Re: [vcf-midatlantic] Not quite so linked lists (of books)
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 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. - Ken
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
participants (2)
-
Adam Michlin -
Ken