[vcf-midatlantic] Not quite so linked lists (of books)

[Ken]

At 9/13/2020 06:44 PM, Jeffrey Brace via vcf-midatlantic wrote:
>Racing the Beam by Ian Bogost and Nick Montfort: About Atari a great game
>making company. Also shows how hard it was to program games back then.

Racing the Beam was a fantastic book. It wasn't about Atari the company. It was about the Atari 2600/VCS as a technical platform, and was a really compelling technical study about the interplay between a platform and what's created for it. It focused on the machine's architecture, and then on a few titles written for it, each highlighting something fascinating about platforms.

While technical, it was also accessible. It's one of my top-favorite technical studies of all time. And, if you're not already familiar with the 2600's design, it does really heighten one's appreciation for how intensely challenging programming for it was, and how impressive those developers were.

It looks like this is my second-ever message to this listserv responding to Jeffrey on the subject of this book. Five years ago, I wrote this:

Jeffrey,

I strongly second Adam's recommendation of "Racing the Beam: The Atari Video Computer System," written in 2009 by Nick Montfort and Ian Bogost.
https://mitpress.mit.edu/books/racing-beam

I found it well written and well researched. It gets technical enough to be interesting, without getting too technical to scare anyone off. I would love to read another book as similarly compelling. (It didn't read like a dissertation to me!)

There have been many books like "The Soul of a New Machine" ("Dreaming in Code," etc.) which are all about the people and politics behind the development of a system. But "Racing the Beam" was primarily about the system itself, and it focused brilliantly on the most compelling and instructive moments in the evolution of 1977's Atari 2600 platform. You will learn just how stupendously hard it was to program for that platform. And, to the authors' goal, you will learn how significant a platform itself is, and what kind of heroics it takes to move beyond the constraints and intended capabilities of a platform.

Here are a couple of excerpts, which illustrate what it was like to work on a system that had no operating system, nor even a concept of a 2-dimensional screen grid to write to:

...the VCS programmer must draw each frame of a program’s 
display manually to the screen, synchronizing the 6507 processor instruc-
tions to the television’s electron gun via the TIA. The program has a small 
amount of time to change the TIA settings via its numerous addressable 
registers. This can happen when the electron beam resets to draw a new 
line (this period is called “horizontal blank”), or when it moves back up 
to the top to draw a new screen (a period called “vertical blank”). The 
program must also explicitly instruct the TIA to wait for the horizontal 
blank or to initiate the vertical blank, which involves keeping track of how 
much time the instructions take to execute on a single line, between lines, 
and between frames. Programming the Atari VCS means drawing every 
line of the television display individually, making decisions about how to 
change the display on a line-by-line basis rather than setting up a screen-
ful of pixels all at once. This task requires that the programmer write 
carefully timed code that fits the motion of the television’s electron beam. 
Some graphical effects demand changes to the TIA’s registers in the 
middle of a single scan line. In these cases, the programmer must care-
fully “cycle count” processor instructions so they execute at the right 
time. While “racing the beam” is a catchier name, “pacing the beam” is 
more apt, since the program might have to be sped up or slowed down.

[...]

The basic flow of Combat follows the progress of the TV’s electron 
beam, busily preparing each line that is to be drawn while the current 
one is appearing on the screen. During the vertical blanking interval, 
as the beam moves from the bottom of the screen to the top, the VCS
running Combat does the computation necessary to process input, deal 
with game logic, and update the score if necessary.

The first routine in Combat’s main loop checks the position of 
the VCS console switches. A game can be reset at any time, so it is 
necessary to check these controls each frame. This routine allows 
different game variations to be selected—if a game is not already in 
progress—and, if a game is in progress, it also checks to see whether 
time is almost up and the score should be blinking. This routine also 
underscores the fact that the programmer is responsible for handling 
every interaction on the machine. The Atari VCS has no operating 
system to intercept inputs and respond to common ones. Thus, even 
though the reset switch is clearly labeled “reset” on the console cabinet, 
it is up to each cartridge programmer to write a program that responds 
to the switch being pressed. The programmer can choose to have a 
cartridge do something other than reset the game when the reset 
switch is closed, just as different games might use the joystick button 
for different actions. Although this was rare, there are examples of 
games that override the function of the console switches as printed 
on the console.

- Ken