It was a nostalgic and informative treat this week to read through “Racing the Beam: The Atari Video Computer System” by Ian Bogost and Nick Montfort. As a child I inherited a massive collection of Atari hardware and games from my older brother, which I enjoyed playing even after the release of the original Nintendo Entertainment System. The technical differences between the NES and the Atari 2600 were bluntly obvious to me even at that early age. But the Atari still impressed me with a large number of games that I found to be fun time-sinks.
‘Racing the Beam’ examines the Atari VCS—i.e. the Atari 2600 after 1982—in the form of a technical platform study. The authors provide detailed insight into the hardware and software challenges faced by game developers in those formative years, weaving its explanations together with expositions about the history of the VCS and its place in American culture.
I approached the book already familiar with major details concerning the console’s history. But as a computer programmer I had never taken the time to revisit the technology that brought video games into my childhood. “Time to get my learn on….”
The Target Audience
I should make something clear before delving into my thoughts on ‘Racing the Beam’: technical-minded people are the target audience. A reader who is not a programmer will still find much content to enjoy. However, someone who is not comfortable with CPUs and close-to-the-metal programming will find himself forced to gloss over sections here and there.
This is the best benchmark I can think of to help people determine if they can grasp everything in the text: ask yourself how much difficulty you would have learning to write software for the MOS 6502 microprocessor. If that sounds daunting then do not skip the book, but realize that you may not understand all of the technical insight it offers.
‘Racing the Beam’ is not some snobby, ivory tower book intended only for an obscure chosen few. I am certain that video game enthusiasts with absolutely no programming experience will enjoy the book. But some sections do make assumptions about a degree of technical prowess on the part of the reader.
Remember These Games?
‘Racing the Beam’ is divided into eight chapters: an introduction, an epilogue describing the crash, and six chapters in the middle, each devoted to a particular game.
Any of those names bring up fond memories? Well congratulations, you are old! Heh.
In each chapter the authors begin by setting the stage for the game, providing the historical context surrounding and motivating its release. Each one of these titles provides an impressive avenue of insight into the variety of game-design techniques that emerged for the Atari 2600 and, furthermore, why those techniques were the results of necessity.
A number of those techniques are technical achievements that will stun any modern game developer unfamiliar with the console. For example, the Atari 2600 has 128 bytes of RAM. One-hundred twenty eight bytes. Let me put that into perspective: The text (and nothing else) for a 140-character tweet takes up more memory than the Atari 2600 has to offer. No single paragraph of this article could fit into that memory. Bill Gates is incorrectly credited with having once said that, “640 kilobytes of memory should be enough for anybody.” That is five-thousand times more memory than what is available in the Atari 2600.
The paucity of RAM is not the only technical challenge the system presents. The Atari 2600 uses a variant of the MOS 6502 CPU, the 6507. But the popularity of MOS’s chips meant that it was well-understood. On the other hand was a chip unique to the console, the Television Interface Adapter, the TIA. As the authors put it:
The processor is always called the “brain” of a computer, and, indeed, the MOS Technology 6507 is the Atari VCS’s brain. But the custom Television Interface Adapter (TIA) is its heart.
A great example of the fascinating technical information from the book rests in its thorough examination of the TIA.
Pixels? Ha Ha Ha…
Game developers and programmers like myself are so accustomed to thinking about rendering in terms of pixels that it is easy to forget this is not how things were done in those days. A modern video game console has a buffer of ‘frames’ that programmers render. The console draws each frame to screen, and if we can create those buffered frames quickly enough then we create smooth and steady graphics. However, those frames must be stored in memory. Even if you tried to divide a television in those days into ‘pixels’ there is still not even close to enough memory to store a single frame in memory.
When you play an old Atari game you will see that there are not obvious gaps in the graphics, delays in rendering that cause empty chunks of screen. How is that possible? It requires some basic understanding of cathode-ray tube televisions (CRTs). Inside a CRT is an electron gun that fires from top-to-bottom, left-to-right across the physical television screen, illuminating the phosphors coating the glass within. Each one of these horizontal lines is a ‘scan line’, a term many of you have surely heard before. When the electron gun reaches the end of a scan line it moves down one line, re-aims starting from the line, and begins firing again. To make rendering appear smooth and steady Atari game programmers had to find clever ways to stay ahead of this beam so that it would never reach a point where the console was not ready to tell it what to draw.
Hence the phrase, ‘racing the beam’.
The word ‘video’ in the name ‘Atari Video Game System’ is not a marketing term. It reflects the very close relationship between the console and the behavior of television video hardware. The aforementioned Television Interface Adapter (TIA) is the bridge between the two. As I said, the Atari has no concept of pixels. The closest are the ‘color clock cycles’ on the TIA: the amount of time which the TIA can affect the electron beam within the television before it fires again. That means that changing rendering, e.g. switching to using a new color, means using the TIA to modify the behavior of that electron gun.
But this is hardly simple. The TIA is synchronized to the Atari’s CPU. In programming we measure CPU instructions in ‘cycles’. For example, moving data from RAM into the CPU could take three cycles, and most of the CPU’s instructions required three or four cycles. The TIA has its own clock that runs in sync with the CPU. That TIA clock ‘ticks’ three times for every single CPU instruction. In other words, by the time the CPU executes a single instruction the TIA clock has ticked nine to twelve times. That makes it very difficult to introduce graphic changes in those horizontal scan lines. Instead it is easier to wait for the brief gap during which the electron gun finishes one line and positions itself to start firing the next.
Atari 2600 programmers had to find clever ways to accomplish changes in these very brief periods of rest between rendering. A useful time to do so is during a ‘vertical blank’. This is when the electron gun finishes firing the beam over the entire screen and has to start again from the very top. That ‘long’ gap—not really that long—is the time when many 2600 games update information such as score, character and enemy positions, create sound effects, and so forth. It does not last long but it provides the longest respite to do anything unreleated to graphics.
Some Interesting Things I Learned
Did you know the Atari 2600 does not understand its reset button at a hardware level? Every game is responsible for providing code that detects that button press and resets the game accordingly. A natural consequence of this is that games can choose to not behave this way, treating the reset button like any other. While this technique was used infrequently it did open the door for some clever tricks.
If you play the game Yars’ Revenge you will see a bar in screen called the neutral zone. Here the player can rest his ship in automatic safety from some of the enemy’s attacks. The bar looks like random noise, but that is not true. Implementing a semi-random number generator on the 2600 would take up too much processing power. So another idea is to use a series of data that appears random to players and display that. But since 2600 games had so little memory and disk space to use it was also not realistic to add a ‘random’ sprite to the game. So programmer Scott Warshaw hit upon a clever solution: treat the game’s source code as the data. At a fundamental level all code is data. At the lowest level all code becomes numbers feed into the CPU, just like the numbers in memory representing data. What makes them code versus data depends on how we use them. So Warshaw decided to create his ‘random’ bar by treating the game source code as data, displaying it to the screen. That means when you play the game you literally see its source code on the middle of the screen in graphical form. Pretty neat huh?
The game Pitfall!—never knew it had an exclamation mark in the title—has a total of two-hundred fifty-five stages. The previously mentioned memory limitations make it impossible to store these levels in memory. So programmer David Crane came up with a clever solution: he used a polynomial counter to create single digit numbers that would determine the type of level to create. Since the process creates a sequence of numbers he could move sequentially through them, meaning when the player returns to a previous screen he sees that previous level and not a mysteriously new one.
I strongly recommend ‘Racing the Beam’ to any video game developers and video game enthusiasts with an interest in the console. It is a fantastic and absorbing read from cover to cover. The authors do a great job of describing the cultural impact of the console while also explaining the various forces, both technical and social, that impacted game-design in that era.
Here are some great resources for readers who wish to learn more about the system:
- The Stella Emulator
- Atari Gaming HQ
- Stella Programming Guide (PDF)
- BASIC Compiler for the 2600
- Easy 6502
Next Book of the Week
In keeping with the topic of the MOS chip inside the 2600 I have decided this week to read the “MOS MSC6500 Family Programming Manual” (PDF). It is freely available so I encourage you to read along with me this week.
I hope you’ve enjoyed the article, and if you have any questions about the Atari 2600 then please don’t hesitate to ask in the comments, and I’ll do my best to answer.