Racing the Beam (2009)(mitpress.mit.edu)
mitpress.mit.edu
Racing the Beam (2009)
http://mitpress.mit.edu/books/racing-beam
7 comments
This book is so informative it's unbelievable. I really hope Nick and Ian keep doing these platform studies because there is nothing else like them out there right now. A few things about the Atari 2600 make this book fascinating. It's like reading about some weird ancient civilization and how it tried to build nuclear bombs out of sticks and stones.
Case in point: The Atari 2600 had no screen buffer. You drew lines on the screen in real time, as the electron gun was firing. As the gun moves, so does your code, immediately rendering whatever is being drawn by the gun. This means everything had to be calculated at the exact moment the electron gun is where you want the tank to be drawn. It all took place through the TIA chip designed by Joe DeCuir and others at Atari.
Additionally, drawing the background of the screen was even more difficult, as the Atari 2600 could only address half the screen: you had to mirror whatever background was on one side, onto the other side of the screen, mirrored vertically.
But wait, it gets even more complicated! That one side of the screen was composed of 20 columns of possible addressing, making for 40 columns total across the screen. The 20 columns you could address on the left side of the screen were numbered, and I am not making this up, as follows:
1 2 3 4 5 6 7 8 8 7 6 5 4 3 2 1 1 2 3 4
That means you addressed the first part of the screen in ascending, left to right. Then, you had to draw right to left in reverse order (though numerically, it was still ascending), then you had 4 more bits to address, left to right.
Absolutely nuts. You can actually see the graphics if you look at the assembly of a 2600 game because the graphics were literally dot, no dot. The graphics were stacks of one's and zero's. Check out these Distella maps. They're in the NY MOMA, and the MADE. http://benfry.com/distellamap/
Case in point: The Atari 2600 had no screen buffer. You drew lines on the screen in real time, as the electron gun was firing. As the gun moves, so does your code, immediately rendering whatever is being drawn by the gun. This means everything had to be calculated at the exact moment the electron gun is where you want the tank to be drawn. It all took place through the TIA chip designed by Joe DeCuir and others at Atari.
Additionally, drawing the background of the screen was even more difficult, as the Atari 2600 could only address half the screen: you had to mirror whatever background was on one side, onto the other side of the screen, mirrored vertically.
But wait, it gets even more complicated! That one side of the screen was composed of 20 columns of possible addressing, making for 40 columns total across the screen. The 20 columns you could address on the left side of the screen were numbered, and I am not making this up, as follows:
1 2 3 4 5 6 7 8 8 7 6 5 4 3 2 1 1 2 3 4
That means you addressed the first part of the screen in ascending, left to right. Then, you had to draw right to left in reverse order (though numerically, it was still ascending), then you had 4 more bits to address, left to right.
Absolutely nuts. You can actually see the graphics if you look at the assembly of a 2600 game because the graphics were literally dot, no dot. The graphics were stacks of one's and zero's. Check out these Distella maps. They're in the NY MOMA, and the MADE. http://benfry.com/distellamap/
I haven't read the book yet, but David Crane's Pitfall Post Mortem[1] also covers a lot of what you mentioned. Truly fascinating stuff.
[1] http://www.youtube.com/watch?v=MBT1OK6VAIU
[1] http://www.youtube.com/watch?v=MBT1OK6VAIU
While we are on the topic of post-mortems for old games, I enjoyed Bob Pape's writeup of his port of R-Type to the ZX Spectrum.
You can get the free eBook here: http://bizzley.com/
This is a really great book.
One underappreciated aspect of the games industry is the extent hardware dictates game design. This is very clear on the 2600 where the limitations were ludicrous by modern standards, but extends through the tile and sprite acceleration hardware of the 16 bit era to the present day with issues like touch control or video processing latency making the very reaction driven titles that were so common on the 2600, by virtue of the limited time you had to process an update and the direct manner the video signal was produced, practically impossible on modern hardware.
One underappreciated aspect of the games industry is the extent hardware dictates game design. This is very clear on the 2600 where the limitations were ludicrous by modern standards, but extends through the tile and sprite acceleration hardware of the 16 bit era to the present day with issues like touch control or video processing latency making the very reaction driven titles that were so common on the 2600, by virtue of the limited time you had to process an update and the direct manner the video signal was produced, practically impossible on modern hardware.
Not sure why this is hitting Hacker News now, but it's an excellent book about game design and designing given the constraints of hardware. Highly recommended.
The book has been mentioned many times on HN. People just recycle or rediscover stories. You see resubmitted stories almost daily, right?
Buy this book. Buy it right now. It is an incredible read. It is an absolute riveting page turner that I could not put down until I had finished. Seriously.
I have this (it's available in Kindle format from Amazon), it's fantastic.
See his website too http://www.bogost.com/games/a_television_simulator.shtml
An excellent book. I'm glad it's hitting front page of HN. I think that any aspiring game developer should read it.
The focus was much closer to the metal in those days - working with the 2600's extreme limitations forced them to come up with some crazy solutions.