![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Atari 2600 programming was NUTS.
Jun. 12th, 2013 06:51 pmLis has been reading Racing the Beam: The Atari Video Computer System, and reading particularly mind-blowing passages to me.
The Atari 2600 was designed to work with CRT televisions. A CRT paints a beam across the screen, then goes back to the beginning of the next line, then paints the next line, goes down one, and keeps doing that until the bottom of the screen, then goes back up to the top. An NTSC television has 525 scan lines, and refreshes sixty times a second.
The Atari 2600 spends about two-thirds of its time following that beam along and changing its color as it goes. It does all its other gameplay calculation during the other third of the time: when the beam is going back to the beginning of the line, and when the beam is going from the bottom of the screen to the top. (Also, there is a little extra time, because only 483 of the 525 lines are actually visible.) Hence, "racing the beam" -- the Atari had to be ready to tell the CRT beam what to do.
The 2600 can tell how high up or down an object is, because it is on whichever of those 525 vertical lines it is. But it can only tell how far left or right a thing is by, well, "dead reckoning," as sailors used to call it. It only knows how far left or right something is by timing how long it's been drawing the beam on that raster line.
The Atari doesn't actually have pixels. A pixel is a point on a Cartesian plane. Well, not a "point", because a pixel actually DOES have area, but it's got a specific x and y coordinate. The Atari doesn't. It's got a de facto y position because of its raster line, but its x position is actually just timing. You can approximate a pixel by figuring out what the minimum number of clock cycles it would take to change beam color, so it's similar. But it's somewhat different down in the guts of the machine.
On the other hand, collision detection is EASIER in the 2600 than in modern machines. If the beam is getting two different instructions to change its color, that's a collision. Nowadays, you need to approximate hitboxes around the objects you want to detect, then make specific comparisons between the hitboxes -- on the Atari, if the graphics are trying to draw two things simultaneously, that's it.
The chapter on ADVENTURE is just really nuts. Warren Robinett was clearly insane to do this. The Atari was absolutely not set up to do anything remotely like it. I mean, you can move vertically from one screen to another -- and maintain your horizontal position, even though, as previously mentioned, the Atari has no actual inherent idea of "horizontal position."
The Atari 2600 was designed to work with CRT televisions. A CRT paints a beam across the screen, then goes back to the beginning of the next line, then paints the next line, goes down one, and keeps doing that until the bottom of the screen, then goes back up to the top. An NTSC television has 525 scan lines, and refreshes sixty times a second.
The Atari 2600 spends about two-thirds of its time following that beam along and changing its color as it goes. It does all its other gameplay calculation during the other third of the time: when the beam is going back to the beginning of the line, and when the beam is going from the bottom of the screen to the top. (Also, there is a little extra time, because only 483 of the 525 lines are actually visible.) Hence, "racing the beam" -- the Atari had to be ready to tell the CRT beam what to do.
The 2600 can tell how high up or down an object is, because it is on whichever of those 525 vertical lines it is. But it can only tell how far left or right a thing is by, well, "dead reckoning," as sailors used to call it. It only knows how far left or right something is by timing how long it's been drawing the beam on that raster line.
The Atari doesn't actually have pixels. A pixel is a point on a Cartesian plane. Well, not a "point", because a pixel actually DOES have area, but it's got a specific x and y coordinate. The Atari doesn't. It's got a de facto y position because of its raster line, but its x position is actually just timing. You can approximate a pixel by figuring out what the minimum number of clock cycles it would take to change beam color, so it's similar. But it's somewhat different down in the guts of the machine.
On the other hand, collision detection is EASIER in the 2600 than in modern machines. If the beam is getting two different instructions to change its color, that's a collision. Nowadays, you need to approximate hitboxes around the objects you want to detect, then make specific comparisons between the hitboxes -- on the Atari, if the graphics are trying to draw two things simultaneously, that's it.
The chapter on ADVENTURE is just really nuts. Warren Robinett was clearly insane to do this. The Atari was absolutely not set up to do anything remotely like it. I mean, you can move vertically from one screen to another -- and maintain your horizontal position, even though, as previously mentioned, the Atari has no actual inherent idea of "horizontal position."