Still Racing The Beam
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.