|
Features

Back To The Classics:
Perfecting The Emulation For Digital Eclipse's Atari Anthology
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.
Controls
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.
______________________________________________________
|