Racing the Beam: The Atari Video Computer System

I just finished reading one of the most nerdtastic books I’ve read in a long time, thanks to Kwin Kramer at Oblong, who generously gave me the book he had just acquired at the MIT Press bookstore while in Cambridge. Kwin hadn’t even read the book yet, but I think he saw me salivate (and therefore judged me more in need of the book than himself) as I thumbed through the pages and saw snippets of assembly code and discussions regarding the coding necessary to perform game calculations in the processor cycles available during the analog/CRT video horizontal and vertical sync intervals.

The book was a true pleasure to read and made for a nostalgic trip down memory lane since I was an avid Atari 2600 gamer as a kid. Guilty childhood confession: I once even made friends with a kid I probably wouldn’t have otherwise hung out with because he was the first one on the block to own Activision’s Pitfall!

Reading this history of this seminal home video game system and technical discussions of the constraints and idiosyncrasies of the platform gave me tremendous respect for early Atari game designers like Warren Robinett, David Crane and Howard Scott Warshaw. First, these guys did it all — graphics, sound, gameplay, design, etc. Each game was a one-man show. Even more impressive was how they were able to produce great games with technical constraints that today sound totally ridiculous — these guys had to confine themselves to 2K of ROM for games and graphics, no frame buffer for rendering a screen (they had to render each CRT scan line in real time in code) and a laughable 128 bytes of RAM.

Some of my favorite programming tricks covered in the book involved the arduous process of code-size optimization. 2K was not much to work with, so programmers often had to squeeze every last byte out of the code and graphic sprites in order to get them to fit in the highly constrained space. This often involved hand-optimizing of MOS 6507 assembly code, and economizing via clever hacks. For example, in Yar’s Revenge, Howard Scott Warshaw need to create a random-looking field of blocks on the screen, but he could not afford the space or computational time needed for a pseudo-random number generation algorithm, so instead he just used sections of the code itself to produce a string of seemingly random patterns on-screen. So cool.

In another game, a programmer was able to save a byte of space when the final byte of a subroutine happened to be identical to the first byte of a sprite bitmap, which happened to immediately follow the previous portion of code in the ROM. So the programmer cut one of the duplicate bytes out and pointed the sprite bitmap to an address one byte earlier in the code to enable both the code and the graphic asset to share a single byte. That is a hardcore level of optimization, possible only when programming so close to the hardware.

The architecture of the system was originally designed to enable games like Pong and Combat, so the system was given two controllers and assumed head-to-head-play, and a video rendering subsystem that included two moveable sprites, a cursor and a missle and hardware support for things like symmetrical playing fields, scaling and mirroring of sprites and collision detection of onscreen objects. The book does a excellent job tracking the evolution of the games developed for the system, with programmers taking the system to a level of sophistication and functionality likely unforeseen by the architects/designers of the platform, a remarkable feat given the simplicity and constraints of the system.

And perhaps most unforeseen by Atari was that their console sparked the rise of an ecosystem of developers and publishers around a game platform, presaging the modern videogame market. Atari hadn’t anticipated this, never published a spec for their proprietary system and assumed all games would be developed in house. In fact, they initially tried to prevent third-party developers from releasing titles for their system. Several early Atari programmers who felt under-compensated as a result of their $20k salaries and no participation in the multi-million dollar profits their games generated for Atari spun out to create Activision, the first third-party game developer. Parker Brothers even made games for the console and had to hire a team of programmers to reverse-engineer the system by disassembling the code in existing game cartridges, since Atari wasn’t interested in publishing a spec or providing tools to allow third parties to develop games for the platform. As a result, they lost out on lucrative licensing revenues from third-party publishers, an error Nintendo wisely learned from when they launched the NES in 1983.

If you are a gamer interested in the history of video games or have an interest in how software design and programmer interacts with hardware design, this book is for you. My only complaint is that this book is not available on the Kindle. C’mon MIT Press, get with the program! I understand the subject matter of this book is retro, but think of your audience here in the 21st century.

  • Awesome! I had an Atari 2600 as a kid as well, and learned machine language programming on the 6502. I'll definitely be picking up a copy of this.

  • I just finished a review of Racing The Beam – it was a fun book to read too, even if I never owned one – got a C64 a few years later. I liked how it talked as much about the environment (cultural, business practises) of the time as well as the technology. There's some interesting trivia here too: like Atari setting up different companies to avoid regulations.