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

[Adam Michlin]

Let me play devil's advocate, though.

The original request was for books to recommend about our hobby to rank 
beginners (adults with at least a little macOS or Windows experience).

I *love* "Racing the Beam". I just don't think it fits the criteria. I 
think it would scare the average person away.

Now, to give people an idea of other directions I'm going with lists, it 
might just be a candidate for my list of 5 books for Computer Science 
teachers that want to integrate history into their teaching. But I teach 
6502 assembly and make all my students play Atari 2600 Adventure... 
maybe I'm just weird :)

On 9/13/2020 8:00 PM, Ken via vcf-midatlantic wrote:
> 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
>
>