Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

EricBall

Members
 View Profile  See their activity

  • Content Count

    2,362

  • Joined

  • Last visited

Posts posted by EricBall

  6. Posted

    7800 disassemblies are few and far between, and I don't believe one has been done for Centipede.

     

    How does a CX-80 TB work? Is it like a driving controller (or mouse, or Tempest spinner) with has two signals, clock and direction, per axis? Or is it more like a paddle with a variable resistance?

     

    In either case I think the TB has to be sampled multiple times per screen. On a 7800 I'd recommend invoking the DLI once per zone to sample the controller. I think this would be okay for a spinner, but too low-res for a paddle.

  7. Posted

    There's nothing limitting a 7800 game from having 240 active lines. How many of those would be visible depends on the TV.

     

    NES mappers are mostly just different varieties of bankswitching, which has been done since the 2600 days. Some of the complexity is handling the PPU address bus and making the most efficient use of the address space. Yes, some mappers had additional tricks (MMC3 & MMC5), but that wasn't their primary purpose.

  9. Posted

    Maybe you can explain this to me regarding video resolution.

     

    Why does the NES have a better resolution than the Atari's?  From the Atari docs I've read, they seem to imply that you cannot exceed the 160x192 resolutions.  But the NES has a 256x224 resolution--much better.

    A standard NTSC field has 262 lines (312 for PAL), however 9 of those lines are part of the vertical sync and some of the remaining lines are not visible onscreen. There's nothing preventing a 7800 game from outputting 224 lines (or even 240) of graphics data.

     

    The horizontal resolution is more of a design decision. The 7800 video signal is driven by a clock which is a even multiple of the colorburst frequency (x1 for 160, x2 for 320), while the NES uses a 1.5 multiplier. More pixels also increase the on-chip line RAM requirements.

  10. Posted

    I've had a quick look at the code and I don't see anything weird. I haven't had a chance to give it a whirl on my CC2 though. A couple of thoughts:

     

    The 320 modes are subject to color aliasing, artifacts & blending. Changes in luminance will be decoded by the TV as color shifts. (At one point I started to work out how to model this, but never finished it.) So you may not be able to see certain color changes.

     

    Kangaroo mode causes color 0 to be background instead of transparent. However, in 320 modes transparency only works if both the even & odd half pixels are are zero.

     

    Unfortunately, I can't understand how setting Kangaroo mode would impact non-overlapping sprites. Perhaps our understanding of 7800 graphics (which is almost entirely documentation based) is flawed.

  11. Posted

    Can someone clarify how big a non-bankswitched 7800 cart actually is? I've heard both 32K and also 48K ...?

     

    Through bannkswitching, I know 7800 games reach 128K and 144K (and conceivably 512K and  larger, except that Tramiel wouldn't foot the bill) but how big are the banks?

    32K is a standard 256Mbit ROM and just requires A15 to be inverted to ~OE. A 48K ROM would require additional logic (not a real big issue for a mask ROM) and probably waste some of the bit row/column rectangle. (Or a 32K + a 16K ROM and some logic.)

     

    According to http://home.arcor.de/estolberg/texts/7800list.txt most 7800 bankswitched games use 16K banks, although this is not the case for all bankswitched games. There really is no limitation, other than the 4K bank at $F000-$FFFF must have a valid digital signature for NTSC carts.

     

    In fact, if I were to create a bankswitch cartridge, it would divide the ROM into 4K banks which could be mapped to any 4K address space (other than bank $F000, of course) by writing to the bank. STA $Exxx would map ROM bank xxx to $E000-$EFFF (with the number of significant bits dependent on the size of the ROM). This could be achieved with a small 8 entry register file and some control logic. (Too much for a 22V10 PAL, but a small FPGA might be able to handle it.)

  12. Posted

    And Pitfall II has a special chip on the cart but everything is still running through TIA - all the special chip does (I think) is feed sound data to the program which then sends it to TIA every scanline (or something). 

    Yup, it has three onboard 1 bit wave generators which are summed to a 4 bit amplitude, which is then read by the game periodically and used to drive one the volume register of the TIA channels. See US Patent #4,644,495 for more info. This gives Pitfall II 3 voice music capabilities.

  13. Posted

    I suspect anyone that was interested in developing for it in the 80's saw the programming specs and ran away screaming.  The Atari dev tools are pathetic.  The Madmac assembler is a 68K assembler retrofitted for 6502 code.  The suggested graphics tools are pretty lame too. 

    Hmm... I hadn't thought of things from the perspective of what was available in 1984/86. I hope that things are a little better today.

     

    If "they" had spent an extra few pennies on a 6532B, the ram and timer would be usable in 7800 mode.  As it is, the only stable time base is the horizontal and vertical retrace timing.  Depending on PAL/NTSC, "your mileage may vary".  Even a simple software loop is not deterministic due to DMA.

     

    If anyone thinks no-one has pushed the system - they are mistaken.  It has been pushed almost as far as it can be.  Unlike the 2600 and 800 which allow fancy video tricks on the fly, the 7800 buffers everything internal to the Maria chip where it can't be accessed.

    I don't know if the absolute limits have been reached. We homebrewers are still working on our first games. That being said, I agree that the asynchronous nature of MARIA takes some getting used to and DMA can really cut into the CPU budget. In theory, software timing loops shouldn't be necessary. The game simply needs to ensure a complete DLL is available every frame.

    Yes, it has lots of "sprites", but it takes more code than it should to move them vertically.  It has 25 colors out of 256 in 160 mode.  That drops to 9 colors in 320 mode (unless you do palette or color cycling).

    Building DLs to start with takes too many CPU cycles. Vertical motion just means the sprite appears in multiple DLs. Vertical scrolling (with a tiled background) is even worse.

     

    I'm not sure how you get your colors though. But I will agree that everything except 160A is very strange and somewhat limitting.

  14. Posted

    And rapidly decided that I hated 6502 assembly and wanted nothing to do with it.

    This may have something to do with the fact that my envisioned project would have used multiplication extensively.

    Yes, multiplication, division or anything other than the built-in operations will require more effort to perform on the 6502. For that reason it's recommended to try to rethink any routines which might require those operations. Multiplication & division by a fixed value can often be coded as a small number of shifts and adds, or even a lookup table.

     

    Consider SpaceWar! 7800. Gravity is an inverse square of the distance: G/abs(x*x+y*y) - two multiplies and a divide. What I did instead was create a lookup table based on a low resolution x,y grid. So now all it takes is a couple of shifts & and or to calculate the offset and I have the required value. But, when playing the game gravity is very smooth.

  15. Posted

    OK Eric. Realistically speaking, how long is it going to take me to learn how to code for the 7800? I have often thought of learning how to do this but I have no idea where to start or how to do this. I have many other hobbies..

    It depends on your background and aptitude. I've been programming computers since the early 80s, but that doesn't mean you have to be a programming wiz.

     

    First, do you have any procedural programming experience (e.g. C, BASIC, Pascal, etc.)? First step is to learn the basics of the 6502 & assembly language. Start at www.6502.org for that. You need to know the basics - load, store, add, compare, branch. Then start with the documentation for the 7800 and soem of the sample code which is out there. Join the mailing list, read the archives. Dedicate an hour a day and you'll be surprised how quickly you get up to speed.

  16. Posted

    The A8 didn't get an official version of Lemmings, but we do still have The Brundles, which is a decent enough port. Given the fact that Lemmings was ported to both the C64 and the Lynx (among others), I'll maintain hope that the 7800 could handle it, too.  :)

    Lemmings would be tricky due to the way the diggers worked. That really calls for bitmapped graphics instead of the sprites used by MARIA.

  17. Posted

    As much as I would love to see homebrew ports of well known & loved games, wishing for them isn't going to make it happen. The only way any of these will be created is if you make them for yourself. No one else is going to do it for you because no one else has the same passion about your favorite game. So instead of wishing, start at atari7800.xwiki.com and follow the links.

     

    For Spy Hunter you could (theoretically) use the paddles for steering. Heck, you could build a complete Spy Hunter control panel which would interface through the joystick port(s) - two paddles for steering & gas, 5 buttons (joystick directions & buttons) for weapons, van & shifter.

     

    MARIA has decent sprite power, yes. But, as I've said before, it's very CPU intensive to set up the sprite lists plus the more sprites the fewer CPU cycles available (due to DMA cycle stealing). The polygon demo you refer to only reached high fps on MESS, which doesn't model CPU cycles correctly.

     

    One problem with ports is they will always be compared to the original. It's much more rewarding to do something new which will be judged on it's own rather than being compared.

     

    Ken and Bruce have done a great job with their 7800 programming efforts. Come join the fun, all you have to lose is your free time.

  18. Posted · Edited by EricBall

    I think the bomb button idea is a good first step.  That's the best idea I've come up with since the last version.

     

    One lesson I learned with Skeleton/Skeleton+ was to never rush to finalize a game. It's always a good idea to take a step back and think "how can I make this more fun?" Is it too hard, too easy, too repetitious, too random, too predictable etc. Focus on the biggest flaw and consider why you feel it so and what can be done about it.

     

    Although I haven't played it, a Tetris/Pipe Dream fusion sounds like an excellent concept. Classic ways to increase difficulty include: pieces falling faster and/or rows of starting pieces. I think Tetris also would vary the probabilities for each piece. (So all you would get were Z type.)

  21. Posted

    SMS Specs:

    Colors: 32 + 32  

     

    7800 Specs:  

    BANKSWITCHING : No

    RESOLUTION : 320 X 200

    COLORS : 256

    SMS Specs:

    Colors: sprite/tile palette of 16 colors from 64 RRGGBB + second tile palette of 16 colors from 64 RRGGBB

     

    7800 Specs:

    BANKSWITCHING : Yes, although not often used

    RESOLUTION : 320 X 200, although 160 X 200 more common

    COLORS : 8 palettes of 3 colors from 256 YYYYCCCC

  22. Posted

    See Charles MacDonald's docs and Richard Talbot-Watkin's doc for info about the guts of the SMS.

     

    The SMS has 8K of program RAM, 16K of video RAM (access indirectly via Z80 I/O port commands) and 48K of cartridge address space (with bankswitching used to allow larger cartridges). Some cartridges may have additional RAM.

     

    Like the NES, the SMS has a grid of 8x8 tiles plus 64 independently positioned 8x8 (or 8x16) sprites with a screen resolution of 256x192. Again, like the NES, the SMS GPU uses a separate memory bus, so the CPU continues to process during active video. Horizontal & vertical scrolling is done in hardware.

     

    One interesting difference between the SMS and the NES is the SMS does not have dedicated VROM, so all tile/sprite patterns have to be transferred by the CPU to VRAM. However, this does mean sprite/tile graphics can be updated as required.

     

    Sprites colors are from a palette of 16 (tiles have an additional palette of 16) from 64 RRGGBB. Palette entries can be reloaded on the fly, even mid-screen.

     

    From this brief look at the capabilities of the SMS I'm amazed. It has equivalent tile/sprite capabilities to the NES and superior color capabilites (16 versus 3 colors per tile/sprite). Like the NES, the SMS graphics capabilities is generally superior to the 7800 save for raw sprite power (e.g. Robotron).

     

    Based on http://www.geocities.com/SiliconValley/Pea...3938/z80ins.txt it appears a Z80 requires 2-3 times as many cycles per operation than a 6502. So no major advantage either way. (The Z80 has more registers including two 16 bit index registers.) The only limitation I can see is the CPU to GPU interface, which requires multiple port operations to move data to/from VRAM.

     

    Sound, don't make me laugh.

  23. Posted

    z26.log is your friend. Yes, it's gi-normous, but HD space shouldn't be a major problem for anyone these days. There are also ways you can make it easier on yourself:

    • Use WSYNC in when waiting for the timer
    • Put a distinctive STA $xxxx before or after code you want to watch. You can then FIND it easily (or even use the command line FIND command to just display those lines.

    There is a gotcha with the #lines*76/64 STA WSYNC/LDA INTIM loop. Do you see it? What happens if the INTIM transistion to zero occurs during the WSYNC? The code then misses it and waits another 256 cycles (3-4 lines) for the timer to finish it's overflow count. Make sure your STA TIM64T occurs a fixed number of cycles after WSYNC, then use Z26.log to tune the TIM64T value.

  24. Posted

    Now, if you set the timer at the beginning of vertical blank, does the PIA halt the 6507 until it reaches zero (making it less useful) or does the 6507 keep on running, so that you could simply start it at the beginning of VBLANK, then run through a variable number of cycles, then check it in a loop for zero when you're done with your work, then just do a single WSYNC and you'd be in perfect sync every time?  

    First, it's a RIOT (a 6532) and it only has one timer. It is possible to have the timer only count down every 1, 8, 64 or 1024 CPU cycles though by writing to different memory locations (TIM1T, TIM8T, TIM64T and T1024T respectively). There are also some interrupt options, but they aren't useful in the 2600 because they aren't connected.

     

    The usual way to use the RIOT timer is to write to TIM64T with 76/64 * the number of lines to wait, then put a STA WSYNC, LDA INTIM, BNE loop at the bottom. You may need to adjust the TIM64T slightly so watch the Z26 line counter or log file.

  25. Posted

    Nope, it doesn't appear to be possible to connect B/C as left/right. On the Genesys B/C connect pins 6&9 to 8 (common ground) and I can't match this to the 7800 fire button circuit without rewiring the internals.

     

    So connect 6 through and B becomes the common fire button & leave 9 unconnected so pressing C won't mess things up. Pins 1-4 & 8 are connected straight through.

     

    An SMS controller should work without modification, although button 2 won't work right.

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...