This book is a must-read for any old-school gamer/programmer style geeks interested in console history. It discusses in some detail the hardware design of the Atari 2600 and how that design effected the games developed for it. It addresses the topic in general, how these decisions effected the history of consoles in general, and then goes on to have six chapters devoted to six specific games.
I had no idea just how raw the system was. There's very little intermediary processing going on between the game code and the display on the screen. For all intents and purposes the game code is basically creating each pixel of the screen in time with the TV tube firing off the electron gun. Thus the title of the book, because there are no clock cycles to spare as the code has to keep up with calculating each scan line in time to get it written to the screen.
Plus the early cartridges only had 2k or 4k of code space. That's some efficient coding there to get the game to fit. Some of the tricks they used to get these games to work are quite interesting.
For example, take Yar's Revenge. You know, this game:
The neutral zone in the middle looks like random pixels, but it's not. There wasn't enough space left for good random number generation code, nor enough clock cycles between scan line to generate convincing random bytes. Another option would be to store a block of random bytes on the ROM and just display those, but that too would not fit on the cartridge. Instead, those "random" lines are actually the code of the game itself being called up for display, each address being selected as directed by the cycle counter that's running the game. I think that's brilliant.
I haven't gotten to the Pitfall chapter yet, but it's been mentioned that the layout of the 255 screens that make up the game were stored in just 55 bytes of space. That averages out to just under 1 3/4 bits of information for each screen. I look forward to reading about how that was accomplished.
"ATTENTION: Customers browsing porn must hold magazines with both hands at all times!"
Hacky tricks. But when your hardware (or software for that matter) can't cut it, hacky tricks look like goddamned magic.
The fact that they pulled off the shit they did w\ the tools they had (programming sucked back in the day) is remarkable.
The '80s would chew up & spit out most developers today.
Diogenes of Sinope: "It is not that I am mad, it is only that my head is different from yours."
Arnold Judas Rimmer, BSC, SSC: "Better dead than smeg."
The system did have some rudimentary procedural calls. The interface chip could track the horizontal location of two sprites for players, two sprites for player missiles, and one sprite for a ball (think Pong and Combat - the tank games - because the hardware was specifically designed for those). It also accepted 2 1/2 bytes to represent 1/2 the playfield and one bit to tell the chip if it should duplicate or mirror the field on the second half. That's all one horizontal scan line, mind you; it had to all be reset for each line on the screen as the refresh continued down vertically. Collisions were returned based on actual pixel overlap between sprites instead of boundary boxes.
The first games all have mirror playfields because that's all they thought would be needed when it was designed. Someone had the bright idea that you could reset the bytes in the middle of the scanning of that line on the screen in order to have asymetrical "playfields".
The horizontal position info didn't overflow, either, it wrapped unless you stopped it. 255 + 1 = 0. That's the source of the bug in Combat that would let you warp your tank across the screen if you angled it just so bouncing off the wall. I remember using that exploit all the time. I was such an ass back then.
"ATTENTION: Customers browsing porn must hold magazines with both hands at all times!"
