Racing the Beam: How Atari 2600 Games Were Drawn

0:00We asked an Atari 2600 to write its own name across the screen. It wrote 2626.

0:12The machine had, in its defence, done exactly what we told it. We had supplied the picture for the left half of each television line. The graphics chip simply used it again on the right. To make the last two digits into zeroes, the program had to rewrite that same chip while the line was already being drawn.

0:43Three writes prepared the left half. Then, after the television beam had passed each part, three more changed it before the beam reached that part's place on the right. That is the startling thing about an Atari picture. It wasn't drawn, stored and displayed. The program built it in step with the television, one line at a time. This is what we now call racing the beam.

1:13Atari launched this as the Video Computer System. The name 2600 came later. A British advert in November 1978 offered the console, Combat, two joysticks and paddles for £169.95. Behind the woodgrain was a machine designed to do as much as possible with very little hardware.

1:40The 6507 processor ran the game. The 6532 provided a timer, read the joystick directions and console switches, and held all 128 bytes of the console's working memory. The custom Television Interface Adaptor, the TIA, produced the picture and sound. The program itself came from the cartridge.

2:09A conventional frame buffer is a block of memory that holds a finished picture for the video hardware to read. The 2600 didn't have one. Al Alcorn recalled chip makers' game designs that used frame buffers of ten or twenty chips. His response was, “And we said no, no, no, no.” Silicon was expensive, and Atari made the software do more so the hardware could cost less. Those 128 bytes weren't even enough to store one byte of colour for each of the 192 picture lines in Atari's standard NTSC frame. And the game needed that memory for everything else: positions, scores, timers, controller input and the processor's own stack. So the TIA kept only a small set of drawing instructions for the line being produced. If the processor changed nothing, it sent the same thing again on the next line. The playfield was only twenty bits for half a line. The TIA could copy or reflect those bits for the other half. Alongside it were two eight-bit player graphics, two missiles and a ball. That doesn't describe a finished screen. It describes a handful of objects that the processor could alter while the television was moving through the picture.

3:36On a cathode-ray television, an electron beam makes a bright spot on the inside of the glass. It sweeps from left to right, moves down and begins another line. At the bottom, it returns to the top. The Atari's signal had to keep that movement synchronised and supply the colour and brightness needed at each moment.

4:01For the NTSC system used by our examples, Atari's standard frame had 262 lines and repeated about sixty times a second. Each line lasted 228 colour clocks. The first 68 were horizontal blank, hidden while the beam returned to the left. The remaining 160 were the visible picture.

4:30The TIA's colour clock ran three times faster than the 6507. So one processor cycle consumed three colour clocks of the beam, and a complete line allowed only 76 processor cycles. A write one cycle later appeared three pixels further to the right. That relationship is the clock for the whole picture.

5:01Our small program begins with the TIA doing almost nothing. Set the playfield once, and it repeats the same vertical stripes on every line. Change only the background colour before each visible line, and the screen becomes horizontal bands. Rewrite the playfield every eight lines, and those repeated fragments become a television set. The picture changes because the program changes the TIA before the beam gets there.

5:33The part of the game that builds the picture is called the kernel. At the end of a line, it can write to the wait-for-sync register. The TIA then halts the processor until the next line begins. But vertical timing was left to the program. It had to count the lines, switch vertical sync on and off and produce a complete frame itself. In Atari's standard NTSC layout, 192 of the 262 lines carried the picture. The other seventy covered vertical sync, blanking and overscan. They provided 5,320 processor cycles, about a quarter of the frame, for reading controls, moving objects, checking collisions and updating the score. Then the beam returned and the kernel had to draw everything again. Atari's standard PAL frame, for British televisions, had 312 lines at fifty frames a second. Their clocks ran slightly more slowly, but each line still contained 228 colour clocks and gave the processor the same 76-cycle budget.

6:58We made that timing visible by changing the background from black to yellow a little later every few lines. On all 192 lines, the yellow began where the beam was when the write took effect. Every extra processor cycle moved the edge exactly three pixels to the right. The diagonal is a clock made out of the picture itself.

7:31Horizontal positioning was just as peculiar. There was no register where a game could say, put this player at x equals fifty. Instead, the program waited until the beam reached the wanted point and strobed the player's reset register. The object then appeared at that horizontal position on following lines. In our example, each extra turn around a five-cycle delay loop moved the white object fifteen pixels. The first three strobes happened during horizontal blank, so they all produced the same position at the left edge. Games used a separate fine-movement control, HMOVE, to fill in the smaller steps.

8:18The 2600 picture needed six playfield writes on every visible line. The first three were ready before the beam reached the picture. The last three landed while the line was being drawn, after their old values had served the left side and before the TIA needed the new ones on the right. On most lines, the work ended at processor cycle 62, leaving fourteen cycles out of 76 to wait. Carol Shaw remembered counting the cycles of every instruction. Sometimes, she said, “you'd just go through and count and have exactly the right number of cycles.” One cycle wasn't a vague unit of performance. On the screen, it was three pixels.

9:09The designers had expected a small collection of objects suitable for games such as Tank and Pong. Programmers soon found that those objects could be changed and repositioned partway through a frame. Larry Kaplan discovered that a player could be reused at different heights. His Air-Sea Battle arranged objects in horizontal bands, a method that later helped make Space Invaders possible.

9:40Space Invaders made each row of six aliens from two player objects, each copied three times. Bob Whitehead found another use for those copies in Blackjack. By rewriting a player's graphics between one copy and the next, three identical objects became three different cards. The TIA hadn't gained anything. The program had learned to change it at precisely the useful moment.

10:13At Activision, the programmers' names and faces became part of the product. Their games kept pushing the same hardware, but the company rejected one common compromise. Flicker could simulate extra moving objects by showing each only every second, third or fourth frame. When IEEE Spectrum wrote about the system in 1983, Activision had never used it. Whitehead called flicker “a tradeoff that is not acceptable”. Their programmers would rethink the game instead. David Crane described the process plainly. “You didn't actually design a game and then implement it on the hardware. You figured out what the hardware could do and then worked that into something fun.” Pitfall! is where that way of thinking becomes a whole world.

11:16Pitfall! appeared in 1982, designed by David Crane. The cartridge label said so. The manual gave him a portrait, a signature and a page of advice. Activision wanted the player to know who had made the game.

11:39The recognition didn't make the cartridge any larger. Pitfall! had to fit into four kilobytes of ROM. Crane later remembered “the 100th time I had to rewrite the Pitfall code, finally getting it down from 6K bytes to under 4K.” Even the little tally marks showing Harry's remaining lives probably cost 24 bytes and, Crane said, another twenty hours of squeezing the code.

12:21We followed one frame of the first screen as the game drew it. Pitfall! made more than a thousand writes to the TIA, not counting its waits for the next line. The busiest line made ten. The registers written most often were the two player graphics and HMOVE, the fine-movement control. The score is another piece of careful reuse. Two eight-pixel players are copied across the line, then their patterns are changed as the beam moves through them. That turns two small graphics objects into six separate digits. Down in the jungle, the same hardware becomes Harry, logs, creatures, branches and hazards, rewritten in different horizontal bands.

13:11That black strip at the left has sometimes been described as picture width sacrificed for more processing time. The hardware account gives a more direct cause. Writing HMOVE during a line extends horizontal blank by eight colour clocks, hiding its first eight pixels. Pitfall! writes HMOVE throughout the display, so separate black marks become a solid bar. In the frame we measured, it wrote HMOVE 195 times. On lines that ended by waiting for the next one, the median time left was sixteen cycles out of 76. That was the room in which Crane's kernel had to remain perfectly timed, while still making the picture look like a jungle rather than a demonstration of video registers.

14:04The manual promised 255 jungle scenes. Storing 255 screen pictures was out of the question. Pitfall! doesn't even keep a table listing them in order. It holds the current screen as one byte in RAM, and calculates which byte comes next.

14:43Every game begins on screen number hex C4. When Harry runs right, the program shifts that byte left and creates its new lowest bit by combining four bits from the old value with exclusive OR. The sequence visits every possible byte value except zero. After 255 screens, it returns to C4.

15:17The whole rightward calculation is ten instructions and fifteen bytes. A second routine performs the calculation in reverse, so when Harry runs left, it restores the previous screen number. Crane later described the layout as 255 screens defined in about fourteen bytes.

15:44The byte is also the recipe for the scene. Three bits choose the ground, including holes, pits, ponds, crocodiles and treasure. Two choose the tree pattern. The remaining three help choose what lies on the path, such as logs, fire or a snake. One number becomes both Harry's place in the maze and the ingredients needed to draw it.

16:17So the jungle isn't stored as 255 pictures. Its route isn't stored as a list either. It unfolds from one byte, and the same calculation can be walked forwards or backwards. That saves memory, but it also gives the game a coherent, circular world. Reach the 255th scene and the next one is home.

16:47Ron Milner later said, “I'm proud we accidentally came up with a platform that clever programmers figured out how to do much more than we intended it to do.” The accident was a machine that left an extraordinary amount of the picture in software. The 6507 prepared each line. The TIA turned those changing values into a television signal. The 128 bytes of RAM held the game's immediate state, but never a finished frame. And the television beam supplied a deadline that moved relentlessly across the screen, three pixels for every processor cycle. Inside the Atari, the whole screen was never there at once. It existed line by line, in the narrow space between the code and the beam.

17:41For more stories where the hardware is the plot, subscribe to Retro Computer TV. And if this one earned it, you can like the film.