Inside the Homebrew Atari 2600 Scene
Pages: 1, 2
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.
2600 Homebrew Resources
Return to the LinuxDevCenter.com.