oreilly.comSafari Books Online.Conferences.


Inside the Homebrew Atari 2600 Scene

by Howard Wen

"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.


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.

Pages: 1, 2

Next Pagearrow

Linux Online Certification

Linux/Unix System Administration Certificate Series

Enroll today!

Linux Resources
  • Linux Online
  • The Linux FAQ
  • Linux Kernel Archives
  • Kernel Traffic

  • Sponsored by: