Oh man, having tried Atari 2600 programming myself, that article misses some of the more crazy points.
The playfield for example, has to be drawn the same way as the sprites, updating the necessary 20 bits each line right before it gets scanned onto the screen. And yes, only 20 bits, even though the 2600 playfield is 40 pixels wide. This is because those same 20 bits are drawn TWICE, once on the left side then again on the right, though there's an additional bit you can set to mirror the bits on the right side, plus clever programmers could update those 20 bits in the exact machine cycle necessary so that the right side is a different 20 bits than the first. Few games did this though.
One thing that was also insane is that you can't simply set a variable and set an X coordinate of a sprite, line or ball. Y coordinate is easy, just choose which scanline to start drawing from. But to set an X coordinate you had to use a special command which allowed setting a sprite position within 16 pixels of the current colour clock. So to set an X coordinate, you had to perfectly time sending the appropriate command to the CPU. There was no margin for error in this, and since none of the CPU commands take less than 2 machine cycles, you had to use combinations of 2-cycle and 3-cycle commands to time this out. x_x;;;
The saving grace of 2600 programming is that the system had built-in hit detection between all entities, with the appropriate bits set during the actual drawing of the pixels, resulting in pixel-perfect collisions.
TBH though, I think every generation of computing and gaming has its strong and weak points, so I think back to all of them depending on the mood I'm in. ;)
--- Kris Asick (Gemini)
--- Pixelmusement Website: www.pixelships.com
--- Ancient DOS Games Webshow: www.pixelships.com/adg
