My parents brought home our first home Pong console in the fall of 1977, shortly after I turned four-years-old. The following year we upgraded to a Magnavox Odyssey 2, and in 1979 we purchased an Atari 2600. I have literally been playing video games my entire life; I’m a grown up gamer that grew up gaming. I’ve watched the video game technology grow and expand infinitely, back from its humble monochrome roots in the late 1970s to the hi-definition graphics, digital surround sound audio, and online multi-player gaming experiences we take for granted today.
When you’ve been around as long as I have, it’s impossible not to compare and contrast the new with the old. As a technical kind of guy this often plays itself out in numbers. Comparing the processing power and storage capacity of today’s modern marvels to the systems of yesteryear results in some mind-blowing revelations. I once downloaded a zip file that contained the ROMs of every Atari 2600 game known at that time. The file was 3 megabytes in size. A complete archive of every official US Nintendo Entertainment System (NES) is slightly larger at just over 100 megabytes. Realizing that I have enough memory to store complete copies of the Atari 2600, NES, SNES and Sega Genesis game libraries on my phone reminds us of how far we’ve come in the couple of decades. In the year 2000, I had a Nokia cell phone that was capable of playing a port of Snake (an arcade game from 1976). Ten years later, I bought an iPhone that plays Tony Hawk’s Pro Skater 2 (THPS2).
Cramming a skateboarding game originally designed to play on the Sony PlayStation into an iPhone requires a level of technical wizardry that is impressive, but not surprising. If you really want to understand what technical wizardry is — if you really want to learn about a world where every byte (nay, bit!) counted, you’ll need to go back almost 30 years to the Atari 2600 platform. While it is indeed impressive that in 2010 Activision was able to render a three-dimensional world in which you can maneuver a virtual Tony Hawk around in, it is more impressive to me that in 1982 Activision released Pitfall!, a game that contained 32 treasures spread across 255 unique rooms containing varying combinations tar pits, water holes, quicksand, rolling logs, campfires, snapping crocodiles, scorpions and swinging vines … all in 4k worth of code.
If that last fact made your jaw drop, or caused you to smile, or sent chills down your spine, or got any sort of physical reaction out of you at all … then Racing the Beam is for you.
Written by Nick Montfort and Ian Bogost, Racing the Beam chronicles (in technical depth) the development of six seminal Atari 2600 games: Combat, Adventure, Pac-Man, Yars’ Revenge, Pitfall!, and Star Wars: The Empire Strikes Back. With the development of each game, readers are exposed to the capabilities (read: limitations) of the Atari 2600 platform. From a hardware perspective the 2600 was developed to play variations of Combat and Pong, and only contained the ability to render five moving objects (two players, two bullets, one ball) at a time, and had 128 bytes of RAM in which to do it. The random, colorful explosions in Yars’ Revenge and the smooth, parallax scrolling in Star Wars: The Empire Strikes Back become all the more impressive in that context. In order to perform some of those complicated tasks, programmers found themselves literally racing the television’s electron beam down the television display.
Each game discussed within the book marks a milestone in the life of the Atari 2600, whether it’s the evolution of text adventures into a graphical environment (Adventure), the birth of movie licensed-games (Star Wars: The Empire Strikes Back), or the genre of arcade-to-console conversions (Pac-Man). None of these games were developed within a vacuum, and the book does a good job of encapsulating not only the technical achievements of each game, but also the historical context in which they were developed. The chapter about Yars’ Revenge, for example, talks about the game’s roots as a port of Star Castle, and compares and contrasts the game with Atari’s Asteroids. The game’s Easter Egg, the code used for the seemingly random level-ending explosions, and its unique sonic landscape are all discussed in detail.
At multiple times throughout the book, Racing the Beam reminds us that these classic games weren’t compiled by teams of skilled programmers, but rather were labors of love, quite often imagined, developed, and programmed by a single individual. While general concepts and technical knowledge was passed along between programmers, because of the way these games were designed it was difficult to recycle and/or share specific code among projects. The concept of having different people work on graphics, sound, and gameplay mechanics would not come to pass for a few more years. The book does a good job of introducing us to these men behind the keyboards.
Racing the Beam is not always an easy read. While the anecdotes and memories documented within are both interesting and informative, the book occasionally delves deep into the technical hows-and-whys involved in producing these games. I encountered some conversational hurdles as I waded through information regarding Atari’s TIA chip (the 2600’s sound and graphics chip), clock cycles and horizontal and vertical blanks — interesting Jeopardy material to be sure, but definitely deeper reading than your average light-hearted romp down retrospective lane.
Upon finishing this book you will never again look at the background trees in Pitfall or Pac-Man’s flashing ghosts in the same way. While not an encapsulating history of the Atari 2600 itself, Racing the Beam does an excellent job of explaining the demonstrating the hurdles and limitations early programmers had to overcome in order to create great video games.
(One final thought: this review contains almost 6,000 characters, approximately 2,000 more than any of the Atari 2600 games dissected in Racing the Beam. Food for thought.)
I was once a 65xx developer “back in the day”, I had never heard of this book before your blog. I have it in my hands right now and am enjoying it greatly.
I programmed C-64s and 128s in 6502 assembly language in the late 1980s/early 1990s. So when someone asked me in the late 1990s if I could program an Atari 2600, I figured, hey, it’s a 6502 variant, how hard can it be?
The only thing I can compare it to is raster programming on the 64, but it’s harder. The 64’s video hardware was sophisticated enough to tell you what it was drawing at the time; with the 2600, you pretty much had to guess. The 64 is a lot more forgiving to program.
But I’ve often wondered if one could “race the beam” on a 64 to do things like change video modes in the middle of a line, like on the 2600.
Dave, I’ve seen some pretty amazing tricks on the 64. I’ve done assembler on the 64 and some of the apples. I’ve seen some mode changes done on the fly I’m pretty sure. I think LOGO or PILOT used that method to do graphics on the top 2/3 and commands on the bottom..been a looong time though.
The 2600 uses the 6507 which oddly is sort of a cut down version of the 6502 I think.
If you’re interested in going back to the “olden” days, you might check into this, I’ve built one and its damn cool if I do say so..
http://www.brielcomputers.com/micro-KIM.html
Hey Jimmy, glad to see you still around, and glad you are enjoying the book!
Sometimes I think y’alls discussions are more interesting than my posts. I love it!
Sometimes I yearn for retro. Not sure why. Lately I’ve been going back through all of the 6502 stuff. Programming just isn’t that fun any more, The gui ruined it for me I think.