Gamasutra is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Gamasutra: The Art & Business of Making Gamesspacer
Back To The Classics: Perfecting The Emulation For Digital Eclipse's Atari Anthology
View All     RSS
May 24, 2019
arrowPress Releases
May 24, 2019
Games Press
View All     RSS

If you enjoy reading this site, you might also want to check out these UBM Tech sites:


Back To The Classics: Perfecting The Emulation For Digital Eclipse's Atari Anthology

January 13, 2005 Article Start Previous Page 2 of 2

Making Atari Anthology

For most of the games in the Atari Anthology we don't have any source code and emulation based on the ROMs is the only possible approach to recreate these games. On the Atari 2600, precise timing down to the microsecond level is crucial for getting the games even close to perfection. The source code, if we had it, wouldn't help at all, though an oscilloscope might.

By modern standards, the Atari 2600 is extremely unusual. The program code and the generation of video signal are completely intertwined. Given that we didn't want to mess around with electronics, our 2600 emulator was converted into a super 2600 debugger. This debugger allowed us to freeze the video beam in time and see exactly what the code was doing at that instant. Or, in fact, by positioning a crosshair anywhere on the window containing our simulated TV screen, another window would tell me exactly what code had been executing at the time that part of the screen was being drawn, and what the state of the simulated CPU was.

If I had one piece of advice to give any prospective emulator author it would be this: The first thing you need to do is write a really good debugger to go with your emulator. It'll save you untold grief later. Getting an emulator to behave exactly like the original hardware is a matter of great tedious trial and error, and examination of detail. When things go wrong, it is invaluable to be able to stop your simulation, look at what state it's in, and be able to wind the "logs" back to find out exactly how it got into that state. This made it possible to hunt down subtle behaviors of the hardware. Run side-by-side with a real Atari 2600 we used a re-programmable cartridge (the limited-release Cuttle Cart, as it happens), we could also download test code into a real Atari 2600 and see what changes might make our simulation diverge from what a real Atari 2600 might do.

As an example of where a good debugger really helps, for the 2600, not only did I have to emulate the chips that were in the machine, I also had to emulate the chips that weren't there! Some 2600 programs access illegal memory and depend on the results, which come back. A normal emulator might return zero. Not good enough; the games just crash. I had to answer the question "If the 2600 reads memory that doesn't exist, what does it see?" This kind of thing isn't covered in the specifications.

The 2600 is additionally challenging because it would build the video signal on the fly as the raster scanned down the TV screen. There was no video buffer, so the content of the registers never contained the whole picture. You had to look at what was in the registers whenever it changed and know exactly where the raster was supposed to be in order to know how the image was built. Essentially, there were several pages of emulation code that had to be processed at run time to deal with each pixel on the screen. It was such a drain on the CPU that, for a time, it looked like the PS2 wasn't going to be able to pull off the double-speed effect we wanted as a game variation.

That's the big irony about the 2600. What appears to be the simplest machine to emulate is actually one of the hardest and most CPU intensive. It only had 128 bytes of RAM and most games were 2048 bytes of ROM but every cycle counted.

Recreating the Experience

There are some specific things we did for Atari Anthology to make the games true to the originals. For example, the Atari 2600 console had 128 different unique colors. The circuits for generating those colors are hidden inside a custom chip. Rather than guess, I created a special ROM and downloaded it into my Atari 2600. It was programmed to cycle through all the possible colors. A bar code on the top of the screen identified which color was being selected. The result was captured with a PC video card and the program scanned the captured video, deciphering the bar code and noting the dominant color that was on the screen with it.

Another interesting problem was the vector games in Atari Anthology, such as Asteroids. These games did not draw their pictures the way a TV does, but worked more like an oscilloscope. The result was a picture composed of brilliant wire-frame ships, asteroids and saucers. Though a TV doesn't afford the brilliant luminous contrast or smooth lines of a true vector screen, we simulated the fringe effects of the vectors and anti-aliased the lines to bring the experience as close as possible on a normal TV. In fact, Atari's vector games use resolutions higher than a regular (NTSC) television - 1024x1024 to be precise. On platforms that support it, we made use of the progressive scan modes to get an even better picture. Atari Anthology looks better on HDTV.

For the arcade games in Atari Anthology, we went beyond simply duplicating the image on the CRT and added some of the additional cabinet art you would see at the edges of the screen when playing. On many games this even includes the flashing buttons.

The European (PAL) versions are an additional challenge. All of the originals run at 60 frames per second, but TVs in Europe run at 50 frames a second. Six does not divide evenly into five so we have to come up with schemes to get the speed of the game correct.


Control is part of the experience, every bit as important as the game's visuals, timings, difficulty, levels, etc. Analog spinners, steering wheels, levers, etc. have all been specifically designed to make the control of the user's ability to control the game intuitive and precise. These are absolutely essential qualities in intense action games balanced to defeat the average player in 2-3 minutes.

Part of the point of a package like Atari Anthology is to bring back the fond memories of playing the game in the arcade (or at home). The emulator's video and sound are pretty significant cues to dredge up those memories, but the controls really make a difference. We can't duplicate the shape of the original controller, but if we get the response to the controls right, the player's muscle memory will kick it. It is one thing for the game to look like Asteroids - it is a whole other sensation for it to feel like Asteroids.

Just like there's no direct equivalent in the instruction set of one CPU to another, there's often no direct replacement for an original game's control and the new platform. Even in a joystick or button game, the travel of the control, position of the buttons, etc. can be an encumbrance. The more frustrating ones for us in trying to create genuine recreations, however, are often the paddle controls and the free-travelling spinners.

The trackball is one of the most innovative controls created. It's a spinner that can be spun on two axes - up/down and left/right, similar to a mouse. A mouse is an integral part of your PC. If you were told you weren't allowed to have a mouse anymore, and instead had to control your cursor with a joystick (or drive your car with a joystick, for that matter), you'd not be happy. It's a barrier for us, strictly as creators of software, that can be most frustrating. It would be absurd to suggest that the user is not an integral part of the equation. The most precise recreation of a game's logic and behavior is hobbled if the user can't get his/her intent across to the game as well as before. The game has been precisely balanced to respond to a decent player using a decently intuitive and precise control.

The best we've been able to offer in response to this, when a precise controller is not available, is to support as many controllers as we can. Beyond that, we provide as many options as possible (unfortunately, sometimes bordering on an overwhelming number of options) in order to tune other controllers to balance between precision and responsiveness. Something as simple as Super Breakout creates a problem of balance. You need to be able to move fast, but you need to be precise. Most thumb sticks don't give you enough travel to have a sufficiently wide range of speed with fine precision between those steps.

So, we often have options like "absolute" vs. "relative" mode, where you either get to choose whether your thumb stick will determine the speed of your onscreen paddle (more precise on position, but hard to reverse direction quickly or the like), or the position of your onscreen paddle (but, often, with 200+ positions on the screen, you are going to have trouble picking the exact position of your paddle with a thumb stick). The great thing about a paddle controller - and a trackball, too - is you could give it a good spin for sudden emergency moves, but still stop it dead in its tracks with a touch, and then fine-tune the position. We've come up with all sorts of schemes for attempting a balance between these two qualities on a thumb stick (or steering wheel, or whatever is available), but unless we can get a precise match for the original game's controller, it's always going to be an incomplete solution.

In some cases, modern controls are more complicated than originals (like the pressure sensitive buttons on the PS2 or Xbox). In other cases, we need to find a happy medium between what players expect from the original game and what they expect on the console. For example, we may be influenced by where the gas pedal should typically be located on the modern controller. After we find what we think is the best arrangement for the user, we add in UI elements so they can re-arrange the controls to suit their needs.

One particular problem, in that regard, is the common modern standard that the Start button also be a pause button. Sounds simple, right? Problem is, the Start button should also start the game. So what the Start button should do changes depending on whether a game has already started or not. How does the emulator know if a game has started or not? It doesn't. It just has a huge collection of information about the state of the original hardware and what's in its memory. It's up to us to divine some way of determining what state of the original CPU indicated a game in-progress. That had to be done "by hand" for each of the 85+ games in Atari Anthology. For example, sometimes lights might flash on the control panel of an arcade game when it's waiting for a new player. So, we'd change the behaviour of the console's Start button based on whether or not the emulator saw a recent request to flash the arcade cabinet's lights. Other times, it wasn't so easy. For another example, what if Player 1 presses Start while it's Player 2's turn? It probably shouldn't do anything, but how do you know it's Player 2's turn? Most times, that's just an obscure byte at some obscure location with in the game's RAM. Did I mention we didn't have any source code?

Adding Extras

There's more than just game play, graphics, or sound to these games; there's culture.

Interviews with the people who created the games can put the games in a new light. Perhaps you'll learn about Easter eggs you weren't aware of in the game. These interviews may not be to everyone's taste, but it is similar to how some people are curious about what a band has to say about the songs they wrote or performed. For example, by listening to Nolan Bushnell, you'll find out about Atari's game behind the game: Atari contracted chip houses to develop a lot of different graphics chips as busywork to prevent competitors from developing their own consoles.

There is also an element of nostalgia to packages like the Atari Anthology. The emulators have the game covered, but with the extras we can attempt to recreate the experience of the entire product. It might sound silly, but if you buy a classic car, it adds something if you have the original manual. And we've found that people seem to appreciate it, for the most part, and it has become an expected thing.

Sometimes the publisher doesn't specifically ask for the content, but we add it anyway because we believe in creating a well-rounded package. Sometimes, they do ask for it, but it's usually left to us to consider the details. Typically, the selection and coordination of materials is entirely between us and the collectors who help us out. This even includes who we choose to interview, most of the time.

An innovation in Atari Anthology was the addition of the Challenge Modes. The Challenge Modes add a new dimension to game play by tinkering with the original game experience. Unlike remakes or the like, the game premise isn't changed. Rather, how you interact with the game changes.

The idea for the Challenge Modes came from a couple sources. When we released Atari Arcade Hits for the PC back in 1999, there was an interest in updating the graphics a bit. This included adding some more detail to the sprites in Centipede, more color to Battlezone, etc. As an experiment, one of the optional modes in Asteroids was "Trippy Mode." Unlike the other visual enhancements, Trippy Mode affected game play. It left a psychedelic, blurring decaying trail as everything moved. It made for an interesting game and created a unique challenge. It was quite entertaining to us, but didn't fit in with the "authentic play, new look" presentation Hasbro and we were going for in Atari Arcade Hits. It was left in, but buried in obscurity in one of the game options menus.

A second unlikely source of inspiration for the Challenge Modes was a pointless thing I'd do for fun every time I upgraded my computer. I wanted to get a real sense for just how much faster my new computer was, so I'd take one of my emulators and remove the code that made one second of simulated CPU time take one second of real time. Without that code, the emulator still did everything properly, but time sped up. It got to the point on my 3.6GHz system, the time from the start of a game of Robotron and Game Over three lives later was about 1/3 of a second. However, way back on a 166MHz, the games might be insanely fast but still almost playable. This was the inspiration for the Double Speed Challenge Mode in Atari Anthology.

Rounding out the five Challenge Modes were three other challenges: Time Warp mode was a variation on Double Speed where the game speeds up and slows down periodically. In Time Challenge, you had to score as many points as you can in a fixed amount of time. In Hot Seat mode, you would play several games at the same time, switching games - no matter what is going on - every 10 seconds.

In Atari Anthology, there was an interest in creating unlockables to enhance the replay value of the package and encourage people to explore the collection fully, rather than sticking with the games they knew. However, we didn't want to lock out any games that might turn out to be someone's favorite. The Challenge Modes seemed a good solution. They added replay value, but all the original games were still there and accessible from the start.

Legal Issues

How do these packages come about? Being a developer, we don't obtain the rights to these games on our own. We talk to the publishers who already own the rights. The publishers we are most likely to end up working with are the ones with the more concentrated catalog of games and who were a dominant presence in some form, both then and now. This minimizes the legal issues, though they still exist.

For example, when spanning 20 years of the industry or more, records may have changed corporate hands several times through buy-outs and the like. There may have also been special contracts for contributors to a game's development. Back then the industry was far from standardized. It can be a very time consuming process for the publisher to verify they even have clear ownership of a game, and that the rights weren't shared, or lapsed or the like.

Centipede on Atari Anthology

Multiple owners can make it nearly impossible to get some classics republished. My favorite Atari arcade game of all time is indisputably Star Wars, but that would require the consent of not only Atari, but also LucasFilm. This also happens with games that might have been licensed by Atari for North America but are owned by, say, a Japanese company. Namco in fact, owned a number of arcade games with the Atari logo on them.

Though this problem didn't occur with Atari Anthology, there have been cases where corporate logos have changed hands. For legal purposes, we have to modify the original games and erase the old logos! The emulator is perfect, but not legally perfect. Similar to the start button, we figure out very carefully how to remove the offending logos without altering the original ROMs and that can be tricky.

The time it takes to research ownership alone can be prohibitive to getting new games in a compilation. This is part of the reason the first round of games on a new console might be a collection of those released on the previous console (e.g. the PS2 Midway Arcade Treasures more-or-less pooled all the PSone titles). In the time it takes to research new titles legally and technically, there isn't time to get those games in the package between the day it's green lit and the day it's to ship. Successful sales, of course, breed follow-ups, and give publishers the time and motivation to expand the catalogue of "legally clear" titles. Meanwhile, we continue to add more games to our library, bringing them to a technical level with the accuracy that consumers have come to expect.

Striving for Perfection

Emulation brings a long way toward recreating the original game experience. As each successive generation of console comes out, we feel we're edging these games a little closer to getting the experience just right. For example, sounds can be emulated more precisely, more games are added to the compilation, new material can be added, better resolution can be achieved, etc. It's a never-ending challenge, but one we're very fond of, because we simply love these games. Doing these compilations is just our humble way of preserving the legacy, and trying to pay these games back for all the enjoyment they've brought us. And, given the continued enthusiasm each release has been met with, and the ever-expanding catalog of "classic" games as the industry marches forward, it's something we're excited to keep doing for a long time to come.


Article Start Previous Page 2 of 2

Related Jobs

Petroglyph Games
Petroglyph Games — Las Vegas, Nevada, United States

Senior Game Engineer (C++)
Sanzaru Games Inc.
Sanzaru Games Inc. — Foster City , California, United States

Junior Gameplay Engineer
Brace Yourself Games
Brace Yourself Games — Vancouver, British Columbia, Canada

Disbelief — Cambridge, Massachusetts, United States

Senior Programmer, Cambridge, MA

Loading Comments

loader image