Hacker News Reader

Comment by rsync | Hacker News Reader

I'm surprised this article does not discuss one of the most fundamental constraints facing all Atari 2600 games - the fact that the machine had no framebuffer and every programmer had to "race the beam".

You had to keep track of where the light gun of the tv was at every moment and if your program took too much CPU time to ... compute things ... you would miss changing colors, etc., as the beam went past ...

This is why all Atari 2600 games (like Pac Man) have graphics that seem weirdly, horizontally distended - the CPU wasn't fast enough to change color before the light gun got to the next pixel ...

All of this is beautifully explained in the wonderful book _Racing the Beam_ which is part of the MIT platform series and is one my favorite books on any subject.

View on HN

The 2600, called the VCS (Video Computer System) when I was a kid, offers three kinds of graphics.

Background. This can be changed by the CPU, but as mentioned, the CPU is not fast enough to do that per pixel. It is often changed per scan line though.

Playfield. These are 40x1 pixels, that cab be mirrored and otherwise manipulated. Call this a scanline buffer, or partial one, depending on what one wants to do.

If you want symmetry, 2 and a half bytes of buffer has you covered. Otherwise, you need to load different pixels for the other side of the screen.

Playfield is monochrome. One bit per pixel. The colors can be changed ar any time, and are often changed per scanline.

Sprites. There are two "balls" which are two bit wide strips that can run the length of the screen vertically. It is up to you to put the right pixels and position in place for every scanline.

And two player sprites, same as the balls, 8 bits wide.

The color precision of the system is basically one NTSC color clock, which is roughly 160 pixels, or positions to which the sprites can be drawn.

This generally means pixels at least twice as wide as they are tall. Other graphics can be much wider.

A typical game will contain a complicated kernel that is responsible for the graphics. Game logic and other tasks happen during the blanking times.

System resources:

128 bytes of RAM

4k ROM

Sound and game controller I/O, which is actually fairly robust, supporting digital direction input, up to 4 paddles (pots that can indicate a position), and some buttons.

I do not recall having ever seeing it, but a nice analog joystick is supported as are rotary encoders, and various button and stick combinations.

Pixel perfect hardware collision detection

And sprite / playfield priority. The cool, invisible room in ADVENTURE comes to mind.

The NES didn't have a framebuffer either, but its sprite hardware was a lot more capable. OTOH, Atari had a patent on synchronizing the cpu with a scanline, so if you ran out of stuff to do during a scan line, you could wait and start again knowing exactly where the beam was. For the NES, Nintendo didn't build that, so if you do want to do something tricky based on where the beam is, you'd need to work a lot harder (or have something to help you in the cartridge hardware)

> The NES didn't have a framebuffer either

The NES does have two nametables that perform a similar role, though. Instead of storing a 256x240 array of pixels, they store a 32x20 array of tile indices, each describing an 8x8 pixel tile. Once the CPU has written to the nametables, it can do something else while the PPU draws an entire frame.

Whereas on the 2600, the CPU needs to step in every few scanlines or it can't draw a 2D image at all!

On the VCS, you are supposed to set up a scanline, which will be then drawn by the graphics chip (TIA) automatically. Manipulating this setup on the fly as in "racing the beam" is really more exploit territory. The vertical aspect of the image is left to the program(mer), but the VCS gives you a helping hand in form of a critical feature: The graphics chip can halt the CPU until it has reached the start of a new scanline. So your program can sleep and will be woken up precisely at the beginning of the horizontal blank interval. (The 6502C "Sally" MPU used in later Atari 8-bit computers had a similar feature: an extra signal to pause the processor, when pulled low.)

> The graphics chip can halt the CPU until it has reached the start of a new scanline.

This seems similar to the horizontal-blank interrupt that's available on later machines, where it's widely used to change color palette or scroll values part-way down the screen. Because it’s an interrupt, though, the CPU doesn’t have to wait for it and can do other things during the active display period. As toast0 says, on the NES this interrupt is usually provided by hardware on the cartridge, but other 8-bit consoles (including the Game Boy and Master System) support it natively.

> Manipulating this setup on the fly as in "racing the beam" is really more exploit territory.

Even on the NES, "racing the beam" is not unheard of. For example, Marble Madness uses mid-scanline changes to draw text boxes in the middle of the level graphics. For part of the display it uses timed code to switch from the level nametable to text and back again within each scanline.

> a 32x20 array of tile indices

Oops, that should say 32x30.

Yes, it's all very stressful to consider from our modern cushy full-screen 32-bit 8-megapixel triple-buffered world. :)

That said, a tiny nit: televisions don't have light guns, they have electron guns. The light is created by the phosphor layer on the inside of the tube. Chances are you know this from the rest of the comment, of course.

I didn't think to include that (I'm the author) 'cause that constraint is more about the difficulty of timing instructions, rather than saving memory, which is the main reason Crane implemented the LFSR that he did.

But yeah I read that book and it started my interest in this topic. Super interesting stuff.

Reply on news.ycombinator.com