[vcf-midatlantic] Not quite so linked lists (of books)
kenzolist at lastever.org
Sun Sep 13 20:00:29 EDT 2020
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:
I strongly second Adam's recommendation of "Racing the Beam: The Atari Video Computer System," written in 2009 by Nick Montfort and Ian Bogost.
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 programs
display manually to the screen, synchronizing the 6507 processor instruc-
tions to the televisions 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 televisions electron beam.
Some graphical effects demand changes to the TIAs 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 TVs 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 Combats 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 selectedif a game is not already in
progressand, 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.
More information about the vcf-midatlantic