There is probably an easy explanation for this based on some facet of how the TIA generates the display. As is readily visible in the image taken from a real Atari 2600 displayed on a modern LCD, the vertical resolution of the score area (where you see "13") is higher than the vertical resolution of the game play area.

enter image description here

Details: 4-switch "Darth Vader" Atari 2600 with Asteroids cartridge is modified for S-video out and connected to the S-video input of a Sony DSC-1024 studio scan converter. Output of the DSC is 48kHz VGA (1024x768). This is connected to a VGA-HDMI encoder and then output to the LCD as HDMI and displayed with the 4x3 aspect ratio enabled on the LCD.

  • The vertical resolution looks about the same to me, but the playfield appears to have a higher horizontal resolution. Mar 27 '18 at 4:53
  • 1
    @traal I guess it's likely that the score is part of the playfield, so a fixed 40px horizontally, but the asteroids are double-sized player sprites, so twice the horizontal resolution and placeable at any quarter of a playfield pixel.
    – Tommy
    Mar 27 '18 at 13:17

There is probably an easy explanation for this based on some facet of how the TIA generates the display. As is readily visible in the image taken from a real Atari 2600 displayed on a modern LCD, the vertical resolution of the score area (where you see "13") is higher than the vertical resolution of the game play area.

No, it isn't.

Atari 2600 [...] is modified for S-video out and connected to the S-video input of a Sony DSC-1024 studio scan converter. Output of the DSC is 48kHz VGA (1024x768). This is connected to a VGA-HDMI encoder and then output to the LCD as HDMI [...].

You get fooled by your converting hardware. Your hardware assumes this is a real TV signal, consisting of two half frames with half the vertical resolution each. This is called interlaced video. The first frame supplies all odd lines, the second all even lines. The first one is also marked by a different timing. Your hardware always connects two half frames into one (*1) - after all, your new 'progressive' display has at least doubled the vertical resolution.

The Atari Hardware doesn't do half frames, but always first frames, giving a real 60 Hz display with half the lines. A real (analogue) TV does just go by the syncing and displays it the way the VCS sends it.

Your 'more' sophisticated hardware looks for a standard TV picture with interlaced frames and puts always two into one new picture to be displayed.

Objects that are drawn each picture now get their lines 'doubled', which makes them look solid on your hardware, while objects only drawn in one frame will be only displayed every other line, making it look spaced.

Bottom line: With your setup the signal gets not only displayed much sharper, but also timewise integrated (deinterlaced). Deinterlacing is a great thing for moving pictures, but not so much for TV Games using effects only possible on a 'real' TV.

Now, why does the VCS display objects every other frame?


While simple games with a low number of objects and/or simple computing needs are fast enough to display every object on a line in every frame. TV uses 30(25) frames per second, displayed as 60(50) half frames. Simple games now display the same picture in every frame, ignoring what 'half' it is. When such a game output is converted by your hardware it displays solid objects.

More complex games, especially if they want/need to display more objects in a line than possible, split them up between frames. Here the first frame gets some objects while others are displayed the second one. On a real TV (CRT) this still gives a great and smooth picture. Only a little bit dimmed. Your digital setup now does not display these two pictures after each other, creating the same effect, but puts them into one frame.

With the objects spread out over two (half) frames the number of items in one line can be doubled. There are even games known that split objects into three (half) frames. Fine (or better acceptable) on a TV, but your setup might display them in a rather weird flickering fashion.

Yes, splitting objects adds a little flickering, but it's the very same every classic TV picture has, so nothing out of the ordinary. Even with three frames for one picture it is playable.

The by now classic book "Racing the Beam"(*3) uses Pac Man as an example for this technique, as it was eventually the first game to do so. In certain situations all 4 ghosts may run in the same horizontal line. Displaying 4 sprites in the same line is something the VCS couldn't do by default. There are only two 'Player' objects. Since Pacman could also be on the same line, he always got one, the other got shared by all 4 ghosts.

Asteroids had the same problem. If you look close, there can be up to 4 asteroids in one line, plus the ship. Much like Pac-Man. They did eliminate the players need for a 'Player' object by using the background graphics for the ship, so now 4 asteroids could share the two objects by drawing two in each frame.

And why are the top lines displayed in both frames?

Cause there is nothing else to do. Generation of these big numbers is solely done by the background graphics. That's just 3 bytes to load every line - or more like every 4th line or so. So there is no time constraint.

Also having bold static elements at the top or bottom makes games with lots of objects more acceptable to the human eye. But that's a different story.

So, why is it still playable?

Same way as on analogue TV - the human eye is way too slow to really separate the frames. It just gets more and more flashy. In fact, the way your new hardware composes the always two into one does reduce the effect by half. Games like Pac-Man (and Asteroids) will look way less annoying than on a classic screen. Except for the black lines that is.

BTW: Thanks for your detailed description of the data path, as this helped a lot to identify the problem.

*1 - There is a whole bunch of additional computing within the deinterlacer to make camera swipes work.

*2 - In fact, much of the hassles of early digital (LCD/Plasma) creation where around finding algorithms to make the displays more 'blurry'

*3 - A must read for anyone. While somewhat technical, it's written for the average reader and quite entertaining. Go and get it.

  • If my converting hardware is responsible, why does it only do what you claim in the score area and not the game play area?
    – Brian H
    Mar 26 '18 at 20:28
  • 2
    It does it in both areas. The score area is just displayed the sam in every frame, while the game objects are displayed in altenating frames. It's all about the problem of converting a time spacial signal into a single picture - maybe checkup interlacing/deinterlacing in Wikipedia.
    – Raffzahn
    Mar 26 '18 at 20:50
  • BTW; @BrianH, dependign on the game, you might be able to even see and indenify each items frame. Just look where you can move multiple ojects horizontaly next to each other.
    – Raffzahn
    Mar 26 '18 at 20:53
  • 1
    Oh, I see we've decided to answer effectively different questions. This is definely why you see gap lines on the moving items but not the score. I think I've been too literal in thinking of resolution as number of different bits of source data in a region rather than number of samples.
    – Tommy
    Mar 27 '18 at 0:05
  • 1
    +1 for use of "flimmering" (and for getting what I'm sure is the right explanation).
    – TripeHound
    Mar 27 '18 at 8:48

On the 2600 vertical resolution — the number of unique pixels shown in a column — is the game author's choice. It can be anything less than the upper bound imposed by the video signal.

The 2600 has no DMA. It's TIA video chip cannot fetch anything. The entire display is push. The CPU pushes a new line of background and/or it pushes a new line of sprite data whenever it chooses. That line is then repeated until it receives something else.

So it's perfectly possible to push any vertical resolution less than or equal to the number of lines in the display, and there's no need to be consistent across the frame. Every 2600 game consists primarily of a display kernel, which is a list of things for the CPU to push to generate a frame.

The programmer is even responsible for ensuring proper entry and exit from vertical sync which in practice leads to quite a lot of variability in the total number of lines per frame — despite Atari pushing for a standard 262, commercial NTSC titles of the era produce anything from 238 lines/frame to 290, neither of which is likely to be compatible with the complete range of televisions. A programmer could in theory produce interlaced video, making this a discussion of fields rather than frames, but no commercial titles did.

Conversely the only reason you'd likely see a difference in horizontal resolution is that the different layers are different resolutions. The background is 40 pixels across; sprites can be up to four times as dense, though you can display them at double or quadruple size, possibly reducing them to the same pixel density as the background.

  • Not raly. As the output hast to be a valid TV signal. The vertical Resolution is always the number of lines for a half frame. It can't be more o less. Otherwise the TV won't sysnc and display. Ofc. the programmer can decide to make lines without visible content - or display twice the same content. Still that doesn't change the resolution.
    – Raffzahn
    Mar 27 '18 at 0:24
  • 1
    @Raffzahn, cc Tommy: Both of these are partial answers to the question. I think you should both emphasise the effects that you're talking about near the beginning of your answers (i.e. that Raffzahn is talking about the gappy effect and Tommy is talking about the relative blockiness of the score).
    – wizzwizz4
    Mar 27 '18 at 15:46
  • 1
    Answer updated; though for the record I'm still unclear how somebody can claim that the previous wasn't appropriate with a straight face.
    – Tommy
    Mar 27 '18 at 17:23
  • 1
    @Raffzahn: If a cartridge outputs a consistent number of lines per frame within the range ~256-270, most CRT-based television sets will display a stable picture with that number of lines (not twice that many). If the number of lines varies, the picture may expand or contract, but the exact amount may vary from CRT-based set to another.
    – supercat
    Apr 23 '18 at 21:48
  • 1
    The TIA is always outputting lines, but has to be told when to emit VSYNC, which according to the Stella Programmer's Guide, has to be at least 3 scan lines. Without this your picture will roll on a CRT like the vertical hold is off. You normally want to stop emitting meaningful visual data after line 200 but nothing stops you from telling the TIA to put non-blank emitting stuff in the overscan area; just no guarantee that it will be visible.
    – LawrenceC
    Jul 16 at 21:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.