Stellaaaaa!

I found a great online development environment for the Atari 2600 console at 8bitworkshop.com. I noticed the URL while skimming through a book on Amazon entitled Making Games for the Atari 2600, by Steven Hugg.

There are a lot of great code examples on the site, but the most useful thing about it, IMO, us the fact that your code is compiled and executed as you type. Being able to instantly see the result of your changes is incredibly convenient. Also useful is the timing calculations that the site can do on your code. If you want to do any tinkering with Atari 2600 code, be sure to check that site out.

As for my castle program, I did some more work on it over the weekend. I tightened up the castle drawing code a little bit and made the castle a little taller. I also got rid of the shading on the grass for now; I want to save as many cpu cycles as possible for the time being. The colors are a bit dark and need to be tweaked, but I’ll do that once I have actually sprites moving around so I can get a better sense of what colors will work best.

In the screen shot above you can also see a ballista in the castle courtyard. This is going to be the player. It doesn’t actually do anything yet, but eventually the player will able to move the ballista left or right within the castle walls.

Once player sprite motion is implemented I’ll work on making it shoot arrows up at the sky. I have some animation frames drawn for the firing of the ballista which I hope to be able to add in as well.

I came up with a ton of ideas to add to the game over the weekend as well, including different enemy types, power-ups, difficulty settings and even a possible boss battle. If I don’t lose interest too soon, I think I can make a pretty enjoyable game out of all this.

Atari 2600 Programming

It’s been a while since I last looked into writing programs for the Atari 2600. The last thing I was messing with was drawing a sort of castle onto the screen. I was having a bit of trouble with that and my interest eventually just petered out.

I recently returned to this project and got the castle to draw nicely. I then added a sky and grass to the background, then I added some fancy shading to the grass. Here’s a screenshot of what I have so far:

I would like to eventually use this as the basis for some sort of game. The idea currently swimming in my head is to have the player control a ballista inside the castle which he could move to the left and right. Dragons would fly across the screen in the sky and the player would have to shoot them.

The dragons would vary in color, with certain colored dragons being faster than others. The dragons would also shoot fireballs down at the player. If possible, it would be cool to add swooping dragons as well.

We’ll see if any of that ends up happening.

I’m experimenting with drawing sprites right now (sprites are things that can move, like the player for example). I’ve managed to get the player 1 sprite to display, but it’s not anything usable for a game yet.

I’m optimistic that I can get a moveable player on the screen soon. I’m a little worried that the sprite logic might force me to simplify the color gradient for the grass — processing power is very limited on the Atari.

I’ll probably post the source code for this program once I have a moveable player implemented.

Atari 2600 Programming

atari 2600When I was a kid, our family had an Atari 2600 Video Computer System, as did many of our friends and relatives.  We had a good number of games, and many great memories were made playing them.

A few years back I got a book (Racing the Beam: The Atari Video Computer System, by Nick Montfort and Ian Bogost) that talked about how those old games were programmed.  It was quite fascinating.  The approach to programming the Atari 2600 is quite a departure from what I do every day as a software developer.  I gained a lot of respect for the old Atari game programmers; they performed incredible feats of coding.

More recently, on a whim, I decided to read up on Atari 2600 programming about a month ago.  Here’s a little bit of what I’ve learned:  To run games, the Atari 2600 uses a MOS Technology 6507 microprocessor (a variant of the MOS Technology 6502, a generic 8-bit microprocessor which was first produced in 1975 and is still used in hundreds of millions of devices to this day).  This is the central processing unit: the chip that executes the software written by Atari programmers.

The central processor interacts with two other chips.  One is the MOS Technology 6532, another generic chip designed to provide RAM (only 128 bytes — your computer probably has at least eight billion bytes or more), a couple of I/O ports for interfacing with peripherals (e.g. joysticks), and a timer. The other is a custom chip called the Television Interface Adapter (or TIA), nicknamed “Stella”.  The TIA is responsible for generating the signals that are sent to a TV in order to generate images and sound.  The TIA was designed to keep costs down, and cost-cutting measures led to the chip exhibiting some very peculiar behaviors which required arcane knowledge and carefully timed commands to effectively control.

After learning about programming the 6507 to control the TIA, I’ve discovered that the Atari’s reputation for being notoriously difficult to program games for is not overstated.  First of all, in 1975 we didn’t have computers powerful enough to provide layers of abstraction between the programmer and the hardware which act to simplify programming tasks. The Atari requires coding in an assembly language — literally the lowest level of programming possible in a computer (sometimes called “bare-metal” programming because of the programmer’s metaphorical proximity to the physical hardware).

To illustrate the difference between modern software development and programming in assembler, imagine that you want to write a poem on a piece of paper.  Modern programming is like you grabbing a pencil, then manipulating that pencil to write the desired words on a piece of paper.  With assembly programming, if you want a pencil, you can’t just grab one — you have to first chop down a tree to get some wood, mine some graphite out of the ground for the lead, etc.  Programming in assembler for the Atari’s Stella chip is like you having to time those axe and pick swings in step with your heartbeat or you die.

The ultimate testament to the skill of the original Atari programmers is the fact that the games for the Atari 2600 could not be longer than 4096 bytes.  The entire text of this blog post you are reading takes up a little bit more than that!

So, I decided to try my hand at doing a little Atari 2600 programming myself. I followed a tutorial by Andrew Davie to get started.  Unfortunately, some of the code examples had bugs in them that made learning Atari programming very frustrating at times — I had to debug code that I was in the process of learning!

Here is my first Atari 2600 program (hosted on Google Drive — please leave a comment if there’s a problem with the link).  All this program does is display a Canada flag.  It might not seem very impressive, but if you’re familiar with Atari programming you’ll know it’s no trivial task.

canflag0 screenshotThis zip file contains the compiled ROM that you can load up and run in an Atari emulator like Stella (named after the Atari’s custom chip).  If I had the hardware, I could literally burn this ROM file into a writable Atari cartridge and run it on an actual Atari 2600 machine.

Also included is the source code to which I’ve added copious amounts of comments to make it easier to follow (feel free to tinker with it), and a symbol dump file generated by the program that compiled my code which shows exactly how each command in the source code is converted into numbers that the 6507 can understand.

Also, if you’re interested, here is a PDF of the 1979 Stella Programming Guide.

Edit: Spiceware has also put up an excellent programming tutorial as multiple topics on the AtariAge forums.