Still Racing The Beam

30 Jul 2022

Pitfall on the Atari 2600

Atari recently celebrated its 50th anniversary, which reminded me of the excellent Racing the Beam, by Nick Montfort and Ian Bogost. It’s a fascinating exploration of their iconic home console, one of the first with interchangeable games (in the form of cartridges): the Atari 2600.

From pull quote on the dust jacket:

William Morris famously opined “You can’t have art without resistance in materials.”

The 2600 provided a lot of resistance. Architecturally, it offered little more than was necessary to implement Pong and similar games — two player sprites, two bullets, and some very low resolution play fields. It had 128 bytes of RAM (not kilobytes, bytes), and only 2KB of ROM in each cartridge.

The basic capabilities of the machine topped would, at first glance, seem to top out with things like Combat (which is, admittedly, quite fun). However, later developers (both within Atari and elsewhere, notably Activision) pushed past these to produce far more sophisticated titles than the original designers had ever envisaged. Pitfall, pictured above, is a prime example. Another is Garry Kitchen’s truly remarkable effort to port Donkey Kong

This involved a deep understanding of how the machine worked, including the dynamic behaviour: when everything happened. A key technique was changing what was drawn (the playfield and sprites) while they were being drawn. This was usually done in the split-seconds when the cathode ray had finished one line and was returning back to the start of the next, hence the name of the book: the code was literally racing the beam.

In my previous job, we created a product that solved a very similar problem. When translating a digital circuit from the idealised world of 1s and 0s into the messier domain of physical wires and voltages, it’s imperative that a signal is steady at its intended value by the time it’s needed (setup), and it stays that way until everything that depends on it has stabilised (hold). This is a problem that gets harder, rather than easier, as technology improves – newer, smaller manufacturing processes are both more variable and can run at higher speeds, leading to tighter and tighter constraints. Our software would adjust circuits until they met these constraints, performing the job that the Atari programmers were doing at a far larger scale.

These days, I’ve moved away from silicon and into the cloud. When creating distributed applications, one of the primary things you have to bear in mind is latency, and which data can be where, by when. Networks get faster, but this is fundamentally limited by physics – the speed of light. We’re still racing the beam.

This site is maintained by me, Rob Hague. The opinions here are my own, and not those of my employer or anyone else. You can mail me at rob@rho.org.uk, and I'm @robhague@mas.to on Mastodon and robhague on Twitter. The site has a full-text RSS feed if you're so inclined.

Body text is set in Georgia or the nearest equivalent. Headings and other non-body text is set in Cooper Hewitt Light (© 2014 Cooper Hewitt Smithsonian Design Museum, and used under the SIL Open Font License). BBC BASIC code is set in FontStruction “Acorn Mode 1” by “p1.mark” (licensed under a Creative Commons Attribution Share Alike license).

All content © Rob Hague 2002-2024, except where otherwise noted.