It’s 2016, so we’ve have almost 39 years since the Atari 2600 was released. Let’s write a game for it.
Let’s write a game for a machine with 128 bytes (~characters) of memory, marginally “crap” graphics, and a 1 MHz processor. We’ll write it mostly in 6502 assembly language, and design graphics, sound effects, music, and dialogue. In order to get it to anyone, we’ll have to build cartridges with the game’s ROM and some control circuitry, build cases for them, labels, a manual …
Oh, and of course the 6507 CPU in the Atari is also used in a bunch of other computers from the 1980’s: The 6502 in the VIC-20 and Apple ][, as well as the Atari 400, 800, 5200, and 7800; the 6510 in the Commodore 64, the 8502 in the Commodore 128, the 2A13 in the Nintendo Entertainment System, all are more of less the same processor. The big brother 65816 is in the Super NES and Apple //gs. Totally different memory arrangements, of course, and different video hardware, audio systems, even input devices. Let’s try to produce a single game that’ll be playable on several of these.
OK, well, maybe it’s just me. But, while we’re at it, let’s design this on a modern Linux system with top-of-the-line development tools.
Here’s what I’ve chosen for starters:
- The main editor for the program code is, of course, Emacs.
- The toolchain that will compile the art, music, maps, and so forth into assembler-friendly data files will be in Common Lisp — and I’m not going to be too shy about being SBCL-specific, Linux-specific, or even Fedora-specific if it makes any difference. This tool is basically just for me, but if someone wants to use it elsewhere, they might have to do a little hacking.
- For the tool, I’ll use CLIM for the interface. Restarts will appear in the CLIM Debugger, the CLIM Listener and Climacs will be available at build time, and if there’s anything that makes sense as a general-purpose tool, I’ll build it in CLIM as well. Among other things, this means that interactive building tools can use rich text and embedded graphics for their output cheaply. Nonetheless, it must remain possible (in the “no errors” case) to run a headless build and capture a reasonable (text only) log file output from the process.
- The size of the build tool is unimportant, but I’d like it to run on a sub-$300 notebook without choking.
- For graphics, we’ll use Gimp XCF files, but we’ll hack on Gimp a little. A Gimp (Guile) plug-in for exporting as PNG, and some palettes for Gimp to make it easier to hit the various color palettes of our target machines.
- Atari gets first dibbs, followed by Commodore 64, and then we’ll see what else I have time (or interest) to build.
- Music will be imported from General MIDI files, but I haven’t set my heart on any particular editor. In fact, it’ll probably mostly be Public Domain or Creative Commons classical music.
- For maps, Tiled wins. Yes, I made a donation to the author, too. Eventually, my own Hath will probably replace it, as this project will probably eventually merge with Hath altogether.
- Ideally, let’s write a scripting system that supports a reasonable subset of Lisp and writes out native 6502 code.
- The assembly source files should be 64TurboAssembler (64tass) compatible.
- The game needs to be runnable in Stella, Vice, and the like.
- Ideally, anybody with Gnu Make and SBCL installed should be able to do a one-step build — so, it ought to be able to bootstrap the whole toolchain with DNF in some rational way.
So, some arbitrary choices I made up front, based on things I like to use or think are nice to work with.
So, now what? Oh … we need a game.
Let’s talk about that next time