Friday, November 26, 2010
Atari 8-bit Programming and You
Wow, I have something to write about!
I've been doing some preliminary studies on Atari 8-bit programming. Which means I've pretty much come full circle, because the Atari 400 was really the first computer I ever "programmed." So far my studies have included:
- Reading Racing the Beam, the book on 2600 games. An interesting read for a top-down perspective on early Atari programming. Yeah, it covers the Atari 2600, but the 8-bit computers were essentially based on a heavily upgraded 2600 design. It's still all player/missile graphics and playfields, and there's a similar general programming approach to them. While an interesting read, Racing the Beam isn't a technical manual, so it lacks a lot of the information that would be needed to actually write programs. It does give one an excellent starting point for getting into the Atari mindset, though.
- Reading De Re Atari, ANTIC Magazine, and other old references. Turns out my dad actually wrote a comprehensive-but-terse Atari reference that's been floating around on the internet for a while, and it's one of the foremost documents on the platform now. Who knew?
- Setting up a dev environment. MAC/65 and the Atari Macro Assembler are available on different sites, and it's interesting to try and work with them, line editing and all. I'm a bit of a purist in this regard, and I remember typing in programs from ANTIC when I was a kid* so... I'm not really tempted to write code in Vim and cross-assemble. I am, however, somewhat tempted to try and write a screen editor in the same vein, maybe even do some rudimentary syntax highlighting...
So, with my background in Nintendo DS hacking, it's interesting to look at the features and limitations of the old 8-bit computers.
For instance, in the more common graphics modes, you have access to "playfield" graphics, 4 players, and 4 missiles. The playfield is a bitmap that fills the entire screen, if you like. That's it. Then you have the players, which are 8-pixel-wide strips spanning the entire height of the screen. Your player graphic occupies a small part of this strip, you can move the strip horizontally through a register, and to move the image vertically you rewrite it to a different portion of the strip. Player graphics are accelerated in hardware and draw quite smooth. Missiles are similar to players, except they're 2 pixels wide, and take their color from the player they're associated with (or you can switch them into a special mode where they emulate a fifth player). What's nice is that collision detection is supported in hardware for all the players, missiles, and the playfield, so you don't have to write costly collision detection code.
Now, the thing about the playfield is that it takes a lot of computational time to change it around, so you can't really animate it that much. No scrolling backgrounds, then. You're also pretty tightly limited in the amount of stuff on the screen, though you can still employ tricks like flickering one player back and forth horizontally to make it appear to be two.
It's fun to look at the existing games and try to figure out what combination of playfield, player and missile graphics were used to put it together. The older-looking games obviously use the hardware without any special tricks, and newer games definitely have more interesting stuff going on software-wise.
*Ahhh, ANTIC. I think I managed to get a grand total of one game typed in and actually running. All I remember of it is vague graphics, though.
¶ 2:47 PM
