This Book About the Atari 2600 Reminds Us That Programming These Days is Really Candy Ass

I recently read 'Racing The Beam: The Atari Video Computer System'. The book introduces a new field: 'platform studies', which sounds academic and dry, but if you are a technical person, what it is is a nice break from the told and re-told video game mythology those of us who came up in the era of classic video games (roughly the late 70's to the '83 crash) have heard and re-heard: the Pong coin box overflowing, the pizza with a slice missing as Iwatani's inspiration for Pac-Man the truckloads of the hated 'ET: The Extra Terrestrial' cartridges being dumped in a pit in Alamogordo, New Mexico which was then paved over.

Today's programmers, whose 'hello world' programs written in Java require the memory of millions of early 80s Sears Department Stores' Electronic sections full of VCSs have heard stories of the amazing programming feats in the days of old. The Atari 2600 (code name: Stella) featured a whopping 128 bytes of RAM. Not 128M. Not 128K. 128 bytes. You can't even fit a whole Twitter Tweet in there.

'Racing the Beam' gets into the gory details of the platform's design. Of particular interest is the TIA (television interface adapter). Screens were drawn line-by-line (with 192 vertical scan lines), and horizontally the screen was divided into 'color clocks'. 'Racing the beam' refers to the need for code to do all the necessary calculations in these tight time constraints.

Aside from the memory and time constraints, the games were mostly built under tight personnel (usually one person per game) and schedule constraints (although in the chapter about the game 'Adventure', we learn that after a very intense month of prototyping (and essentially laying the groundwork for a whole genre of games), Warren Robinett had to take a month-long vacation to let his brain recover).

How Deep Does It Get?

As I mentioned before, the book does cover the architecture of the system in a block diagram sort of way. While there are no extensive code listings, the chapter on Combat gives a high-level overview of the program's structure and discusses the building blocks for game graphics: 2 hardware sprites, two 'missiles', a 'ball', and a playfied (by default, this was symmetric, so the field could be specified in half the space it would otherwise take).

Brave souls who want to dive deep into Atari 2600 programming can do so now that we have the internet. See the complete disassembly of the Combat code by Nick Bensema and Roger Williams. This is at first horrifying, but after the initial fear I was struck by the thought that this was the product of a single mind, in contrast to the 'product of many minds of varying levels of skill and levels of giving a shit' nature of enterprise software, which can end up being horrifying in its own right, no matter how many new programming wonder-fads and tools are thrown at it.

For all their heroics, the programmers of the Atari 2600 had their share of shame. Tod Frye got some big royalty checks for his 2600 version of Pac Man. He posted them on his office door: whether this was because of social ineptitude or just being an asshole will be debated by platform studies scholars for years. Unfortunately, the game was horrible, as those of us who owned it and played it 3 or 4 times recall. Millions returned the cartridge, other people, like me, just never played it again. I should note that this book does a pretty good job describing the technical reasons the game sucked so bad.

So what is it? Academics? Nostalgia? Geexploitation?

I mentioned at the start of this post how a lot of us have heard the stories of the classic video game era many times. Really great stories stand up to retellings and help pass them along to new generations, who may or may not care. This book does provide a freshness by looking at the 2600 from a technical as well as cultural, historical, and business perspectives. I'd like to read similar books about other great machines of the era, both game machines like the NES and early home computers like the Commodore 64 or the legendary Apple ][. With Maker culture getting people interested in working within the tight constraints of PIC and AVR microcontrollers and the Arduino platform, there's even a practical benefit to looking back at techniques that today's web monkey will have little or no use for.

I'd recommend the book to anybody who loved the Atari 2600 but doesn't want to just take another nostalgia trip down memory lane, or anybody who wants to know how grandpa wrote programs back in the old days.