The Atari VCS, later renamed the Atari 2600, had a unique design that made it famously challenging to develop for. Whole books have been written about that process, such as Racing the Beam from MIT Press. Hobbyists have been tackling the challenge of making new games for the 2600 since nearly the end of that system's long life. Some of them appear in officially-released collections, such as a fanmade Adventure sequel appearing on the Atari Flashback.
Lately, the cartridge format has allowed the use of an old trick, that of including extra hardware in the cartridge to increase the capabilities of the main system, to make possible games that are much more complex than were possible during the Atari’s heyday. One group making Atari games with frankly amazing visuals and play is Champ Games. They agreed to talk with us about how they overcame the 2600’s legendary limitations.
The market for games for retro consoles is necessarily a niche one. How is business going for you? How do you promote your products?
Since Champ Games is a hobby, it’s not treated the same as a typical business as far as marketing is concerned. We mainly promote through social media (Facebook, Twitter, YouTube and Instagram) and through the AtariAge website forums.
We also have a dedicated website that has information on all of our games and upcoming projects, as well as an online store for purchasing digital copies. Physical distribution (Atari cartridges with professionally printed labels, manuals, and boxes) is done through our publisher AtariAge, and they will promote our games as well.
Additionally, we promote our games by attending classic video game conventions (like the Portland Retro Gaming Expo) where we have our games set up to play and can meet other classic gaming enthusiasts.
Something I find about games for some systems is that there is almost a feel to them, a style of play that one can come to associate with the platform. Some of this is probably subjective, but in the games of the Atari VCS/2600, in particular, because it builds its picture in a way that requires the 6507 processor's constant involvement, always make their framerate targets, otherwise they can't display much of a picture. To me, it feels like there's a sharpness to the play of 2600 games because of it. Would you say that its method of building the display in real-time, "racing the beam" so to speak, the Atari has advantages over competing platforms at the time, like the Intellivision or Colecovision?
Although I am not familiar with how games, and in particular the video picture, are developed for other systems, I can say that the ‘racing the beam’ aspect of Atari 2600 development is what intrigued me the most in developing games for that platform. Even in 2023, with all the hardware enhancements, extra ROM/RAM, coprocessors, etc., in the end, you are still confined to ‘racing the beam’ in 76 machine cycles per line, updating registers at specific moments with limited sprites and a low-resolution playfield. Since you are drawing the screen in real-time, you cannot have the game ‘slow down’ if too much is happening as this will make the screen roll, so you are constantly making adjustments and compromises to make sure you can always execute all of your game logic in one frame. The advantage, of course, is the silky-smooth gameplay that is a hallmark of 2600 games.
Champ Games' products take advantage of one of the greatest advantages of the cartridge software format: that it can include extra hardware in the unit. What does the internals of a Champ Games cartridge look like? Is it something you can tell us about?
Most of the newer Champ Games take advantage of the latest technology, including a coprocessor chip in the cartridge. Although we do not directly develop the hardware, I can tell you that the circuit board in the cartridge (called a “Melody board”) that contains an ARM chip (70 Mhz) that emulates the various bank-switching schemes, including extra ROM (up to 256K) and RAM (up to 64K, as well as Flash memory (up to 128K). Various bank-switching schemes have been developed to leverage these additional resources (DPC+, CDF, CDFJ, CDFJ+) that Champ Games uses in most of our games (although some of the original games like Lady Bug, Conquest of Mars and Avalanche are pure 6502 assembly with no additional RAM or coprocessors).
Unlike the NES, which was designed with some extensibility in mind, the VCS/2600 platform has some specific limitations, like the absence of a memory write line out to the cartridge that makes the use of external RAM difficult. How do you manage to get around these limits?
Back in the ’80s, the Atari engineers and other third-party developers figured out how to implement ‘bank switching’ that allowed games to use more than 4K of ROM to store game code, graphics, sounds, etc., with the limitation being that you could only access one 4K ‘bank’ at a time. They also developed schemes that allowed you to increase the amount of RAM accessible to your game by reserving lower ROM address lines as read/write registers (this is also how they were able to get around the lack of a read/write line). Our early games used these standard bank-switching schemes to expand the available ROM from 4K to 16K (we did not use any extra RAM, only the 128 bytes available in the RIOT chip).
At or around 2010, technology was developed that utilizes an ARM chip in the cartridge (which is emulated in emulators like Stella, etc.). The original intention of the ARM chip was to emulate the various bank switching schemes to support all existing 2600 games, including Pitfall 2, which required emulating the DPC chip (created by David Crane) that allowed for more RAM, faster updates to registers, and a 3-voice music chip. The engineers that developed this figured out a way to leverage the power of the ARM chip (70Mhz) before and after the screen is drawn, where you have access to the ARM ROM and RAM (up to 256K of ROM and 64K of RAM). Additionally, you are able to execute ARM code (written in C) during these time intervals to execute game logic and populate data buffers that are then accessible from the Atari to update its own registers (graphics, sounds, etc.).
Your ports are known for a fairly high degree of accuracy compared to the originals, despite the limitations of the platform. For example, the behavior of the cats in your port of Mappy seems fairly accurate to the arcade. How do you reproduce the algorithms of the arcade originals? How close is close enough, would you say?
All the algorithms in our games for movement, patterns, etc. are interpreted by sight and sound; we do not reverse engineer or disassemble the original code. One of the strengths of Champ Games that we are proud of is that we are able to capture the ‘feel’ of the original game without duplicating it exactly. Also, since most of our games are ports of arcade games that were originally meant to be ‘quarter-eaters,’ we do take liberties to modify or update specific parts of a game to make it more accessible and enjoyable to the casual player while still maintaining that ‘feel’ of the original.
Most of our games also offer additional challenges (levels, enemies, obstacles, etc.) not found in the original game as well as multiple skill levels to give the player a different experience than just playing the arcade game on an emulator like MAME, etc.
The VCS/2600 has just 128 bytes of RAM! So I gotta ask: how did you manage to store and display the playfield in Zoo Keeper, specifically?
As mentioned above, even in the '80s, Atari and other companies figured out not only how to expand the available ROM from 4K to as much as 32K, there were also ways to expand the available RAM from 128 bytes. Games like Dig Dug and Galaxian used the ‘Super Chip’ which expanded the ROM from 4K to 16K and doubled your RAM from 128 bytes to 256 bytes. Since there is no read/write line, the Atari engineers figured out how to use ROM locations to trigger a read/write to expanded memory.
Regarding Zoo Keeper: Atari actually had this game in the pipeline back in 1984, although it was never completed (just the sounds and some animations were done). My guess is that they would have used a Super Chip-type scheme to store that playfield.
In our implementation, we were lucky to have 2K of RAM that is accessible from the ARM chip. This is used to store the playfield brick pattern for 2 players and can even store ‘partial’ bricks that haven’t been completely removed. If ZK was done back in the day with 256 bytes of RAM, I would think it would have been 1-player only and most likely would have stored bricks being on/off vs. partial bricks (like Breakout).
Up until now Champ Games has mostly dealt with classic arcade ports. What are you working on next? Do you have any plans for original software for the VCS, or maybe for other systems?
Right now, we are completing work on two more ports: Turbo Arcade (a port of Turbo; we added on the ‘Arcade’ to distinguish it from the prototype that was developed by Coleco back in the '80s). We are also finishing up a game called “Elevator Agent” which gets its inspiration from the arcade game “Elevator Action.”
We have also started development on an original game called Mountain Raider. It’s a game that a friend and I designed back in 1982 (we even sent the ‘plans’ to Atari, but sadly it was rejected). It can best be described as a side-scroller treasure-hunting game where you pilot a spacecraft for part of your mission and you’re on foot roaming through the inside of the mountain for the other part. It borrows elements from several classic video games but with an original concept and objective.
We have also started development on a line of advanced sports games for the 2600 (the “Champ Sports” series). The first two games will be Champ Sports Baseball and Champ Sports Hockey and will feature updated graphics, sounds, voice, teams, etc. If they are well received, we will consider developing other sports like basketball, football, volleyball, tennis, golf, etc.
We also have numerous other ideas that we are developing as we plan on transitioning to original games vs. ports. We have also considered developing games for other legacy Atari platforms like the 5200/8-bit and 7800. Coincidentally, my first game development was on an Atari 800 computer back in the early '80s (albeit in BASIC) so I would like to ‘return to my roots’ one day and make a proper game in assembly.