Vaders and Venetian Blinds: A Review of “Racing the Beam”

I’ve said before that I don’t read a whole lot of books. Not to say I don’t have a few on my radar, it just takes me a while. Same goes for video games; I have plenty to play, but I’m usually too busy off in my own world to try them out. Given that it looks like the US will open back up some time after the heat death of the universe (read: plenty of time to myself), I’ve been trying to rectify that.

Today’s topic is one that combines both these worlds in a really curious way: meet Nick Montfort and Ian Bogost’s Racing the Beam, a look into the curious challenge of programming the Atari 2600.

The heavy sixer

The Atari 2600 is synonymous with 70s gaming. It’s hard to think of a console design more iconic, a game library more evocative of a very strange era in gaming than the Atari’s. You know it, you’ve heard of it, if you’re of a certain vintage or you’re a retrogamer (of which I was before it was cool, ahem), you’ve played one. They’re not exactly rare.

I’ve loved the Atari ever since I was a little kid watching way too much Classic Game Room and getting lost in quirky titles like Demons to Diamonds and Surround, the real oddities of the Atari’s library. No one quite knew what would be a success on a home console yet, so if it wasn’t a very abstract Star Wars tie-in or an arcade conversion, it was probably a game about trying not to eat yourself to death when your Italian mother won’t stop making you food. Yes, that’s a real game.

What compounds my interest in the console (and what this book’s based around) is its utterly bizarre architecture. 128 bytes of RAM, a 6502 with some of the address lines lopped off like unwanted fingers, and a miserable 4K of max addressable ROM without bankswitching. The Atari was an anemic machine with some maddening tradeoffs: at its heart is a custom chip called the TIA that doesn’t work in pixels or in frame buffers, but in a ball sprite, two missile sprites, two player sprites, and a 160 pixel across playfield which can’t even be drawn all the way across the screen normally. All your code has to work while the TV is being drawn scanline by scanline, sometimes in the middle of a scanline; this is why they call it “racing the beam”.

This is also what makes the Atari such a fascinating console; it’s limited, but it gives wide, wide latitude to what programmers can do with it. As early as Air-Sea Battle, Atari programmers realized they could take the same sprite object and draw it on multiple scanlines, giving the illusion of tens of objects on screen at once. Multicolored sprites were next, just change the color of the sprite on the next scanline. The glitchy on-screen distortion in Yars’ Revenge is the result of feeding the TIA parts of the game’s own code. Even advanced effects such as parallax scrolling were eventually made a reality on the Atari.

Scratching the surface here–this is a constrained programming dream machine.

Reason to race

Racing the Beam focuses on six key games from the Atari’s early lifespan: Combat, the initial pack-in game, Adventure, the first proper graphical adventure game, Pac-Man, the infamous arcade conversion, Yars’ Revenge, a warped conversion of Star Castle, Pitfall, the predecessor to the sidescroller, and finally Star Wars: The Empire Strikes Back, obviously a movie tie-in.

What makes Racing the Beam noteworthy is the angle at which the authors attack the subject matter. Something like Racing the Beam could’ve easily turned into melodramatic fluff in the hands of, say, pseudointellectuals more interested in telling you their interpretation of the past, distorted through so-called “critical” modern day lenses than anything that contributes to the conversation. Thankfully, Racing the Beam differs in that it’s a “platform study”, primarily detailing how the challenges of the Atari shaped the games made on it. The historical context is mostly kept around the edges, enough to paint in the lines of the topsy-turvy world of Warner-era Atari, and then the rest is all on how the console and the culture affected the games.

• Combat‘s used as a lead-in to explain how your average early Atari game was built and what the console was initially meant for.
• Adventure shows how one medium (text adventures) gets adapted to another medium without a keyboard or text display.
• Pac-Man demonstrates very much what the Atari wasn’t good at, especially with the internal strife at the company at the time.
• Yars’ Revenge shows how a developer could take an idea which wouldn’t work terribly well on the Atari and turn it into a new, much more successful project.
• Pitfall‘s used as the lens through which the emergence of the third-party game studio is explored (in its case, Activision).
• Finally, Star Wars is used as a contrast to the Combat game, showing the technical and cultural growth of the Atari over its first six years and how a non-interactive medium could be adapted to interactivity.

To this end, Racing the Beam is excellent. Some of the Amazon reviews bemoan the lack of hard code analysis, but that wasn’t the aim here. This book’s most interested in the stories, the way a young programmer would look at a machine as bonkers as the Atari and surmount it. Not every one succeeds; as said, Pac-Man is basically the poster child for bad ports, with one Tod Frye being tasked to build the damn thing in six weeks on a console with architecture vastly different to the arcade machine’s. Some took third options; Howard Scott Warshaw, in charge of Yars’ Revenge, saw a Star Castle port as pointless and came up with a totally different amalgamation of its elements, to which Atari agreed and ended up with a classic.

Towards the end

Admittedly, Racing the Beam is a little slow to get into at first, essentially becoming a history lesson with some tech chatter in the Combat and Adventure chapters (not that they aren’t informative, just dry). The book really hits its stride when it talks about the insane tricks behind these often considered simple little games. I can think of no better example than Pitfall‘s polynomial counter, which is used to consistently generate 255 screens of “randomness” in about 50 bytes. One would’ve considered so many screens a futile effort–David Crane (and before him, Warren Robinett) begged to differ.

Come the latter chapters, the anecdotes really start to stick in your head. I love this one about the early Activision, how freewheeling it all was back then:

The work environment was more atelier than software shop. Developers worked together in large rooms, occasionally turning to each other to discuss design or programming techniques. David Crane told the story of one such discussion: Carol Shaw was hard at work on River Raid, which would become an influential vertical scrolling shooter. In the game, the player has to maintain the plane’s fuel supply, flying it over canisters in the river. There is a detailed fuel gauge at the bottom of the screen, but Shaw wanted to include audio feedback as well. She was programming alongside several other Activision developers, and she asked for advice on an appropriate klaxon-style sound to warn the player when the fuel level became dangerously low. According to Crane, he rolled back in his chair, looked up in thought for a moment, and recited a few lines of assembly code that created the effect perfectly.

Or how Parker Brothers outdid Atari’s work with the machine without any docs by reverse-engineering it and guessing at the rest:

“Our first job was to reverse-engineer the trade-secret Atari [VCS]. Parker Brothers hired a company to strip off the top of the graphics chip and photograph it. [Two engineers] stared at the circuit diagram, while I wrote a disassembler to examine the existing cartridge code. Then I started writing some small programs to test our theories about how it worked. Finally, by the fall of 1981, we were ready to create our first game.”

The whole thing reminds me a lot of the culture and anecdotes surrounding the development of the original Macintosh. Stories like this, of young, fresh faces writing the rules of uncharted ground, fill sites like Folklore.org. Stories of madmen like David Crane are right at home there, pushing the limits of their technology and doing things actively thought impossible. Remember–Sunnyvale’s only 10 minutes away from Cupertino.

Seriously, if you’re not turned off by the discussion of color clocks and assembler instructions, Racing the Beam is a highly recommended read. It’s sad that there have been no further entries into this Platform Studies series, because there’s so much that’s primed for this kind of examination. The Nintendo DS is a classic example of a unique platform with its touchscreen, and given all the press around Flashpoint, I’d say web games are primed for such a postmortem as well.

But look beyond gaming for a moment. What about non-gaming related media, like how the limitations of vinyl informed several classic releases? (Or maybe I’ll leave that for an essay sometime…) The authors even discuss this much towards the end of the book, talking about how everything from Java to BASIC to even the old PLATO system count as platforms that informed the design of the material built on top of them. Looking at the world from the foundations and intentions up is key for a fair dissection; this book nails it.

Seriously, MIT Press, whoever’s on this–make more. I’ll buy it.