Inside the Homebrew Atari 2600 Scene

"Have you played Atari today?" was an ad jingle for the Atari 2600 VCS game
console during its reign in the early years of the video game industry, from
the late 1970s to early 1980s. That question that could apply even now, thanks
to the passion of programmers who've continued to make new Atari games for the past few years. These "homebrew" games come in cartridge form (for use on
actual Atari 2600 consoles) and have free public releases as code that runs on
Atari 2600 emulators. (Homebrew developers use two of the most popular
emulators, z26 and Stella, to test their games.) Emulators have greatly increased the audience for homebrew games outside of those who still own the consoles.

The Atari 2600 homebrew community is the largest among groups who
develop original games for classic video game consoles. (This probably
corresponds with the fact that the 2600 was the top-selling console during its
time. The 2600 was the first video game system for many gaming enthusiasts
who were alive then.) The scene is competitive but friendly, where authors
share their expertise, advice, and even source code with one another and with those
who are looking to program their own homebrew games.

"It's a lot of fun, with various trade meets and video game expos organized
every year. Homebrew development seems to be taking off more than ever," says
Joe Grand. In 2001, Grand released SCSIcide (see
Figure 1), the first homebrew Atari 2600 game to use the console's paddle
controllers (a technical challenge to implement for the system). This
fast-paced "twitch" game -- its theme and gameplay inspired by the inner
workings of a hard drive -- also has the distinction of being the Atari
2600 homebrew game that has sold the most number of copies in cartridge form -- over
200 copies. The 28-year-old, an electrical engineer by trade, resides in San Diego, California.

Figure 1. SCSIcide by Joe Grand

Nostalgia is a primary, initial motivation for most who homebrew their own
games. Many were children during the heyday of the Atari and daydreamed of
making their own games for it. A more practical reason is the challenge; it
takes a certain finesse, and patience, in coding ability to make good games for
the decades-old system.

Linux/Unix System Administration Certification-- Would you like to polish your system
administration skills online and receive credit from the University of Illinois? Learn how to administer Linux/Unix systems and gain real experience with a root access account. The four-course series covers the Unix file system, networking, Unix services, and scripting.
It's all at the O'Reilly Learning Lab.

The Art of Minimalism

Programming the 2600 is the art of dealing with limitations. Developers must find
ways to optimize for speed and limited memory space. The system has
no video buffer, the total code size cannot exceed 4K and can only use 128 bytes of RAM, and, adds Simon Quernhorst,
"you even have to share that with the processor stack. This means that
occupying too much memory results in crashing programs, as you might have
deleted some information used by the processor."

Quernhorst, a 28-year-old IT consultant in Wesel, Germany, created the
puzzler Mental Kombat. At
present, he is making another Atari 2600 homebrew game, based on Aztec Challenge, a 1983 game originally for the Commodore 64 home computer.

In terms of graphics and sound, the Atari only has two sprite objects
-- each just eight pixels wide. The background is restricted to 40 pixels
per scanline. There are only two available sound voices.

To hear these homebrew Atari programmers put it, these very technical
constraints make programming the system ... fun?

"It's a lot like working a puzzle," Paul Slocum describes, "and there's
something satisfying about working so closely with the hardware [and] not
having layers of software between you and the CPU." Slocum, 29, lives in
Dallas, Texas, where he works as an embedded systems programmer. He wrote
Marble Craze and Synthcart, a program that produces music on the Atari 2600. (He even uses the Atari as an instrument in his own
band.) Currently, he's developing an RPG officially featuring characters of the
cult online animated series, Homestar Runner.

"I'm still attracted by the simplicity of gameplay, graphics, and sound. It's
the art of minimalism," says Quernhorst. "The limitations of graphic registers, RAM, sound voices, and colors increase the challenge of getting nice results."

"Because the Atari 2600 hardware is so limited, you must
concentrate on the gameplay," emphasizes Thomas Jentzsch, who has created two
homebrew games for the Atari -- Thrust and Jammed. The 39-year-old is a software developer for a mobile phone company in Düsseldorf, Germany. "The gameplay must be as perfect as possible. Then the player will soon forget the limitations of the system. That makes the biggest
difference between the classic games and many modern 'games' that concentrate
way too much on eye and ear 'candy,' and often neglect the gameplay dramatically."

Bits and Bytes

The tools needed to make games for the 2600 are surprisingly simple. There
are only three: a text editor (many Atari homebrew game developers recommend TextPad), a 6502 cross assembler (such as DASM), and one of the aforementioned emulators (z26 or Stella) to test the code.

The programmer's skillset is more important. Developers need very good
familiarity with the 65xx assembly language in order to understand the
architecture and addresses that set the sprites, read the input devices, play
the sounds, and do everything else on the 2600.

"You must love dealing with bits and bytes, because the Atari 2600 requires
100 percent Assembler coding," warns Jentzsch. "And you need some perseverance; often, coding is quite frustrating and sometimes a solution for a problem seems to be
almost impossible. There are far more abandoned than finished projects for the
Atari 2600, mainly because the programmer burned out."

"It's not actually that tough a technical challenge to program the machine.
But programming it efficiently and effectively is what separates the experts
from the rest," says Andrew Davie, a 40-year-old professional programmer in
Hobart, Tasmania, Australia. Davie developed the game Qb (Figure 2), as well as many technologically innovative programs for the Atari 2600 that other homebrew
authors have put to use, such as Interleaved ChronoColour, which brings full-color bitmap capability to the machine. He's also written several articles guiding newbies on how to program the 2600.

Figure 2. Qb by Andrew Davie

Playing the final product on an actual Atari 2600 system requires that the
code be burned onto ROM chips. Those who are not interested in figuring out the
intricacies required to do this can usually seek out assistance from others in
the Atari 2600 homebrew scene who make game cartridges for the system. The
easiest and quickest way to test homebrew code on an Atari is the Cuttle Cart, is a cartridge that can hold downloaded code.

"There's nothing like playing a game on the real hardware using real
controllers -- emulators can only get you so far," says Grand.

Thanks to emulators and the processing speed of modern computers, the
development process for making Atari 2600 games is far more convenient and
faster now than it was for those programmers on staff at Atari back in the late
1970s. One advantage they had over present-day homebrewers, though, was the availability of better
debugging tools. The members of the Atari 2600 homebrew scene make up for this
by relying upon each other's advice and assistance.

"The hardware, simple as it is, is still not fully understood [by us]," says
Davie. The homebrew scene learned yet more about the Atari when one of the
companies that previously owned the Atari name released additional technical
information to the public. "It's only since the circuit diagrams for the TIA chip [a central component of the Atari 2600] have been available, and since some clever individuals started analyzing the operation of the chip, that we're
coming to understand why the hardware behaves as it does -- and how to use
this knowledge to make effective programs," says Davie.

Display Kernel Issues

Besides the 2600's limited amount of memory, homebrew game developers say
that the most difficult aspect about writing software for it is dealing with
its display kernel. Since the system lacks video RAM, each scanline must be
programmed directly. The picture on the screen has to be drawn in
synchronization with the video beam, which can be a tricky feat to pull off,
and there are only 76 CPU cycles per scanline. The game code must also control
vertical synchronization, repositioning the electron beam at the top of the
screen to start a new frame.

"Following the raster beam, you have to set each pixel and color just in the
right moment to show it. If you want to show a sprite from lines 50 to 60, for
example, you have to set the sprite values by hand at exactly the scanlines 50
to 60 on the correct horizontal cycle," explains Quernhorst. "This makes
variable sprite positioning quite difficult. Such things are much more easy on
other machines, as you can simply set the X or Y values to their registers at
any time during your program."

To squeeze out the best screen display under this restriction, the display
kernel usually has a unique design for each game. The display for an action
game, where objects on the screen move quickly, would need to function
differently from that of a puzzle game, where the objects would probably be
static.

"You have a limited amount of time [for] each TV frame to do game processing
before you have to start drawing the screen again. So you have to guarantee
that under all conditions, your game-handling code will finish within that
amount of time," says Slocum. "This can be tough since you usually have to cut
it close."

Another issue with the 2600's display is that the color order and location
of the data bits on the screen are randomly selected. This routine is a
time-consuming function which, if not executed properly and placed in the right
section of the code, can result in annoying flickering of objects on the
screen. For his game, Grand says he made the decision "to run the routine once
at the beginning of each level, which led to a quick flicker of the screen.
This way, gameplay wouldn't be noticeably affected by flickering every time a
data bit was read."

New Games for Old Systems

All of this extreme, stripped-down simplicity does have one benefit: making
a game can be a one-person effort. "Game development projects for old machines
can be done by single developers, while modern game systems require a lot more
manpower, if you want to make state-of-the-art games for these platforms," says
Quernhorst." It's almost impossible for a single person to create a cool game
on a modern platform. It's easier to develop cool games for the ancient
machines due to their limitations."

Ultimately, it's more than just the challenge that attracts programmers like
Quernhorst and his colleagues to make new games for the Atari -- or for
any classic game console. There's a passion and love, not only for the systems
themselves, but for the community of fans who have been helping the old hardware
remain relevant today.

"It really feels good to know that the time, frustration, and money spent to
develop and manufacture the game was all worth it. It's nice to give back to
the community and provide people with a new game for an old platform," Grand
says.

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.