Definitive Atari 2600 resource

[Thomas Jentzsch]

You should mention that 262 total and 192 visible scanlines are not set values. They can (and are!) changed by the programmers.

 

NTSC TV can tolerate +/-10 to 20 total scanlines (e.g. Artillery Duel 241, Desert Falcon 281 total scanlines). And they should be able to display 200 to 210 scanlines easily.

[roland p]

The upshot of this is that a single FRAME of a TV image is actually only half of the vertical resolution of the image. Thus, a NTSC frame is 525/2 = 262.5 lines deep, and a PAL frame is 625/2 = 312.5 lines deep. The extra .5 of a line is used to indicate to the TV if a frame is the first (even lines) or second (odd lines) of an image. An aside: about a year ago, the #stella community discussed this very aspect of TV images, and if it would be possible for the Atari to exploit this to generate a fully interlaced TV frame - and, in fact, it is possible. So some 25 years after the machine was first released, some clever programmers discovered how to double the resolution of the graphics.

 

Back to basics, though. We just worked out that a single frame on a TV is 262.5 (NTSC) and 312.5 (PAL) lines deep. And that that extra .5 scanline was used to tell the TV if the frame was odd or even. So the actual depth of a single frame is 262 (NTSC) and 312 (PAL) lines. Now, if TV's aren't told that a frame is odd, they don't offset the first scanline by half a scanline's depth - and so, scanlines on successive frames are exactly aligned. We have a non-interlaced image, displayed at 60Hz (NTSC) or 50Hz (PAL). And this is the 'standard' format of an Atari 2600 frame sent to a TV.

 

In summary, an Atari 2600 frame consists of 262 scanlines (NTSC) or 312 scanlines (PAL), sent at 60Hz (NTSC) or 50Hz (PAL) frequency. It is the job of the '2600 programmer to make sure that the correct number of scanlines are sent to the TV at the right time, with the right graphics data, and appropriate control signals to indicate the end of the frame are also included.

 

http://www.atariage.com/forums/topic/27187-session-2-television-display-basics/

[SeaGtGruff]

The problem with the Stella programmers guide is that it does not use the correct terms for defining the TV signal. The 2600 generates a display at 60 fields per second for NTSC. To the TV its interlaced at 30 frames per second. TIA must account for odd/even fields per frame. If it didn't it wouldn't work because it wouldn't be NTSC.

You need to distinguish between the standard/ideal/to-spec NTSC signal and the TIA signal.

 

The TIA does *not* have to account for odd/even fields per frame. In fact, the TIA doesn't know squat about fields, frames, and lines per screen, because it doesn't auto-generate the vertical blank interrupt-- the human programmer must tell the TIA when to turn on blanking, when to turn on the vertical sync signal, when to turn off the vertical sync signal, and when to turn off blanking.

 

It is entirely up to the human programmer whether the TIA will generate an interlaced or a progressive display. The "default" practice is to generate a progressive display with (ideally) 262 lines per screen. And since the display is progressive, it's perfectly acceptable to call it a "frame" instead of a "field." In fact, "field" would imply that it takes more than one of them to make a full frame, so "field" would arguably be misleading at best, if not flat-out incorrect. (On the other hand, I sometimes refer to a single screen as a "field" if I'm using 30-Hz flicker to combine two screens for the purpose of color mixing or sprite multiplexing, such that it takes two consecutive screens to display the "complete" image.)

 

Of course, an interlaced display *is* possible on the 2600, but even so, it could be argued that it still isn't an "NTSC" signal per se, because it doesn't conform to the NTSC specifications. Rather, it's an "NTSC-like" signal, or "NTSC-ish." The NTSC signal has 227.5 subcolor carrier cycles per scan line, but the TIA outputs 228 subcolor carrier cycles (or "color clocks") per scan line. As they say, "This changes everything!" If 1 TIA-generated scan line doesn't equal 1 NTSC-spec scan line, then there's no way that 262.5 TIA scan lines can equal 262.5 NTSC scan lines. It doesn't matter whether the TIA is programmed to output a progressive display or an interlaced display-- the line rate, field rate, and frame rate will all be off from NTSC specs. Yes, they'll be within tolerance, because the tolerance is so... tolerant. But they won't be (and cannot be) in conformance with the specs.

 

Michael

[GroovyBee]

We'll have to agree to disagree. If you look at NTSC TV specifications its 30 frames per second. With the field rate being twice that. See :-

 

http://www.maxim-ic.com/appnotes.cfm/an_pk/734

[SeaGtGruff]

We'll have to agree to disagree. If you look at NTSC TV specifications its 30 frames per second. With the field rate being twice that. See :-

 

http://www.maxim-ic.com/appnotes.cfm/an_pk/734

If you want to be specific, 30 frames per second and 60 fields per second apply to the old monochrome or black-and-white NTSC specs. The color NTSC signal has a slight reduction-- approximately 29.97 frames per second and approximately 59.94 fields per second. The exact numbers are 30 * 1000 / 1001 frames or 60 * 1000 / 1001 fields per second.

 

However, that has nothing to do with the fact that the TIA does not normally output interlaced fields, but instead (normally) outputs progressive frames, with each frame (ideally) containing 262 lines per frame. If you want to create interlaced frames with the TIA, you have to specifically program a display kernel to do that.

 

Likewise with the CTIA and GTIA chips on the Atari 8-bit computer-- you have to specifically program a display to do that (as Rybags recently succeeded in doing). It's easier to do this with the TIA because the Atari 2600 doesn't automatically generate the vertical sync the way the Atari 8-bit computers do.

 

As I said previously, the TIA (as well as the CTIA and the GTIA) output 228 color subcarrier cycles per scan line. (I can't believe I called them "subcolor carrier cycles"-- that was an obvious typo, but I can't believe I made the same typo twice in the same sentence!) This is one part of what makes the TIA's signal different than the NTSC specs. Another part is the lack of any "pre-equalizing" and "post-equalizing" pulses, as well as the lack of any interlacing (without special programming).

 

The fact that the NTSC signal has 227.5 color subcarrier cycles per line (which I'll henceforth call "color clocks" since that's how we refer to them on the Atari), and 525 lines per frame, gives rise to the NTSC "superframe," which contains four consecutive fields or two consecutive frames.

 

If we number the lines 1 through whatever in the order they're generated-- such that the first field consists of lines 1 to 262.5, and the second field consists of lines 262.5 to 525-- and say that line 1 begins with a whole color clock, then each odd-numbered line starts with a whole color clock and ends with a half color clock, whereas each even line starts with a half color clock and ends with a whole color clock. Since a "color clock" is actually a time measurement, and what we're really talking about are cycles (ideally a sine wave), it means that the color signal is shifted 180 degrees on alternating lines (the following represent sine waves):

 

/\/\/\/\/\/\.../\/\ = odd lines

\/\/\/\/\/\/...\/\/ = even lines

 

(In reality, the peaks and valleys of these waves will depend on the color being displayed, but the "ideal" wave-- which I suppose is represented by the colorburst-- is shifted in phase by 180 degrees, or half of a cycle, from line to line.)

 

Let's say that frame 1 starts with line 1 and ends with line 525, frame 2 starts with line 526 and ends with line 1050, etc. That means frame 2 starts with the color signal shifted 180 degrees from frame 1, since frame 1 starts with an "odd" line and frame 2 starts with an "even" line. It takes four fields or two frames for the color signal at the beginning of the frame to get back in sync, so these four consecutive fields, or two consecutive frames, are referred to as a "superframe."

 

On the Atari, *every* scan line begins with the color signal lined up in the same phase as the previous scan line-- there is no 180-degree shift from line to line as with the NTSC signal, hence there is no need to refer to a "superframe" with the TIA.

 

The NTSC signal and TIA signal both contain the same number of color clocks per second-- about 3579545.45 (repeating 45)-- but the difference in color clocks per line means that they have different line rates. The NTSC signal has about 15734 lines per second, whereas the TIA signal has about 15699 lines per second (actually closer to 15700 lines per second).

 

The NTSC signal has about 29.97 fields per second, or about 59.94 frames per second, whereas the ideal progressive TIA signal has about 59.92 screens per second (which we can refer to as frames because there's no interlacing)-- although the exact number of screens per second depends on how many lines are drawn per screen by the game program. A lot of the old games drew a lesser or greater number of lines per screen than the 262 ideal.

 

If we program the game to draw an interlaced display with 262.5 lines per field and 525 lines per frame, then there would be about 59.81 fields per second, or about 29.90 frames per second-- again, different from the NTSC signal.

 

Anyway, the TIA is incapable of outputting a "true" (by-the-specs) NTSC signal, mainly due to the difference in the color clocks per line, but also partly due to the lack of the "pre-equalizing" and "post-equalizing" pulses. The NTSC specs allow for some degree of variance in the timings, and most (traditional) TV sets were very forgiving of signals that don't conform precisely to the NTSC specs-- but based on what a lot of people have been posting, some of the more modern TV sets seem to be less forgiving, which is why they sometimes have trouble displaying the Atari's game screens. Fortunately, my HD Samsung LCD TV *does* display the Atari screens without any "problems," although it converts the picture into an interlaced display. I think that's pretty neat, because it helps to remove any 30Hz flicker. But I suppose I should be annoyed that it doesn't display the Atari's screens "correctly."

 

On the other hand, I bought a "WinTV-PVR" for my computer, and when I hook my Atari up to it I either get a monochrome display (if I feed the Atari through my VCR first), or no display at all (if I hook it up directly). I'm guessing this might be due to the difference in the number of color clocks per line, since with a standard NTSC signal the color subcarrier cycles are shifted 180 degrees from line to line, whereas they are always lined up the same on the Atari. In other words, I'm guessing the monochrome display (whenever I do manage to get a display) are comparable to the problem wherein a PAL Atari will display a monochrome screen if the game draws an odd number of lines per screen, thereby causing the color phase to get out of alignment from screen to screen with what the PAL TV set is expecting.

 

Michael

[+grafixbmp]

Case in point... I feel a hefty portion of atari enthusiast take trivial aspects of the 2600 way too seriously. I mean even newcomers are only interested in making childhood dreams come true. Just to put something on screen and say "I did that. Ain't it cool?" is one of the main staples of programing the 2600. Am I wrong? I only wanted to splt the prudent aspects from the mind numbing,trivial jargon out there so there would be less intimidation. But lets face it, as long as Atari fanatics bicker over what newcomers may perceive as trivial and not paramout to the final outcome of learning how to program, Atari 2600 may just die off as a forgotten hobby in the next 20-30 years. Kudos to Andrew Davie and a select few others out there who, for lack of a better way to put it, "dumb it down" for the layman, newbie wanting to relive their childhood.

 

Just forget it. Compiling 2600 info is a waste of time when fanatics are out to get every single indiscretion someone makes. Reminds me of Church snobs who think they are better than you.

[Thomas Jentzsch]

You could simply stop reading when it becomes uninteresting instead of complaining that some people are talking about stuff you don't want to know.

[GroovyBee]

When you use the words "definitive" and "inclusive" to describe technical documentation you will automatically raise the level of critique that your material will receive from any interested parties. The "it has to be right" mantra just kicks in.

 

To say that something is both "definitive and inclusive" is subjective and based on your own knowledge and personal experiences. Your definition of "the definitive 2600 documentation" is almost certainly different to Michael's, Thomas's and my own (however I admit I'm no 2600 expert by any means).

 

To be brutally honest I don't think that you can write a fully inclusive resource just by regurgitating and collating information from multiple sources. You need many years of practical experience gained from doing it the "hard way" to fully understand and appreciate the internals of the machine and its limitations. That practical experience will help you sort the wheat from the chaff.

 

If you come back to this project after a few completed games or technical demos you'll almost certainly see things much differently.

[SeaGtGruff]

Just forget it. Compiling 2600 info is a waste of time when fanatics are out to get every single indiscretion someone makes.

I would like to see you continue, but I don't think this is something you can do alone. At one time I wanted to create a definitive guide, too-- but there's a lot to cover, and I have a job. That's why I thought it would be cool to create a wiki site, so anyone who's interested can contribute. I think a lot of people were hoping that AtariAge can host a wiki, which would be great if or when it happens, because there are a lot of knowledgeable people here who could contribute to it. A well-written and well-designed (well-organized) wiki could be as general or as detailed as the reader wanted it to be, because the reader could just read the basics and skip the technical details, or delve deeper into the technical details if desired. If someone wanted to get into the finer points of the TV display-- including things like colors, and converting from YIQ/YUV colorspace to RGB colorspace-- then they could. If someone wanted to read up on bankswitching, they could. Just follow the links to deeper levels of detail. Anyway, I'm sorry you got discouraged, and I hope you regroup and reconsider.

 

Michael