The Developers Speak

Homebrew game authors Andrew Davie, Joe Grand, Thomas Jentzsch, Simon
Quernhorst, and Paul Slocum discussed with the O'Reilly Network their
experiences in making games for the Atari 2600.

O'Reilly Network: What inspired you to make your own Atari 2600 game?

Andrew Davie: I had many games under my belt, but only as
programmer/designer. I'd not had the opportunity to develop a full product from
concept through programming, marketing, and sales. I saw the 2600 as an ideal
platform to do all of these in one go. I also happen to adore the 6502
processor -- the Atari has a variant of this, and was fascinated by the
technical challenge of getting the machine to do anything, let alone
something interesting. I was originally motivated by Bob Colbert's pioneering
work on Okie Dokie.

Thomas Jentzsch: I must admit that I had almost completely
forgotten my Atari 2600 when I accidentally found a working emulator for it on
the Web. But almost immediately I remembered the fun I had back then. Soon
after that, I found the Stella developers group and saw a new challenge for my
Assembler programming hobby.

Simon Quernhorst: I'm a collector of Atari VCS cartridges
for years now, and I decided to start a development project in 2001. I've been
programming demos and games for the Commodore 64 for years. Therefore, the
machine language of the VCS was nothing new to me -- just different
addresses had to be learned and checked. (Quernhorst created A-VCS-tec, as seen
in Figure 3.)

Figure 3. A-VCS-tec Challenge by Simon Quernhorst

Joe Grand: I was already collecting cartridges for the
Atari 2600, and I wanted to work on a project that combined my hobby and my
professional life -- electrical engineering. Not only did I code the game,
but I created a custom circuit board. The boards fit into the standard Atari
cartridge cases and all components are easily obtainable at many electronics
stores. This made the manufacturing process much easier and less frustrating. I
built the first 50 games by hand to sell at a gaming expo and sold out almost
instantly.

Paul Slocum: The challenge of programming for such a
minimal system, and I really wanted to when I was a kid. I actually still have
game designs I drew up in elementary school, although I don't think many are
feasible on the 2600.

O'Reilly Network: What's your personal favorite Atari 2600 game? Why?

JG: Activision's Kaboom!. It's the type of game that forces you to get "into the zone" and just space out. It's a very "Zen-like" game. It was the inspiration for SCSIcide.

AD: I don't really have a favorite. I am mostly
interested in the technology, rather than the game itself. Having said that, Dig Dug was a very good conversion effort, so I'm partial to that at the moment. Many of the modern homebrews are excellent.

SQ: I'd mention H.E.R.O.
It's really good and was well-designed overall. I also enjoy most of the modern homebrew games. Just to mention a few: Qb, Star Fire, Marble Craze, Merlin's Walls, and Thrust (Figure 4).

Figure 4. Thrust by Thomas Jentzsc

TJ: From the classic period, Starmaster. It was one of the very few games I owned, and it combined action with some strategy. I was very addicted to the game back then.

From the modern homebrew games, Oystron. This was one of the first homebrews I found, and it is a great game. It was Oystron that made me want to program my own game. It defined a new
level for Atari 2600 homebrewing and showed that a homebrew game could match
the old classics.

O'Reilly Network: What interesting technical challenges did you came across when you
made your game?

PS: I made it extra hard on myself by doing a
paddle game. Paddles must be read while displaying whatever's on the screen,
and timing is critical during the display. Since SCSIcide was the
first homebrew game to use the paddle, there was no previous work to
reference.

One byte of RAM was used to store the current numerical value of the paddle.
At the beginning of each frame in the vertical blank, the capacitor inside of the
paddle controller is discharged and, a few cycles later, set to recharge.
During every scanline draw, the value of the capacitor is read. How long the
capacitor in the paddle takes to charge determines the vertical position of the
[player character] on the screen.

For example, less resistance in the potentiometer of the paddle will cause
the capacitor to charge more quickly, and place the [player] towards the top of
the screen. If the paddle is moved in the other direction, increasing the
resistance of the potentiometer, the capacitor will take a longer time to
charge, and the [player] will be placed lower down the screen. Programming
efficient and "non-fluttering" paddle control took the longest amount of
development time and required a great deal of experimentation with the Atari
2600 system.

SQ: The Atari VCS can only handle banks of 4kb at one time, and a technique called "bankswitching" is used to access more
ROM. You can tell the machine which of the 4kb banks is currently in use and
access this ROM then. The problem is that the memory is always numbered in the
same way. This means that an address $0F00, for example, is used
two times; once in Bank 1 and once in Bank 2. When jumping from one bank to the
other, the processor jumps into Bank 2 at just the address where you left Bank
1. For example, a bankswitch command at $0E03 in Bank 1 lets the
processor continue at Address $0E06 in Bank 2.

O'Reilly Network: Did you develop any unique code that takes advantage of the Atari
2600's technology?

TJ: For Thrust, I invented a smooth
looking, bi-directional "delayed" scrolling that is still quite unique for the
2600.

JG: My proudest achievement was implementing the
paddle support, but I also created a six-digit hexadecimal scoring routine based
on some old score display code, and implemented a cool random number to
generate the random color and location of the data bits on the screen.

AD: The Interleaved ChronoColour technology was
independently developed, but does duplicate similar technology already
available on other machines. It introduces "full-color" bitmap images on the
Atari 2600, where previously only single-color-per-pixel images were possible. This
has extended the graphics capability of the 2600 significantly. The technology
involves real-time multiplexing, in time and space, of red-green-blue-component
images to achieve a color image.

SQ: I invented a PAL/NTSC-switch on
Mental Kombat. As far as I know, no other game now uses this
technique. This makes the cartridge run on any machine worldwide without
problems or mixed-up colors.

PS: I'd say my most innovative work was with
music. I wrote a music driver that managed to do fairly decent music in spite
of only having two sound channels and very limited pitch. And the driver uses
very little processor time, so you can easily run it in the background
in-game.

O'Reilly Network: What advice do you have for others who are interested in making
their own homebrew games for the Atari 2600?

SQ: If you already know assembly and machine
language: take a lot of time and patience and prepare for a very exact
programming challenge. The 2600 is very timing-sensitive. Using too many
cycles in one scanline may, for example, lead to mixed-up graphics and colors.
In very timing-sensitive routines, counting the cycles of every operation by
hand might help to ensure that you're not using too many cycles.

JG: Experiment, experiment, experiment, and be
patient! There are a huge number of resources available now that provide
disassembled games, commented source code, development tools, emulators, and
discussion lists.

It might appear easy, since there are so many homebrew game projects going
on right now. But take small steps and play around a lot. That is the best way
to learn. There are lots of people in the community willing to help out new
developers.

Writing a game takes time, as does thinking up graphics and packaging,
making the cartridges, etc. You won't make a quick buck, so only do it if you
love it.