Differences between Atari 2600 and Atari 7800 sprite colors?

[+Random Terrain]

For a multicolored Atari 2600 sprite, each row can only have one color (not including any holes that let the background peek through). When I look at some Atari 7800 sprites, a row seems to have more than one color. From what I have read so far, not all multicolored Atari 7800 sprites are the same. It all depends on the mode or something like that.

 

Is there a web site or a thread at AtariAge that lists the different types of Atari 7800 sprites and how many colors each row can have (in plain English and possibly with images)?

 

 

Thanks.

[CPUWIZ]

There is some info here...

 

https://sites.google.com/site/atari7800wiki/home

[Rybags]

Depends on mode, yes. In a sense, everything displayed on the 7800 is a sprite of sorts - the main limitation being how many DMA cycles are consumed to display them.

 

Note though that there's not hardware collision or priorities in the normal sense. Collisions have to be software detected, usually by bounding box method. Priority works such that objects appearing later in the Display List will overlay the earlier ones.

 

One thing I've wondered for a whilte though - could TIA be used as a collision detector of sorts, ie you could plug in graphic/positional data that of course doesn't display, but the collision registers should work. Although given it's a time-consuming process to do, probably way less efficient in most cases than bounding boxes.

[+Random Terrain]

There is some info here...

 

https://sites.google.com/site/atari7800wiki/home

 

Thanks, but that's one of the many places I looked and it doesn't seem to say how many colors an Atari 7800 sprite can have per row.

 

I guess Wikipedia has one of the best plain English explanations:

 

wikipedia.org/wiki/Atari_7800#Graphics

Depending on various parameters, each individual sprite can use from 1 to 12 colors, with 3 colors (plus a 4th "transparency" color) being the most common.

 

An Atari 2600 sprite can use any of the 128 colors, but it is limited to only one color per row. Looks like the sprites that most Atari 7800 programmers use can have only 3 colors for the whole sprite. So you can have 3 colors per row, but all of the rows that make up a sprite can only use those 3 colors. If I'm not misunderstanding, that's an improvement over Atari 2600 sprites in a way, but it's also more limiting. For example, you could create an Atari 2600 sprite that is 128 rows high that uses 128 different colors, but it doesn't look like you could do the same on the Atari 7800. With the most commonly used sprite on the Atari 7800, you could have a sprite that is 128 rows high, but it could only use the same 3 colors for the whole thing.

[RevEng]

If I'm not misunderstanding, that's an improvement over Atari 2600 sprites in a way, but it's also more limiting. For example, you could create an Atari 2600 sprite that is 128 rows high that uses 128 different colors, but it doesn't look like you could do the same on the Atari 7800. With the most commonly used sprite on the Atari 7800, you could have a sprite that is 128 rows high, but it could only use the same 3 colors for the whole thing.

Yeah, the MARIA graphics chip in the 7800 is generally more advanced than TIA, but because you control TIA 100% as the screen is drawn, TIA can be more flexible within its own limitations. Its the price you pay for a chip that doesn't need to be micromanaged.

 

Even though it's a called a mode, you can mix 160B 12-color graphics with the 160A 3-color mode they're referring to. So one of your sprites that needs color can have 12 colors, while the others use leaner 3 color graphics.

 

Or you could build your monster sized sprite from smaller sprites, with different sprites using different palettes. Due to the way MARIA works with graphics data, you're pushed into storing graphics in zone sized chunks, more or less.

 

 

One thing I've wondered for a whilte though - could TIA be used as a collision detector of sorts, ie you could plug in graphic/positional data that of course doesn't display, but the collision registers should work.

Sadly, the TIA CX* collision register addresses are inaccessible in 7800 mode. MARIA palette registers are at those addresses.

[+Random Terrain]

Even though it's a called a mode, you can mix 160B 12-color graphics with the 160A 3-color mode they're referring to. So one of your sprites that needs color can have 12 colors, while the others use leaner 3 color graphics.

 

Thanks for the info. I like that idea.

 

 

 

Or you could build your monster sized sprite from smaller sprites, with different sprites using different palettes. You'd want to have multiple sprites for tall objects anyway. The way MARIA requires sprite and character data to be stored - with each line of graphics separated by a whole page of memory - pushes you toward using joined smaller sprites to make big objects. Otherwise you'd get a bunch of bytes spread across 32k for your 128 line sprite, mucking up most/all of the program space.

 

Sounds like a certain number of Atari 7800 sprites can be near each other or touch each other without flickering. We could make some cool-looking stuff.

[RevEng]

Sounds like a certain number of Atari 7800 sprites can be near each other or touch each other without flickering. We could make some cool-looking stuff.

Yup, this is the up side. You can throw a lot of sprites at MARIA, and provided she has time to render them, they're flicker free.

[Rybags]

Has anyone used "flicker" on the 7800, ie overcome the DMA limitation by only displaying certain objects every 2nd frame?

 

The multicolour "limitation" - not as bad as you might think - colour registers can be changed, either use DLI or a kernal or mix of both.

Of course though, objects don't have exclusive allocation to the colour registers, so changing a single colour register might affect every object on that scanline.

[EricBall]

The 7800 has a 13 color palette from 256 shades. As stated, the palette registers can be updated mid-screen as well. (Note: the registers are not buffered, so it's recommended to update the registers after STA WSYNC to avoid changing them in the middle of the row.) How sprite data relates to which palette registers are used depends on the current read & write modes.

 

You probably could do some kind of intelligent flicker routine to handle cases with either a large number of sprites (especially with a tile background). Just keep track of which sprites haven't been displayed, and add them to the display list before the ones which haven't been displayed.

[PAC-MAN-RED]

Quoted from GroovyBee in a message to me explaining how the 7800 graphics work:

 

"The Atari 7800 does not have a linear video frame buffer like the ST, A8s etc. Its graphics are generated on a per zone basis from a Display List (DL) on the fly. A zone can have a vertical resolution of between 1 and 16 pixels. Each zone also extends across the full width of the screen. Each Display List header points to some graphics/character data and a palette index (0-7) that the data will pass through on its way to the screen (the Display List headers have other data like starting X coordinate and sprite width in bytes too). The video hardware is poked with the start address of the Display List List (DLL) which is a list of pointers to Display Lists. Confusing I know .

For example the Display List for zone 7 might contain :-

<Display List entry - background gfx data>
<Display List entry - sprite 1 gfx data>
<Display List entry - sprite 2 gfx data>
<....>

I like to think of all the 7800 graphics data (background tiles, foreground sprites etc.) as all just being sprites because it makes life easier. The order of sprite display is controlled by the position of that sprite's Display List entry in the list for that zone. In the display list example above if sprite 1 and 2 overlapped you'd see sprite 2 on top of sprite 1. Both sprite 1 and 2 are on top of the background sprite.

I hope this is making sense. This is what puts most programmer people off the 7800 .

You don't need sprite masks on the 7800, its all done by the hardware for you. Where ever you use the common background colour in the sprite it can be considered as transparent when the sprite is overlaid onto other sprites.

Sprites on the 7800 cannot be zoomed or flipped in hardware. Its software routines or graphics duplication in the ROM for those sorts of effects.

You don't need to clip sprites in X. For example, if you had a sprite that was 16 pixels across and you stated its starting X position was -1 (off left side of screen by one pixel) only the rightmost 15 pixels would be drawn on screen. A similar effect happens on the right side of the screen. If you specify the draw position as 149 only the left most 10 pixels of the sprite will be drawn.

Using Display Lists in this manner allows easy left and right scrolling too. With 12-13 writes to your Display List entries (for all zones on screen) you can scroll sprite blocks left and right. You can do 50/60 FPS side scrollers doing this.

Colour on the Atari 7800 is done with hardware palettes. It supports up to 24 colours on screen per scan line at the same time (as standard) and a background colour giving 25 colours in total. You don't specify the RGB for the colour though. The value you poke into the palette registers directly affects the phase of the chroma component of the TV signal.

There are 8 "mini palettes" arranged as 8 lots of 3 colours. The common background colour to all the mini palettes is set in another register.

The 7800 has 2 graphics modes that I use in games :-

160A - Each sprite can be 4 colours, 3 colours come from the each palette and a common background colour to all sprites.

160B - Each sprite can be 13 colours, 12 colours come from the first 4 mini palettes and a common background colour to all sprites. the second lot of 12 colours come from the last 4 mini palettes.

The video chip in the 7800 is called MARIA and it has a fixed display bandwidth. If you have too many 12 colour objects in the display list for each zone it'll soon max out the bandwidth because it takes MARIA too long to fetch the graphics data in the time alloted to that video line.

You can also mix and match 160A and 160B graphics in the same Display List for a zone. The 7800 also has some 320 pixels across graphics modes but they have a more limited palette.

For each zone you can trigger an interrupt. The interrupt fires before data for that zone is extracted from memory and used. This allows the 7800 to change colours on the fly. You can achieve nice colour bars and the like doing this. It also allows status areas in games to use different colours to the main game.

If you want more information (I've skipped some of the other stuff you need to know about as a programmer like Holey DMA and sprite cutting between zones). Have a read of :-

http://www.atarimuse...maria_specs.pdf

The 7800 only has 4K of RAM internally. You can have up to 48K of ROM space before you need to bank switch. When you bank switch you swap out a chunk of memory for another in the cart.

Let me know if you need any other technical information.

Mark."

[PAC-MAN-RED]

Here's something to help those people, myself included, that require more of a visual aid:

 

 

Thanks to RevEng for posting the image he created in his up coming batari Basic port for the 7800 so that I could steal it and use it in my diagram.

[Trebor]

Here's something to help those people, myself included, that require more of a visual aid:

 

7800 Graphics.PNG

 

Thanks to RevEng for posting the image he created in his up coming batari Basic port for the 7800 so that I could steal it and use it in my diagram.

How does the 320 modes factor into the above, using a 320x192 visible field, instead of 160x192?

 

Froggie (Awesome job Schmutzpuppe) pulled off some amazing work with one of the 320 modes.

 

 

The 7800 also has some 320 pixels across graphics modes but they have a more limited palette.

In the above example it seems there is multiple same sprites with what appears to be a three color palette and on the same line(s) a different sprite utilizing two different colors.

 

In 160 modes you can have two different sprites utilizing four different colors each, but in 320 mode you can only have two different sprites utilizing three colors and another utilizing two colors; is that the color limitation difference - or could even more be accomplished (three and another three colors for each different sprite perhaps)?

[EricBall]

320 modes are a "double res" version of the 160 modes. Although 2 pixels are displayed, positioning is still on the 160 pixel boundaries.

 

The actual colors are controlled by a combination of the write mode and the read mode. See gcc1702b_maria_specs or https://sites.google.com/site/atari7800wiki/graphics-modes and https://sites.google.com/site/atari7800wiki/graphics-modes/palette-sprite-bits for the gory details.

Edited February 11, 2014 by EricBall

[EricBall]

The following tables map the graphics data bits to color indicies for the various modes (except 320D, which is 1bpp like 320A but the palette bits change the colors of the left & right sub-pixels - very strange). Note: the tables are in pixel color order rather than bit order to make it easier to understand.

160A 	WM=0,RM1=0
	3 colors from 8 palettes + transparent / background, 2 bits / pixel
D7 D6 
 0  0	BG / transparent
 0  1   C1
 1  0	C2
 1  1	C3

160B	WM=1,RM1=0
	12 colors from 2 palettes + transparent / background, 4 bits / pixel
D7 D6 D3 D2
 0  0  0  0	BG / transparent
 0  1  0  0	c1
 1  0  0  0	c2
 1  1  0  0	c3
 0  0  0  1	BG / transparent
 0  1  0  1	c5
 1  0  0  1	c6
 1  1  0  1	c7
 0  0  1  0	BG / transparent
 0  1  1  0	c9
 1  0  1  0	c10
 1  1  1  0	c11
 0  0  1  1	BG / transparent
 0  1  1  1	c13
 1  0  1  1	c14
 1  1  1  1	c15

320A 	WM=0,RM1=1,RM0=1
	1 color from 8 palettes + background & transparent, 1 bits / pixel
D7 D6 
 0  0	BG + BG / transparent
 0  1   BG + C2
 1  0	C2 + BG
 1  1	C2 + C2

320B	WM=1,RM=1,RM0=0
	3 colors from 2 palettes + background & transparent, 2 bits / pixel
D7 D6 D3 D2
 0  0  0  0	BG + BG / transparent
 0  0  0  1	BG + C1 / transparent
 0  1  0  0	BG + C2
 0  1  0  1	BG + C3
 0  0  1  0	C1 + BG / transparent
 0  0  1  1	C1 + C1 / transparent
 0  1  1  0	C1 + C2
 0  1  1  1	C1 + C3
 1  0  0  0	C2 + BG
 1  0  0  1	C2 + C1
 1  1  0  0	C2 + C2
 1  1  0  1	C2 + C3
 1  0  1  0	C3 + BG
 1  0  1  1	C3 + C1
 1  1  1  0	C3 + C2
 1  1  1  1	C3 + C3

320C	WM=1,RM1=1,RM0=1
	4 colors from 2 palettes + background & transparent, 2 bits / pixel
D7 D6 D3 D2
 0  0  0  0	BG + BG / transparent
 0  0  0  1	BG + BG / transparent
 0  0  1  0	BG + BG / transparent
 0  0  1  1	BG + BG / transparent
 0  1  0  0	BG + c2
 0  1  0  1	BG + c6
 0  1  1  0	BG + c10
 0  1  1  1	BG + c14
 1  0  0  0	c2 + BG
 1  0  0  1	c6 + BG
 1  0  1  0	c10 + BG
 1  0  1  1	c14 + BG
 1  1  0  0	c2 + c2
 1  1  0  1	c6 + c6
 1  1  1  0	c10 + c10
 1  1  1  1	c14 + c14

This also shows why Kangaroo Mode (transparency) has an odd impact on 320B. For all the other modes transparent pixels go to background when KM=1, but with 320B this isn't the case.

[PAC-MAN-RED]

Well I took a closer look at Froggie, and I gotta say it's a masterpiece of programming. It's doing stuff I can't understand without first mind melding with Schmutzpuppe. However, it is doing something I do recognize so here it is:

 

 

Also, after examining the screenshot I would hazard a guess that it is most likely made up of more than one 320 mode. Thanks to Eric Ball - This effect is demonstrated by a test program he made and is explained on this page: https://sites.google.com/site/atari7800wiki/graphics-modes/320b-d-and-kangaroo-mode

 

Would also be fantastic if Schmutzpuppe would chime in and allow us to learn from his mad skills.

 

[Bakasama]

I got a question, how can the frog get away with having it's unique colors while everything else have their colors defined by the zone there in.

[RevEng]

You're not stuck with one palette per zone. You get to choose the palette for the sprite/characters when you create the zone/DL entry for each.

 

But if you want a bunch of characters using different palettes in the same zone, you need to create a separate DL entry for each set of characters with a different palette. This would bog down MARIA fast. If you're using 160A, unlike Froggie, 12 color 160B mode characters would be a better alternative, though still expensive in terms of MARIA time.

[EricBall]

Palettes are specified on a per sprite / tile list basis (and it doesn't "cost" anything). So with 160A you have 8 palettes of 3 colors to chose from. It is possible to change the colors in mid-screen, but there's limited CPU time to do so (min 7 fast CPU cycles per line). I suspect Froggie changes the background color from blue (water) to black (road) so it doesn't need to have a tiled background (which is very expensive in MARIA time).

[RevEng]

I probably didn't state it as clearly as it could have, but the expense/cost I was referring to was using 2 or more tile-list DL objects in a zone for more palettes, vs a single tile DL object giving 1 palette. Assuming the width is the same, surely if you throw more DL objects at MARIA it takes more of her time.

[PacManPlus]

I've also been trying to wrap my head around how he got the 3rd color with transparency in 320B mode (so I can apply it to my Pac-Man 320 games - or other games in the future), but I just can't get it.

[kenfused]

I've also been trying to wrap my head around how he got the 3rd color with transparency in 320B mode (so I can apply it to my Pac-Man 320 games - or other games in the future), but I just can't get it.

Which item(s) have 3 colors and transparency? Are the frogs and snakes the only items needing transparency? Edited February 19, 2014 by kenfused

[PacManPlus]

Which item(s) have 3 colors and transparency? Are the frogs and snakes the only items needing transparency?

Yes. I'm noticing that everything else doesn't need transparency, but the frog and snake do.

 

 

@everyone else discussing colors and modes:

If I'm not mistaken (and I have not seen or read otherwise), 320B mode limits you to two palettes, and if you use transparency, only two of the three colors within each palette. This means if you don't have time to change colors in a DLI, you're limited to 4 colors total in 320B mode. I had to change palette colors numerous times in Moon Cresta and Scramble with a DLI because of this.

[EricBall]

If I'm not mistaken (and I have not seen or read otherwise), 320B mode limits you to two palettes, and if you use transparency, only two of the three colors within each palette. This means if you don't have time to change colors in a DLI, you're limited to 4 colors total in 320B mode. I had to change palette colors numerous times in Moon Cresta and Scramble with a DLI because of this.

 

See my post #14 which shows each of the color codings. 320B gives 3 color + background|transparent per sprite from 2 palettes (P0 and P4) or 7 colors (including background) per line.

 

The spec says there are at least 7 "fast" CPU cycles between the end of DMA on one line before the start of DMA on the next line. How many cycles the DLI gets before DMA starts depends on how many sprites/bytes were in the last display list, but if we assume there's enough cycles to do the IRQ and STA WSYNC before the end of the line, then you can easily change 1 color (i.e. background) before the line starts. And if you can restrict yourself to using 1 palette in that zone then there's plenty of time to change more colors.

[PacManPlus]

Hi Eric:

 

Thank you for the explanation...

 

I'm confused then. *Any* time I've tried to use that third color in 320B mode while using transparency it never shows up on the real thing. Is there something different you have to do (other than set the Write Mode and the DL header) in order for that third color to come out?

 

Thanks,

Bob

[Eckhard Stolberg]

I'm confused then. *Any* time I've tried to use that third color in 320B mode while using transparency it never shows up on the real thing. Is there something different you have to do (other than set the Write Mode and the DL header) in order for that third color to come out?

That might have been an issue with the graphics you used. Mode 320B uses the same write mode as 160B. So if the pixels in your 320B graphics are set up in such a way that they would be displayed as transparent, if the data was used in mode 160B, they will show up transparent in mode 320B as well. Schmutzpuppe had that same problem while working on Froggie. See here: http://atariage.com/forums/topic/68549-320b-help/