7800 v. Atari 8 bit graphics

[Tyrop]

Question. Is it true that the 7800 can display many colors in 320 x 200 resolution? If so, why can't the Atari 800 do this? My understanding of the Atari 800's graphics mode 8 (which is 320 x 192) is that it is too high a resolution to have color on a TV because each individual pixel is half a color clock (and therefore produces artifacts). If the 7800 can display 320 pixels across, then why doesn't the 7800 (or NES for that matter) produce artifacts?

[SeaGtGruff]

Question. Is it true that the 7800 can display many colors in 320 x 200 resolution? If so, why can't the Atari 800 do this? My understanding of the Atari 800's graphics mode 8 (which is 320 x 192) is that it is too high a resolution to have color on a TV because each individual pixel is half a color clock (and therefore produces artifacts). If the 7800 can display 320 pixels across, then why doesn't the 7800 (or NES for that matter) produce artifacts?

I've never tried to program the 7800, but I'm looking at some documentation for its graphics, and I believe you are correct-- the 320-pixels-wide modes are multicolor modes.

 

How is this possible? Well, in a sense, the 800's 320-pixels-wide modes (GR. 0, GR. 8, and the text mode that allows "true descenders") are *also* multicolor modes, although at the same time they are normally thought of as monochrome modes. This is due to two facts: (1) these modes use only one bit per pixel, so each pixel can be one of only two different colors; and (2) of the two color registers that control the two colors that each pixel can be, one color register controls chrominance and luminance, but the other color register controls only luminance, so you end up with two colors that are different luminances of the same hue (i.e., "monochrome").

 

However, if you change the color registers, then you can change the hue and the two luminances. For example, suppose that it were possible to change the hue for each pixel, by changing the color register that controls the hue. Then you could get many different colors on a line, even though any given pixel could be only one of two luminances of a particular hue. Now, you can't change the color registers fast enough to change the hue for each pixel, but you can nevertheless change the hue several times on a line and get different "zones" on a line, where each zone uses two different luminances of a particular hue. For example, if you change the hue four times on each line-- at positions 0, 80, 160, and 240-- then each line would have up to eight different colors on it, see?

 

Another way to get additional colors in the 320-pixels-wide modes is to use "player underlays" to get additional hues. And of course, you can combine player underlays with changing the color registers as the line is being drawn.

 

Now, due to the fact that each pixel is only half of a color clock, you do get artifacting-- and this is also the case with the 320-pixels-wide modes on the 7800, from what I understand. The big difference with the 7800 is that it allows you to use a greater number of different colors more easily (i.e., without having to keep changing the color registers or tinkering with player underlays).

 

Michael

[Tyrop]

Thanks for the explanation. I guess the answer is in the number of color registers available in that resolution.

[supercat]

The big difference with the 7800 is that it allows you to use a greater number of different colors more easily (i.e., without having to keep changing the color registers or tinkering with player underlays).

 

Actually, due to some unfortunate design decisions the 7800's 320 modes are extremely limited. The machine renders the screen as 160 pixels wide, with five bits per pixel, but has a couple of special modes to map the five bits for each pixel into two half-pixels.

 

When not using transparent objects, this works out pretty well using the first mode. There are two sets of three colors, plus a background color. The only real restriction is that each 160-mode pixel is limited to using colors from a single set--not a big deal.

 

Unfortunately, transparent objects are handled very poorly. A 160-wide pixel will be regarded as transparent unless at least one of the half-pixels within it is color 1 or color 3. If the colors are 02, 20, or 22, then the pixel will be considered transparent and will not appear on screen. This effectively limits objects to two colors plus background.

 

The other drawing mode has two sets of four colors, plus background, where each 160-mode pixel may be drawn on the left half, the right half, or both (the undrawn half shows background color). Transparency only works well with objects that draw both sides of a pixel, but at least backgrounds can use the higher resolution. "One on One" uses this mode.

[+Stephen]

Question. Is it true that the 7800 can display many colors in 320 x 200 resolution? If so, why can't the Atari 800 do this? My understanding of the Atari 800's graphics mode 8 (which is 320 x 192) is that it is too high a resolution to have color on a TV because each individual pixel is half a color clock (and therefore produces artifacts). If the 7800 can display 320 pixels across, then why doesn't the 7800 (or NES for that matter) produce artifacts?

 

Well, the 800 came out almost 5 years before the 7800 was designed, so the graphics capabilities should be a little less. But it's not really a limit of the TV that makes the 800 produce hi-res graphics in mono, since the Commodore 64 can do 320*200 at 16 colors. It comes down to how much data the graphics chip can "spit out". The ANTIC in the 800 can only output 40 bytes of data per scanline (NTSC TVs). To get 320 pixels in 40 bytes you can only get one bit per pixel, drop down to 160 pixels and you can have 2 bit per pixel (4 colors), 80 pixels (GTIA modes) gives you 4 bits per pixel (16 colors). The artifacting comes into play because the ANTIC's "dot clock" runs at the same rate as the NTSC color clock (3.579 MHz for NTSC machines). When you have an every other pixel situation, the color decoder in the NTSC TVs interprets this as color data. Somewhat simple explanation (but hopefully accurate enough:) ).

 

Stephen Anderson

[potatohead]

To expand on that just a bit.

 

How the color is clocked can affect this. By default, if you do nothing but generate a plain old NTSC signal, nice and simple, there are about 160 pixels in the NTSC safe area. The Atari graphics, on the 8 bitters, are keyed to this pixel clock.

 

The C64, and other newer video systems, choose different means of syncing the color to the TV. If you interlace the color, as in offset it 1/2 pixel every other scanline, the solid pixel resolution goes up to 320 pixels per scanline, without artifacts. Wait for some colored text on a tv broadcast sometime and go take a close look at the pixels. You will see them shifting back and forth. Ignoring the vertical interlace, which is every even scan line drawn, then every odd one, this is interlaced color.

 

The 7800 does not do this, so it's 320 resolution mode is somewhat bizzare in how it handles pixels. I suspect this is to avoid artifacting and maintain a stable pixel clock for every scanline.

 

There are more complexities than this in play as well that I don't understand, particularly on the NES. It's 228 pixel resolution seems oddball to me. Maybe they clocked it to minimize jitter in the display or something.

 

IMHO, I'm not sure ANTIC was limited to 40 bytes per scanline for speed reasons. Had it been capable of 80, or 64 or something where more color information would have been made possible per scanline, the overall speed impact would not have been that great.

 

I believe the decision surrounded the sprite engine and how overlays, underlays and variable resolutions all working together impact the overall complexity of the video circuit. Keeping everything keyed to the 160 pixel resolution likely simplified all of that --and when the chips were designed, that was a lot of capability!

 

Perhaps the 7800, being designed to be compatable with the VCS, involved some design choices, where generating pixels and colors is concerned, that managed expectations between the two over providing a better signal at the higher resolutions. Many aspects of the design, follow the minimal approach taken before with the VCS. It may have been thought that few, if any games, would leverage the higher resolution graphics, or that moving objects really didn't need to be at the highest resolution possible either.

 

Had ANTIC been expanded to see color control, above the 160 pixel (for default 40 byte DMA) resolution, it may have seen similar limitations on how things are placed, color sets used, etc... as seen in the 7800.

 

Personally, I like the 160 pixel solid color look. Combined with a robust palette, it has a look that's distinctive. Newer video systems, that had increased color control, also came with lower numbers of directly addressable colors, tile / character modes, and heavier sprite capabilities. These are all resolution and color density choices over intensity and overall color bandwidth choices made in the Atari systems. That's the key to the Atari look, BTW.

[Rybags]

I think the blame goes to Antic wrongly here - GTIA is responsible for generating the actual TV signal.

 

All ANTIC does is read data from memory, then pass it to GTIA on the ANx lines. It does nothing so far as generating colour - only tells GTIA which playfield to display, and sends the H/V sync requests at the appropriate times.

 

So far as resolution goes - it's near the limit considering there's 114 cycles available on a scanline and 96 of those may be assigned to DMA for a wide playfield.

 

Add to that another possible 3 for an LMS Display List instruction and 5 for PMGs. Then another 2 for RAM refresh (the bare minimum when pre-empted by a hires display mode).

[Tyrop]

Thanks for all the replies. So what I am gaterhing is that the Atari 800 had a simpler design than the C64 when it came to diplaying color in 320x200. The C64 (and the NES and everything after the NES) were able to make solid pixels in 320 resolution using more advanced techniques (by doing interlacing?). So is 320 resolution the absolute highest that is resolvable on an NTCS TV? At what resolution are games on the Xbox?

[potatohead]

The top, for a full frame NTSC image is 720x486, that includes overscan and interlaced color. I'm not sure how the colors are done though. I'm working with the Propeller, which is a little microcontroller type chip that has onboard, largely software driven NTSC / PAL / VGA capability. It will do the 720x486, and it does it in color too. I don't fully understand all the mechanics behind color when driving it this high.

 

Perhaps, the double vertical resolution permits some more complex color interleave scheme. I just don't know.

[SeaGtGruff]

Thanks for all the replies. So what I am gaterhing is that the Atari 800 had a simpler design than the C64 when it came to diplaying color in 320x200. The C64 (and the NES and everything after the NES) were able to make solid pixels in 320 resolution using more advanced techniques (by doing interlacing?). So is 320 resolution the absolute highest that is resolvable on an NTCS TV? At what resolution are games on the Xbox?

I think NTSC TV is usually said to have a resolution of about 640x480, but I don't think that means you can display a single dot of color at that resolution and have it be the desired color, because there are only 227.5 color clocks on each line-- and some of those are during the horizontal blanking, so there are fewer than 227.5 color clocks in the visible portion of the line. The topic of TV screen resolution is kind of weird, especially for the analog signals like NTSC. If you look into this topic on the web, you'll see that they talk about displaying alternating black and white vertical lines, with two lines per cycle-- one at the peak, and one at the valley of the sine wave, or something like that. Artifacting is a way of life in analog TV, and you can see it occur when someone is wearing a black-and-white striped shirt and they get farther from the camera-- the stripes will start to show artifacts. Note that resolution in the vertical direction is determined by the number of scan lines, but for the horizontal direction it gets kind of weird, due to the nature of the analog signal. I think the 640 figure is at least partly derived by assuming that the pixels are square, the screen aspect ratio is 4:3, 480 / 3 = 160, and 160 * 4 = 640, so 640 is a somewhat artificial value, because you cannot display 640 dots of color on a TV line and have complete control over the color of each dot.

 

Michael

[SeaGtGruff]

I think the blame goes to Antic wrongly here - GTIA is responsible for generating the actual TV signal.

 

All ANTIC does is read data from memory, then pass it to GTIA on the ANx lines.

I don't think Stephen meant that ANTIC is handling the color, I think he was just saying that ANTIC sends only 40 bytes per line-- so for a horizontal resolution of 320 pixels, that translates into 1 bit per pixel, which is only enough for two values (0 or 1) for each pixel. The C64 stored the color data in a separate memory area than the pixel data, so even though each pixel could be only 0 or 1 at that resolution, it was possible to control which two colors the 0 and 1 would display.

 

Michael

[+Stephen]

I think the blame goes to Antic wrongly here - GTIA is responsible for generating the actual TV signal.

 

All ANTIC does is read data from memory, then pass it to GTIA on the ANx lines.

I don't think Stephen meant that ANTIC is handling the color, I think he was just saying that ANTIC sends only 40 bytes per line-- so for a horizontal resolution of 320 pixels, that translates into 1 bit per pixel, which is only enough for two values (0 or 1) for each pixel. The C64 stored the color data in a separate memory area than the pixel data, so even though each pixel could be only 0 or 1 at that resolution, it was possible to control which two colors the 0 and 1 would display.

 

Michael

 

Yeah - thanks. That's exactly what I was describing.

 

Stephen Anderson

[EricBall]

The top, for a full frame NTSC image is 720x486, that includes overscan and interlaced color.

I think NTSC TV is usually said to have a resolution of about 640x480, but I don't think that means you can display a single dot of color at that resolution and have it be the desired color, because there are only 227.5 color clocks on each line-- and some of those are during the horizontal blanking, so there are fewer than 227.5 color clocks in the visible portion of the line.

 

Michael is basically correct. Analog color TV (NTSC, PAL & SECAM) is made up of four signals - a black & white signal (luma) and two color difference signals (chroma) and framing/synchronization signals. One field of NTSC is 262.5 lines of 63.555555uS and two fields make up one interlaced frame. However, the Atari 2600/7800 doesn't bother with interlacing so each frame is only 262 lines. Officially, only 241.5 lines are active picture (21 vertical blank) and only 52.855555uS (or a little over 83%) of those lines are active video (10.7uS horizontal blank). So an interlaced frame could have up 483 active lines although a bunch of those will be lost on most TVs to overscan.

 

Okay, what about horizontal resolution? The TV industry often uses the term "TV lines" to describe the horizontal resolution of a CRT, which is a very confusing metric and is typically 75% of the value we normally consider to be horizontal resolution - the number of active resolvable pixels per line. It's also almost entirely meaningless because it ignores the limitations of the input signal, which brings us back to chroma and luma and how they get to the TV.

 

If each of the three signals is sent separately (ignoring the sync since it happens outside of the active picture) then it's a component connection. This also means that each of the three signals have virtually unlimitted bandwidth and horizontal resolution. An NTSC DVD uses 13.5MHz sampling (6.75MHz bandwidth) producing 858 samples per line of which 720 are encoded (which includes some horizontal blank). (Actually, the chroma bandwidth is 3.375MHz, half of the luma bandwidth, due to downsampling before encoding.) Component is also the only time when the resolution of modern displays could be exceeded by the source material.

 

Next is S-Video which combines the two chroma signals into one using a 3.579546MHz carrier, which therefore limits the chroma signal to 3.579546MHz or 455 samples per line (378 active). The luma signal is not limitted, but is typically less than 7.159091MHz, or 2x the chroma carrier, for 910 samples per line (756 active).

 

The next step is to combine everything into a single composite signal (which can then be modulated to a given RF frequency for broadcast). This is also where color aliasing comes into play. Ideally the chroma bandwidth is limitted to less than 1.3MHz (137 active per line out of 165 samples) and luma bandwidth to less than 2.27MHz (240 active per line out of 288 samples) to prevent overlap (luma bandwidth + chroma bandwidth < chroma carrier). Okay, what happens if they do overlap? That's when aliasing occurs - instead of detail you get colors. Unfortunately, the 7800 320H modes output pixels at 7.159091, which is twice the chroma carrier and so any on/off patterns will generate color instead of detail.

[Ecernosoft]

I own an atari 7800 and ON MY HD TV FLATSCREEN, there ARE ARTIFACTS.