EricBall
-
Content Count
2,362 -
Joined
-
Last visited
Posts posted by EricBall
-
-
Ahh, okay. So you do have 8 distinct sets of 32 possible characters. So every 8 frames you update only 5 character map entries:
1. new head
2. head -> neck
3. neck -> body
4. body -> tail
5. tail -> blank
the remaining body segments just cycle through their 8 animations until they are changed to the tail (which then cycles through it's 8 animation cycle). So everything animates in lock-step. Then you'll need 8 character sets, each taking up 2K of ROM space. Tthere will be 160 bytes per 256 byte page which won't be used, which you could use for other data, or even code. I did the same thing for the 4K version of SpaceWar! 7800. One bonus is you can animate any of the "static" items too.
Double buffering just adds a 1 frame, 16.7ms, delay to the display and means you can do wholesale updates to the character map without mucking up the display.
-
What about just blt'ing the little guys onto the bitmapped background? I'm pretty sure that's what all the other versions do. They'd probably be no more than five pixels wide (remember we're in fat-pixel mode), so using preshifted shape tables should allow for pretty quick plotting. What's the memory layout for a hi-res bitmap on the Maria? Is it row-major, column-major, or some goofy hybrid?I don't know whether the blit would be less CPU intensive than building display lists. It would free up some additional CPU time though. The problem with blit is un-blitting cleanly. You'd probably need another 16K of RAM to keep as a "holey" version of the background. (Might be able to squeeze both into 16K depending on the size of the playfield versus the score & action buttons.) At least if they're sprites you don't have to have the pre-shifted versions.
RAM layout for the background would be $base+Y*64+X/4, where X,Y=0,0 being the bottom left corner. (Using 64 bytes per row instead of 40 for shiftability.)
A mouse would be similar to a trackball, and needs to be read multiple times per screen. Do-able, but it will chew up some CPU time and might reduce the maximum number of sprites per line.
-
Yeah, I realized later that 320C only really gives you one more color than 320B at the cost of flexibility between the two half pixels. Stick with 320B, that maps exactly to the old CGA modes.
Let's make sure we understand how the worm is animated. The worm is made up of 15 different characters (of 32 possible characters), and there are 8 possible variations of each of the 32 possible characters. The characters making up the are worm are stored in a 40x25 character map along with the background (which is another 16 characters). Hmm, let me see if I can do a primitive example. Is the worm animated like this?
frame 1: >:---! frame 2: };///? frame 3: ]:|||? frame 4: };\\\! frame 5: >:---!
where frame 5 = frame 1 etc. So the character map doesn't change, but the graphics for each of the characters is from one of 8 complete sets of 32 characters. (Versus 32 different characters which are dynamically selected from 8 different possible variations. So character 1 may be from a different character set than character 2.)
Note: you could have two 40x25 character maps in RAM. Be updating one while MARIA displays the other. In that case you'd also have two DLLs and display lists, and just change the DLL pointer register.
-
See also A start to a decent platformer?
Yeah, for Lemmings the background would be the killer, especially since the diggers & bombers affect the background directly. Maybe with 16K of cartridge RAM to do a 160A x 240 bitmapped background. Hmm, that would chew up 136 cycles of the ~400 cycles available per line, leaving time for less than 20 two byte / 8 pixel wide sprites per line, and almost no CPU time during the active display, so only 2500 CPU cycles per frame to:
1. update sprite positions
2. perform collision detection versus sprites and the bitmap background
3. update the bitmap background
4. build the ^&*$(#%* display lists
5. read the controller and act on input
No way that could be done once per frame, so it'd have to be done as a sequence, each frame doing a different step; some steps might require multiple frames. If creating the display lists goes over multiple frames, you'd have to have two sets of display lists as a kind of "double buffer".
-
http://www.6502.org/documents/datasheets/m...s_6532_riot.pdf
Note: there is a "quirk" with the RIOT timer on the 7800. Because the RIOT clock line is slaved to the 6502, which is controlled by MARIA, it gets impacted by the "downshift" the CPU makes when it accesses the TIA and RIOT.
-
Although the stock MARIA probably doesn't bother with the half cycle, it would be necessary if it was going to sync properly with an external video signal, i.e. a LaserDisc player via the expansion port.
-
The NES featured interlaced TV output and the 7800 didn't. That's what makes the difference between the two systems in terms of overall display crispness. The reality is the 7800 is a 160xwhatever machine and the NES was higher than that, interlaced. The result being square pixels and a totally different look.Sorry, no.
Interlaced means displaying different images for the even and odd fields. Unfortunately, neither the 7800 nor the NES don't generate the correct vertical sync to produce interlacing. (Since they don't generate the half line at the end of the screen.) Thus the 7800 and the NES have identical vertical resolution: 262 lines per NTSC frame, of which 200-240 are typically active. (OTOH the 2600 can generate a true interlaced image because vertical sync is under software control.)
There are differences between the 7800 and NES horizontal resolution. The NES has active pixels per line and a pixel clock of 5.369MHz (1.5 * colorbust). The 7800 has two possible horizontal resolutions: 160 active pixels per line at 3.58MHz (colorburst) and the less commonly used 320 modes (7.159MHz = 2 * colorburst).
Aspect ratio is another matter entirely. The NES NTSC pixel aspect ratio is about 10:9, while the 7800 NTSC pixel aspect ratio is 5:3 (160) or 5:6 (320). The closest to square pixels is a PAL 7800 in 320 mode, where the pixels are very, very close to square.
Since this comes up every so often, I've done a comparision at http://atari7800.xwiki.com/xwiki/bin/view/Main/NES
-
Well, Wormy II was a CGA game. If you like I could enclose a copy; it sorta plays on modern machines though it runs too fast [cued off frame rate]. And with artifacting, I think you'd sorta get 16 colors on sorta 320x200 resolution [since different combinations of colors in pixel pairs would yield differnet colors on screen]. Remind me how 320C works?In 320C the pixel color indexes are:
P2|S3|S2|S7|0 P2|S3|S2|S6|0 P2|S1|S0|S5|0 P2|S1|S0|S4|0
where P2|P1|P0 is the palette bits from the display list header and S7|S6|S5|S4|S3|S2|S1|S0 is the graphics data bits.
So with 320C you can have 8 colors + background, though with some dependencies between adjacent pixels.
Nope, you'd only need to update the 15 character grid entries for the worm. So for frame 1 you'd use characters 0-31 for the worm, frame 2 you'd use 32-63 and frame 3 you'd use characters 64-95, with characters 96-127 being the background and other non-animated shapes. Then change CHARBASE to point to the second set of graphics, lather, rise, repeat.
Oh, and there's only 25 display lists. One for each row of characters.
-
Yes, Maria typically reads graphics data from ROM. (It could read from RAM, but with only 4K available and limitted CPU time, it's not really the best way.)
Okay, let's stick with the 40x25 8x8 character grid, which is set up in RAM as a 1000 byte table. You have a static DLL and 25 static display lists, each of which is simply two 5 byte headers (left & right halves of the screen) and the 2 byte terminator. That's around 400 bytes total.
Each 5 byte header has a pointer to the appropriate byte in the character grid and width=20 bytes. Maria then reads the byte at the pointer position and uses that as the LSB to the bottom of the sprite data, which is stored in ROM. The MSB comes from the Maria CHARBASE register.
Hrmm, one problem. Each header also contains the palette info, so you'll be limitted to 4 colors for the entire screen. Very CGA. You'll also need to watch out for artifacting. Unless you figure out how to use 320C, then you will have more colors, but less flexibility in using them.
Anyway, where was I. Oh right, the graphics data in ROM. Okay, since we're using 2 byte characters (8 pixels wide, 4 colors = 2 bits per pixel) you have 128 characters to play with. However, you could change CHARBASE every frame and have multiple character sets. Each character set would be 2K, so with 8 character sets you'll need 16K of graphics data. (Actually, you'll only be using around 48 of the 128 characters, so you could put more than one worm character set into a single 2K block.)
So, each frame you only need to modify the 40x25 character grid and CHARBASE as necessary.
-
-
From Misguided criticism of the Atari 7800
Hrmm. Maybe. Let's see (worst case), 455 cycles/line minus 7 * 4 cycles for the CPU after WSYNC, minus 9 cyles DMA start, minus 13 cycles zone end = 405 cycles for the display list. You've said 4 color (2 bit per pixel) 320 mode, i.e. 320B (although 7800 Graphics Modes shows that 320B has some quirks.) So that's 4 pixels per byte, or 2 bytes per tile at 9 cycles per tile. And there'd be 40 tiles per line (41 if you are scrolling), so you'd need at least two 5 byte headers at 12 cycles per header.2 * 12 + 41 * 9 = 24 + 369 = 393 < 405
So, yes, it looks like you would have the cycles, but that's all that you could do. (Well, you might be able to stick in one 8 pixel wide direct sprite, but that's it.)
Cool. Means if I ever got by Dodgson cart working again I might be able to do Wormy for the 7800 in 320B mode. BTW, it needs exactly 40 columns, not 41. The game was written for a CGA, and uses simulated 8x8 character drawing (320x200x4 colors) to draw things quickly. Most of the motion in the game is done by manipulating the character set, so if memory allowed it should be possible to make Wormy run nice and zippy. The primary requirement would be recopying the shape data for thirty-two characters each frame. Since the character shapes would be 16 bytes each, that would be 512 bytes. If the code uses a tight loop:LOOP: LDA CSROM0,X STA CSRAM,X LDA CSROM0+128,X STA CSRAM+128,X LDA CSROM0+256,X STA CSRAM+256,X LDA CSROM0+384,X STA CSRAM+384,X DEX BPL LOOP
That's 41 cycles/loop, times 128 loops. That's 5248 cycles, or 69 scan lines. A little over where I'd like to be, though maybe the top part of the screen could be in lower-color mode. Would the CPU get any time during the displayed part of the frame?
I suppose things could probably be improved slightly if one took advantage of the fact that only 15 of the 32 characters will ever be on screen at once Would be a little more complicated than always copying all 32 characters, but the cycle saviings could be worth it.
Either that, or else can the MARIA get data out of external ROM without copying it to RAM first? If so, that'd be the way to go. There are about 48 character shapes, of which 32 are animated. There are eight character sets, so they'd take up 6144 bytes total. Too much to fit in RAM, but well within the capacity of a ROM.
There are 32 characters that are used for animating the worm, of which at most 15 can be on screen at once (12 may be on screen in arbitrary combination, then one head front, one head-body join, and one tail back). There are about 16 other non-animated characters shapes (walls, mines, gold bags, power-ups, etc.). Each of the worm characters has eight variations. The non-animated characters have only one each.If the MARIA can read graphics from ROM, it would be a simple matter to have eight character sets and simply change the 20 display lists for the rows containing worm segments to change character sets from one frame to the next. Duplicating the non-animated characters would be somewhat wasteful, but not too bad. The other approach would be to copy the animated part of the character set between frames. If I only copy the 240 bytes that are actually needed, this might be workable.
Well, there's one worm [which actually looks more like a centipede] and it's animated along its entire length. I would think 38 8x8 sprites on a scan line in 320B mode would be even more of a bandwidth drain than 40 8x8 tiles.
-
That's 41 cycles/loop, times 128 loops. That's 5248 cycles, or 69 scan lines. A little over where I'd like to be, though maybe the top part of the screen could be in lower-color mode. Would the CPU get any time during the displayed part of the frame?You'd only have a little over 62 scan lines, or 7068 CPU cycles.
Either that, or else can the MARIA get data out of external ROM without copying it to RAM first? If so, that'd be the way to go. There are about 48 character shapes, of which 32 are animated. There are eight character sets, so they'd take up 6144 bytes total. Too much to fit in RAM, but well within the capacity of a ROM.Question - are there more than 128 distinct shapes? 'Cause if there aren't then you can simply store the 40x25 character map in RAM.
But why use character mode at all? Why not just make each worm a sprite?
-
I would expect that a game which took advantage of artifacting might manage to produce better graphics than one which didn't, but I don't know of any 7800 games that do. Does anyone else know?Tower Toppler (especially the water levels)
Also, it's been ages since I read the 7800 specs. Can the Maria clock out enough data to put up a full screen of 4-color 8-pixel wide tiles in 320 mode if there are no other sprites that need to be drawn?Hrmm. Maybe. Let's see (worst case), 455 cycles/line minus 7 * 4 cycles for the CPU after WSYNC, minus 9 cyles DMA start, minus 13 cycles zone end = 405 cycles for the display list. You've said 4 color (2 bit per pixel) 320 mode, i.e. 320B (although 7800 Graphics Modes shows that 320B has some quirks.) So that's 4 pixels per byte, or 2 bytes per tile at 9 cycles per tile. And there'd be 40 tiles per line (41 if you are scrolling), so you'd need at least two 5 byte headers at 12 cycles per header.
2 * 12 + 41 * 9 = 24 + 369 = 393 < 405
So, yes, it looks like you would have the cycles, but that's all that you could do. (Well, you might be able to stick in one 8 pixel wide direct sprite, but that's it.)
-
Not to ressurect this old tired thread, but I was thinking about this yesterday: Is there any place on the net where source code fro 7800 and/or NES games could be found?I'm not aware of any 7800 source code repositories other than what's available for the few homebrews etc. No significant disassemblies (DanB started on Robotron, and I think someone extended Distella for the 7800.)
I did go looking for source code / disasm for SMB but wasn't able to find much more than some VB clones. The big N has a big legal dept and probably discourages that kind of activity.
-
Just a note - although POKEY has 2/4 channels it only has a single mono output pin. The TIA has two channels, and two output pins; I don't know about the chip in AtariVOX.
-
...the 7800 does use a slightly different processor than the 2600 does. They are virtually the same but the 7800's proc has the ability to halt.I'm not sure what 'the ability to halt' means. Do you mean the 7800 clean up the code and doesn't let it get messed up like it does in the 2600?No, the HALT is used by the MARIA GPU in 7800 mode to stop the 6502 from executing so the MARIA GPU can fetch the display lists and graphics data. (aka DMA mode). I'm not sure if this is any different from the TIA halting the 6507 on a STA WSYNC (wait for end of line).
I suspect that batari is correct. If the hidden world is a result of the game using bits the TIA doesn't have output drivers for, it is certainly possible the 7800 could behave differently due to the data bus not floating in the same way.
I do believe this same quirk is used by some other 2600 games.
-
Check out Color Grid Demo for some code which does this (mostly). This was developed before I had my CC2 and I haven't gone back and tried to fix all of the problems mentioned in the post.
Also see http://atari7800.xwiki.com/xwiki/bin/view/Main/RGB where I try (again) to derive an RGB palette for the 7800.
Note: the 320 modes will cause color artifacts with luma changes (e.g. Tower Toppler does this intentionally) which may generate colors outside of the 256.
-
The current 4K SpaceWar! 7800 is available from http://ericball.atariage.com/spacewar.html. Although it is missing many things (score, sound), it is playable. (Two player and NTSC only.)
-
The best way to see any new games for the 7800 is to program them yourself. The CuttleCart 2 is an excellent way to test out what you create on the real thing. (Unfortunately, the 7800 has many quirks and limitations that the emulators don't emulate.)
What have you got to lose but your free time?
-
CW is only applicable for indirect mode. For example, if the DL entry pointer points to $A000 MARIA then retrieves the byte at $A000 and uses it as the LSB of a pointer to the graphics data. (The MSB being the CHARBASE register + the current DLL line number.) So if CHARBASE=$80, your DLL is 16 lines high, $A000 contains $EE and CW=1 (double byte characters) then MARIA retrieves the graphics data at $8xEE and $8xEF (where x=F down to 0) and stores it at the position given in the DL entry. It the retrieves the next byte at $A001, retrieves the graphics data at $8xyy and $8xyy+1 and stores it at position+4*2(WM=0) or position+2*2 (WM=1), and so on until it reads width number of characters. (One note - the graphics data follows holey DMA, while the characters do not.)
As suggested, if you want multiple size sprites, you have to have separate graphics data for each size. No MIP maps for MARIA.
-
The onscreen graphics are certainly within the capabilities of the 7800 (although you'd have to adjust for lower horizontal resolution and horizontal 160x240 versus vertical 192x240). But the main problem with ports is not duplicating the graphics, but duplicating the gameplay (and sound). And unless you are willing to do the programming yourself, I suspect you are in for a long wait.
-
Currently the only option is to cannibalize a common 7800 32K cartridge, swapping the ROM with an EPROM with an inverter between A15 and ~OE.
However, I wouldn't be surprised if Joe Grand of Pixels Past and Albert have something on the drawing board. (Although a donor cart may still be required for the plastic housing.)
-
I wonder if the issue was more the TIA rather than the RIOT. And since they had to go to the trouble to downshift TIA access, it was easy enough to apply the same for RIOT access then use the same part as the 2600. (Then avoiding any issues in 2600 mode.)
-
Correct. The display is Player 1 X, P1Y, P2X, P2Y. The numbers should increase/decrease as you roll the ball, the faster you roll, the faster the numbers should change.
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Armchair Arcade Issue 7 Released!
in Gaming Publications and Websites
Posted
Backwards Compatibility
modern examples: PS2, GBC, GBA, GBDS, PS3?, 360?
counter-examples: N64, GCN, anything by Sega, GBDS, Rev
Now, in my opinion backwards compatibility is something the public says they want but they really don't need it. I mean, is someone going to buy PSX games to play on their PS2? No, they're going to be playing MGS2. Console manufacturers would be better to spend their time, money & effort making it as easy as possible for developers to create spectacular games for their system.