12

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.

Brian H
  • 60,767
  • 20
  • 200
  • 362
  • The vertical resolution looks about the same to me, but the playfield appears to have a higher horizontal resolution. – snips-n-snails Mar 27 '18 at 04: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

2 Answers2

20

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?

Performance.

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.

Raffzahn
  • 222,541
  • 22
  • 631
  • 918
  • 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 00:05
  • For hyper-flimmering, check out Pac Man. But that's [partly] flimmering for a plot reason. – Tommy Mar 27 '18 at 13:33
  • Pac Man suffers the same frame flimmering as Asteroids. Here each ghost is displayed on a seperate frame (IIRC). So every ghost is only displayed 1/4th of the time, making them less solid more ... well, ghostly. Much like the asteroids in Asteroids. – Raffzahn Mar 27 '18 at 14:11
  • Some games use flicker to multiplex conceptually-similar sprites. Tod Frye's Pac-Man cartridge for the 2600 did this with the ghosts. Asteroids, however, alternates between two separate display routines, one of which can accommodate one upward-flowing and one downward-flowing set of asteroids, with at most one of each type per line (but supporting many objects of each type on the screen), and the other of which can handle one player ship, one UFO, two player shots, and one UFO shot, at arbitrary vertical positions (mapping objects in fixed fashion to the hardware's five sprites). – supercat Mar 27 '18 at 15:33
  • It might be worth noting that when using a CRT, scan lines on alternate fields will only be staggered if the fields in question have slightly different vertical sync pulses. Nearly all Atari 2600 games generate identical sync pulses on every 60Hz field, and when using a CRT the scan lines on each field will overlay each other unless alternating fields have content which is so bright as to over-tax a weak high-voltage supply. – supercat Mar 27 '18 at 15:39
5

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.

Tommy
  • 36,843
  • 2
  • 124
  • 171
  • 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 00:24
  • 1
    @Raffzahn one line of background is stored. The TIA outputs it again and again until I post a new one. If I post once per frame, I get a vertical resolution of 1. If I post once at the start of the frame and once halfway through the frame, I get a vertical resolution of 2. If I post every line I get a resolution equal to the TV signal. So I have a huge amount of control over my output resolution. In exactly the same way that e.g. one of the MC6847 output resolutions is 128x96. Via a valid TV signal. – Tommy Mar 27 '18 at 01:28
  • @Raffzahn so e.g. if I wanted to fill a 200-line portion of the frame, I could update every second line for the top 50 lines. Then every third for the remaining 150. That would give the bottom three quarters of the display only two-thirds the vertical resolution (if talking ppi) of the top quarter. – Tommy Mar 27 '18 at 01:37
  • No. You're still outputing 262(312) lines. Just because they all contain the same value does't change the resolution. What you are talking bout is the effort spend by the CPU to load andchange the values across a screen, not the pictures resolution. Otherwise a cleaned screen on any machine would have a resolutipn of 1x1 ... lol – Raffzahn Mar 27 '18 at 04:41
  • @Raffzahn it exactly means the graphics you are displaying are at a different resolution. Again, check out the data sheet for the MC6847, or for any of thousands of other early video chips to see this very normal usage. For an arbitrary second example, look up absolutely any reference on the Intellivision. What does http://www.intellivision.us/faq.htm#_Toc140592019 say the resolution is? What does Wikipedia say? Your attempted redefinition of the term is simply incorrect. – Tommy Mar 27 '18 at 11:09
  • @Raffzahn I understand the complete panoply of TV signals, from QAM up. I've provided the evidence that the world doesn't use your definition of 'resolution'. That should be obvious — e.g. magazines print at a minimum of 1200DPI. Does that mean the first Atari 2600 screenshot every printed at 2" or so is the first ever 4k game? If you genuinely think this conversation is about a misunderstanding of how TVs work then you're really not following the discussion. I'm arguing that resolution means "pixel density of the source image". You're falsely conflating that with the viewing medium. – Tommy Mar 27 '18 at 13:10
  • Speaking of following, you're aware that your answer is not relatd to the question asked? Much like your non related comments. It would be a good thing if you could step down and think for a moment what this is about. Oh, and BTW, QUAM coles rather late when discusing video, so check your wording :)) – Raffzahn Mar 27 '18 at 13:20
  • 1
    @Raffzahn it is entirely related to the question asked, which is about multiple vertical resolutions within one game. I've therefore explained how a 2600 game can have multiple vertical resolutions within one game. Both myself and the question commenter have taken it to be exactly the same meaning. I'd also be interested to know what here you think is "pseudo knowledge". No need to check my wording on QAM, as it defines the instantaneous encoding of colour non-SECAM television. Syncs and field timings wrap it. They're at a higher level. Don't confuse chronology with hierarchy. – Tommy Mar 27 '18 at 13:30
  • Just the question wasn't about a possibility of varying resolution, it was about why asteroids displays the way seen on the setup Brian uses. And no, syncs are on a lower level. they define the fields in the first place. without syncs not picture and later on no colour. – Raffzahn Mar 27 '18 at 13:35
  • 1
    @Raffzahn I'll quote it directly for you: "How does Atari 2600 TIA display multiple resolutions in Asteroids? ... 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." If you don't think that's about "a possibility of varying vertical resolution" then this is the basic source of disagreement. And, frankly, I'm at a loss in trying to find a way to understand your conclusion. – Tommy Mar 27 '18 at 13:38
  • Hilarious sidebar: see https://www.youtube.com/watch?v=eiXaZtG89EA for an earlier version of my (still not great) 2600 emulator, where colour is being correctly decoded but vertical sync is way off. It was actually a PIA timer error, the pretend CRT is flywheel syncing as it should, but I thought it was a funny complement to the bottom-up versus top-down on video generation since apparently I did favour getting colour to getting syncs... (though: we don't actually seem to disagree, since I describe QAM as the final thing to understand, and you describe sync as the first thing to understand) – Tommy Mar 27 '18 at 13:49
  • But then your wording of 'from QAM up' doesn't work out. You can't build a house starting with the roof (although it has been done, but thats a different story). And no, it's not about varying some resolution, this is about interlacing. – Raffzahn Mar 27 '18 at 14:01
  • @Raffzahn you've assumed it's about interlacing based on the image. That's not in the text. That's your independent detective work, reading around the question rather than constructing it literally. I don't mean to argue that you're wrong to draw that conclusion, but it is false to say that the question doesn't ask about vertical resolution or that an answer about vertical resolution is inappropriate. And re: QAM, you're arguing semantics on bottom-up versus top-down. I don't intend to continue that part of the discussion. – Tommy Mar 27 '18 at 14:11
  • He describes what he seen and what his setup is. I just focused on what he describes and if the effect is there. So no need for any interpretation. First step when analyzing an issue is looking at the setup. And this means all components, not just what a creative person can do with the TIAs minimal hardware under some circumstances. Everyone aware of the way VCS games are made and how the setup described works can see the issue. Don't you think so? – Raffzahn Mar 27 '18 at 14:35
  • 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
  • @wizzwizz4 will seek to do so after lunch; thank you for the validation that this answer is an appropriate response to the question asked and for the constructive criticism. – Tommy Mar 27 '18 at 15:50
  • 2
    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
  • @supercat No idea what your ranting about. – Raffzahn Apr 23 '18 at 22:28
  • 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 '21 at 21:07