A modern computer keeps a complete picture of the screen in memory and sends it to the display many times a second. The Atari 2600 could not do that. It had 128 bytes of RAM, far too little to hold even a single screen, so its programmers built each picture one line at a time while the TV’s electron beam was drawing it. Programmers called this “racing the beam”, and it explains most of what you see when you play a 2600 game: the chunky walls, the flicker, the stripes of colour and the mirrored mazes. Here is how it worked, with games you can load on this site to see each trick for yourself.
What a 2600 programmer had to work with
| Part | What it offered |
|---|---|
| Processor | MOS Technology 6507 at about 1.19 MHz, a cut-down 6502 with no interrupts |
| RAM | 128 bytes, shared by the game and the processor’s stack |
| Cartridge ROM | 2 KB in the earliest games, 4 KB as standard later, more with bank switching |
| Graphics chip | The Television Interface Adaptor (TIA), designed by a team led by Jay Miner, with no frame buffer |
| Sound | Two channels, each with 32 pitch settings and 16 volume levels |
When the console was designed in the mid-1970s, memory was expensive, so the designers left out screen memory altogether. The TIA only holds the data for the line it is drawing right now. Warren Robinett, who wrote Adventure, put it plainly in a lecture on the hardware: unless the processor changes something, the chip “generates the same line again and again”.
One frame, 262 lines
Atari’s own Stella Programmer’s Guide, written by Steve Wright in 1979, sets out the timing. On an American (NTSC) television, one frame is 262 lines, drawn 60 times a second:
- 3 lines of vertical sync, which tell the TV to start a new picture
- 37 lines of vertical blank, while the beam returns to the top
- 192 lines of actual picture
- 30 lines of overscan at the bottom
The TIA does not count lines itself. The program has to count them and switch the sync and blanking signals on and off at the right moment, or the picture rolls. Each line lasts 228 “colour clocks”: 68 for the beam to return to the left edge and 160 for the visible picture. The processor runs at one third of that speed, which leaves 76 machine cycles per line. A simple instruction takes 2 or 3 cycles, so a programmer could fit roughly two dozen instructions into each line. Writing to a special register called WSYNC pauses the processor until the next line begins, which keeps the code in step with the beam.
The part of the program that draws the picture was called the “kernel”. Every other job, such as reading the joystick, moving enemies, checking hits and updating the score, had to fit into the 70 lines when nothing is being drawn. The Stella guide puts that at 5,320 machine cycles per frame. Robinett’s lecture notes add a warning from experience: if the kernel loop “took one too many cycles, timing failed and the TV screen rolled”.
Six objects and four colours per line
The TIA can draw only six things:
- The playfield: 20 bits of data for half the screen. The other half is either a copy or a mirror image, so the full width is 40 blocks, each 4 pixels wide. This is where the 2600’s blocky walls come from.
- Two players: 8-pixel-wide sprites, which can be stretched or repeated two or three times across the line.
- Two missiles and a ball: simple lines 1, 2, 4 or 8 pixels wide.
There are only four colour registers: background, playfield (shared with the ball) and one for each player (shared with its missile). The hardware was built with games like Pong and Tank in mind, and you can see that in Video Olympics and Combat: two players, a few missiles, a symmetrical field.
Adventure shows how far those six objects could be pushed. Robinett used the ball as the player’s square hero and the two player sprites for dragons, keys and other items. He used the missiles, meant for shots like the shells in Combat, as extra thin walls. Because the playfield is mirrored, nearly every room in Adventure is symmetrical left to right, which helped make its mazes so confusing.
The tricks that shaped how the games look
Flicker: taking turns
With only two player sprites, a game that needs more characters must show them in turns. In Pac-Man, one sprite is Pac-Man and the other is shared by all four ghosts, so each ghost appears in only one frame out of four. On a CRT, the glow of the screen fades slowly, which softens the effect, but the flicker is still easy to see. Adventure does the same when three or more objects share a room. The later Ms. Pac-Man, on a larger 8 KB cartridge, flickers far less.
Reusing sprites further down the screen
A sprite drawn near the top of the screen can be repositioned and given new graphics lower down, and it becomes a different object. Space Invaders changes the player graphics as the screen is drawn to fill the screen with rows of aliens. Atari programmer Tod Frye later built a kernel for reusing sprites vertically that was used in RealSports Football, where each team has five players.
Venetian blinds
A chessboard needs eight pieces in a row, far more than two sprites can show. For Video Chess, Bob Whitehead drew four pieces on one set of lines and the other four on the lines in between. The method became known as the “Venetian blinds” technique.
Changing colours line by line
Colour registers can be changed between lines too, which gives the 2600 its bands of colour. Activision used it for a striped sunset sky. You can see one in an unreleased Activision demo, listed here as the Venetian Blinds demo. According to AtariMania, the same sunset later turned up in Barnstorming, Chopper Command, Seaquest and Pitfall II.
Calculating the world instead of storing it
Maps take space, and 4 KB is not much. David Crane’s Pitfall! has 255 jungle screens, but they are not stored anywhere. A counter works out each screen’s trees, pits and hazards as you walk, so the whole jungle takes fewer than 50 bytes of ROM. Carol Shaw’s River Raid also builds its river as you fly instead of reading it from a stored map. Adventure took a different route: its room data is laid out so that rooms can share parts of it, and 30 rooms fit into a 4 KB cartridge.
Where 128 bytes actually go
Robinett’s lecture slides include a rare breakdown of a real game’s memory. This is how Adventure used every byte of RAM:
| Used for | Bytes |
|---|---|
| Kernel (display) variables | 18 |
| World state: where every object and creature is | 49 |
| Other program variables | 34 |
| Reserved for the stack | 14 |
| Unused | 13 |
| Total | 128 |
The ROM was just as full. The same slides list 751 bytes for the display code, 1,263 bytes for data and graphics, and only 17 bytes left over out of 4,096. Choices like these had real costs. Tod Frye decided that Pac-Man had to support two players, which meant keeping a second copy of the score, lives and maze state in RAM. That is memory the game could not use for anything else.
When 4 KB was not enough
- Bank switching. The 2600 can only see 4 KB of cartridge at once, but a cartridge can swap which 4 KB is visible. Asteroids (1981) was the first 2600 game to use this, with 8 KB.
- Extra chips in the cartridge. For Pitfall II (1984), Crane designed his own Display Processor Chip, which took over graphics work and made four-voice music possible.
- Extra RAM. Starpath’s Supercharger plugged into the cartridge slot, added about 6 KB of RAM and loaded games from cassette tape. Dragonstomper is one of its games, and Sweat! The Decathlon Game was still in development for it when Starpath ran into trouble.
Why PAL versions play differently
Because the program itself counts the lines, a game had to be changed for European PAL televisions. The Stella guide gives a PAL frame as 312 lines at 50 frames a second instead of 262 at 60. A game that moves its objects once per frame runs about 17% slower on PAL unless the programmer adjusts it, and the colours change too. That is why some games on this site come in separate versions, such as the homebrew K.O. Cruiser in NTSC and PAL.
Sound on a budget
The TIA makes its tones by dividing a base frequency by one of 32 whole numbers. That gives a fixed set of pitches, and many of them are out of tune with a normal musical scale. That is why 2600 music often sounds slightly off, and why most games stick to sound effects. Pitfall II’s extra chip was one way around the problem.
See it for yourself in the emulator
- Watch the flicker. Play Pac-Man, then Ms. Pac-Man, and compare how the ghosts look. Adventure flickers as soon as you drop a third object in a room.
- Switch to black and white. F2 flips the console’s TV type switch. Games like Adventure read that switch and swap to a set of grey tones.
- Count the colours. Look at any single line of Pitfall II or Seaquest: the background changes colour from band to band, but each line has only a few colours.
The beam is still being raced
The phrase gave its name to Nick Montfort and Ian Bogost’s 2009 book Racing the Beam: The Atari Video Computer System (MIT Press), which studies the console through games like Combat, Pitfall! and Yars’ Revenge. The book inspired Ed Fries, a former Microsoft executive, to try 2600 programming himself. The result was Halo 2600, released in 2010 and fitting in 4 KB. Fries said that working within such limits “felt more like writing poetry than it did like writing regular code”. Load it up and you are watching the same 76-cycle race that Atari’s programmers ran in 1977.
