Tao Te KaChing
Workin' the cash register of the Great Tao

Programming the Atari 2600, and Me - Part 1

UPDATE: Linux-based version of this solution is here


I have always had an urge to test my programming patience against the Atari 2600, but to start, always lacked the game idea.  I have a two year old and 6 month old, and recently in my lack of sleep, had a revelation for the lamest game ever.  I have since not been able to stop my attempt to realize this game.

This series will be for aspiring Atari 2600 programmers.  I know there are many, many of you out there.  Perhaps seeking fame, perhaps fortune.  Either one won't be found in this endeavor.  IT IS THERE BUT TO DO IT!  FOR THE GLORY!

…but I digress.

There is a fair amount of good resources out there for starting your 2600 project, but it's all over the place.  There have been several ah-ha grokking moments after thinking I'd already understood how someone explained something (i.e. not easily understood explanations), and also some actual misinformation that required making some tests in order to them prove wrong.  At no point will I claim this to be a definitive guide, but hopefully will provide a set of solid tested steps to get from Point A to Point B.

I hope this series becomes a good resource for a massive 2600 gaming revival.  After playing Pitfall! and River Raid a few times, I realized just how truly awesome my PS3 is, but still enjoy those old games for a few minutes a day…or week…

…I digress again.

First place to start: a build environment.

I knew there would be many, many a compile-and-run.  What was sort of difficult to find out there was a good IDE for this.  That's probably because we're now in the age of Eclipse and Visual Studio and there kind of isn't (and never was) a “Visual Studio for Atari 2600”.

Finding an editor was easy.  If you're on Windows, Notepad++ is excellent.  Really any text editor is just superb for our task.  What we want, though, is to be able to click a button, have the assembly compiled, and have it execute right then and there.

I opted for two tools to solve this dilemma: SciTE and Stella.  SciTE is a perfect WYSIWYG, easily configurable text editor.  The easily configurable was the key here, as I was able to implement my compile command in about 2 minutes.

Stella is our Atari 2600 emulator we'll use for “running” our program.  I also used the Z26 emulator, but quickly got too accustomed to Stella's display of the fps and video type (NTSC vs. PAL).

For compiling the assembly, DASM seems to be the assembler of choice for 2600 homebrews, as it even includes VCS.h – a header file with all the necessary pointers to the 2600 hardware – in the distribution.

I created a directory C:\MyGame and sub-directories for SciTE C:\MyGame\IDE and DASM C:\MyGame\DASM.  With this setup in mind, I launched SciTE to add the compile command.  Since we'll be working in assembly language, I went to the language-specific settings:


From the Options item in the menu, we find assembly (.asm extension) –specific settings:


Scrolling down to the bottom of the asm.properties file, we find (or add) the compile command:


The command reads:

command.compile.$(file.patterns.asm)=C:\MyGame\IDE\exec.cmd $(FilePath) $(FileNameExt) $(FileName)

The SciTE macros FilePath, FileNameExt, and FileName are passed to a simple batch file exec.cmd, which looks like:

cd c:\MyGame\dasm
copy "%1" %2
dasm %2 -f3 -o%3.bin
"c:\program files\stella\stella.exe" %3.bin

Ergo, go to the DASM directory, copy my current assembly there, compile it, then launch in Stella.  Done.  Simple, effective, works like a charm.

Try this same setup with some of the assemblies out there to get a feel for SciTE and Stella.  There are some assemblies here to try out.  Also, DiStella is a disassembler for Atari 2600 ROMs.  I'm running this massive development solution on 64-bit Windows 7, so I needed DOSBox to run it.

Next, we'll take a look at the Atari 2600 architecture…