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.