2000 Part III: The Emulators Everywhere Else

An old arcade game could run on a PC and still sound wrong. Getting it to start was only part of the job. In 2000, programmers kept working through faulty sound channels, cartridge mappers, corrupted saves, and arcade boards that resisted emulation. The downloads let players revisit arcades, handhelds, 8-bit machines, and the Super Nintendo. Behind each release were smaller repairs that could make a familiar game feel familiar again.

MAME’s year of patient accumulation

MAME entered 2000 as one of the scene’s most visible preservation projects, documenting arcade hardware by making it work in software. The project’s official release record lists version 0.36 on March 21, followed by a long run of 0.37 betas from April into December. “Beta” might suggest something waiting to be finished. Here it also meant that new drivers—the code for individual arcade systems—along with fixes and hardware discoveries reached the public as they became ready.

By version 0.36, MAME covered hundreds of arcade systems and well over a thousand game sets, according to the full MAME history. The count kept climbing through the 0.37 betas, though a game set could be a regional release or another variation of an existing title. Nor did an entry in the list promise a flawless evening’s play. Some drivers worked beautifully; others still lacked sound or the behavior needed to handle a board’s protection. Even a well-supported game was not guaranteed to run perfectly on an ordinary home PC.

Keeping that many boards under one roof required work players would rarely see. Nicola Salmoria had founded MAME, and contributors including Aaron Giles were taking increasingly important roles. The 0.37b9 project notes credit contributors and describe Giles’s major rewrite of the memory interface. Different arcade boards addressed their hardware in different ways, and MAME needed a foundation that could accommodate them. A new memory interface was unlikely to make anyone reach for a joystick, but it helped other developers add systems more reliably.

That work gave MAME’s year a different rhythm from the PlayStation race. A new commercial game running in ePSXe could dominate a forum for a week. MAME might add a cabinet few people remembered outside one city, or correct a sound chip that had been wrong for years. For someone who grew up hearing a particular attract-mode melody in a local arcade, getting that tune right could be more exciting than finding fifty familiar names added to a menu.

The releases kept arriving: MAME’s dated index records 0.37b1 in April, b5 in July, b7 in September, b9 in November, and b10 in December. Alongside the downloads, the publicly maintained source code let researchers compare behavior, test for regressions—things that had worked before a change—and see who had contributed. Players could follow the growing game list; developers could follow the investigation underneath it.

Making unfinished work public had its awkward side. A newly added driver could put a game within reach while still carrying an “imperfect” warning for wrong colors, faulty sound, or incomplete protection behavior. Years of research might have brought it that far, only for the next visitor to ask why it was not “fixed yet.” MAME’s documentation kept those shortcomings visible. Describing what still failed was part of recording the hardware, even when the download made people impatient to play.

A single release could bring together work done by people who had never handled the same machine. One researcher could identify a chip, another supply a dump of the board’s data, another write the driver, and a fourth find a regression in a game the others had never seen. Their contributions arrived together in one executable, giving a unified face to a distributed effort. The arcade boards behind it were often scarce and physically aging; understanding one could depend on several people pooling what they had.

MESS asks a broader question

MESS shared some of MAME’s infrastructure, but its machines asked more of the player than an arcade cabinet usually did. Consoles and computers used keyboards, cartridges, tapes, and disks in different combinations. The official version list shows MESS moving through corresponding 0.36 and 0.37 betas in 2000, though “MAME for consoles” would miss much of its work. To run a computer game, an emulator might need to reproduce the keyboard matrix that registered keypresses, the disk drive, the boot sequence, and the sound chip, then load software in a format that could vary between models. Reaching a BASIC prompt was progress. It did not necessarily mean the game you remembered would load. By the end of 2000, emulation involved much more than swapping cartridges on a PC.

While MESS tackled more kinds of machines, ports and frontends brought MAME-style emulation to more operating systems and devices. Contemporary Zophar notices described MacMAME keeping pace with the official release, and even MAME variants for digital cameras. A tiny camera was hardly an ideal arcade setup. It was, however, an unlikely place to prove that the code could travel—and to find out what another machine could do.

Finding one game in an enormous arcade list could be a job in itself. A command line gave experienced users control, but a searchable menu, screenshot browser, or per-game settings panel made the collection easier to explore. October news described screenshot viewing and a cleaner interface in MAMERun for OS/2, with an explicit recommendation to use MAME 0.37 or later. The emulator, its operating-system port, and a separately maintained frontend all had to line up before the player could settle down and choose a game.

CPS2Shock and the puzzle of protected Capcom boards

Capcom’s CPS-2 arcade boards presented a harder obstacle: their program data was protected by encryption. Understanding the graphics hardware would only get an emulator so far if it could not interpret the program telling that hardware what to do. CPS2Shock brought together people working on that barrier. The group also produced a Callus95 patch that extended the Windows version of Callus to additional games, according to the preserved directory. Behind the prospect of another playable title lay work on keys, program behavior, and the details of the boards themselves.

During 2000, the group worked with patches, tables, and game support while the CPS-2 protection problem remained stubborn. The celebrated full breakthroughs came in 2001. Fans wanted dates for the next decrypted game; researchers needed verified keys and tests. Protected games felt tantalizingly close to the Capcom favorites people already knew, and that anticipation could put pressure on the people doing the work. There was progress, but the protected library had not yet been opened.

Some of the work was less glamorous and immediately useful. The June 2000 archive reported a Callus95 patch update that fixed a Windows 2000 problem, along with matching data files for CLRmame and ROMCenter. Those tools helped users check which ROM files belonged together and whether a dump was complete—information an emulator needed to identify a game set reliably. Getting an older arcade emulator working on a new PC operating system also kept games within reach, even if it made a less exciting headline than cracking a protected board.

Neo Geo and the arcade projects beside MAME

For Windows players interested in Neo Geo games, NeoRageX offered an inviting way into the MVS and AES library. MAME covered the hardware as part of its wider effort to document arcade machines, while Raine pursued its own selection of boards and optimized them for ordinary PCs. Their game lists overlapped, but choosing a program still involved trade-offs. One emulator might run a title quickly and mishandle another board’s sound; another might have a more accurate driver that needed a faster machine.

There were good reasons to keep writing specialist emulators alongside MAME. A developer could concentrate on understanding one board, getting games running on modest hardware, simplifying the interface, or supporting a narrow hardware family. MAME’s open documentation was a strength, but it left room for projects with different priorities. In 2000, several programs could tackle the same game and test the same assumptions from different angles.

Sound could make the choice for a player. A game might look perfect while its music stayed silent, its samples distorted, or an effect arrived at the wrong moment. In a Neo Geo game, missing audio could feel like half the cabinet had vanished. Later screenshots of NeoRageX or Raine show the picture, but they cannot tell us how a 2000 build sounded or played; release notes and player reports supply that part of the experience.

The boards themselves could fail while programmers were still trying to understand them. Keys could be lost, and cabinets could disappear from public locations long before their programs became easy to study. For the people doing this work, an emulator could keep knowledge of a machine from vanishing with its last functioning board, as well as let someone play at home. That concern helped sustain months of work on details most players would never notice, though it did not remove the copyright questions surrounding game data.

Final Burn arrives with the smell of Sega exhaust

In September, Afterburner Emu took a new name: Final Burn. A Zophar release notice listed After Burner, Out Run, Super Hang-On, and Thunder Blade among its supported Sega titles—a lineup of aircraft, cars, and motorcycles with little interest in standing still. The author, identified in the contemporary archive as Dave, released updates quickly enough that another September notice joked about whether he slept. The archive does not establish that he was the site’s own Dave (Conjuror); a shared first name is not much of an identification system.

MAME might cover the same hardware family, but a focused project could shape its presentation around a smaller set of favorites. A frontend appeared almost immediately: someone else was already building a more convenient way to launch the games.

Behind that spectacle came the fiddly work: changing how scanlines were drawn, fixing color modes, and weighing the CPU cost of audio filters. Despite its name, Final Burn was changing quickly. The later FinalBurn family would reach far beyond that September list, but in 2000 its focus was still the arcade racers and flying games in the original notices.

The September version numbers give a sense of the pace. One notice covered the renamed 0.007 build; another described 0.011, which fixed a crash when DirectSound failed and color problems in 16-bit display mode. The frontend author already had updates to chase. Changes to the display code could improve the picture on one video card while exposing bands of color on another. The archive records both the excitement and the bugs, with little time between them.

Genesis emulation keeps sharpening

On the Genesis, Gens and DGen kept improving through 2000. January news for DGen covered battery-backed save memory, interrupt behavior affecting several games, new input code, and GYM audio logging. Interrupts are signals that tell the emulated processor to attend to something; getting one wrong could leave a Sonic level or a fighting game misbehaving. Correcting it might change nothing in a screenshot while making a considerable difference with a controller in hand.

DGen’s author, named simply as Dave in the archive, also had to repair a release that broke a familiar game. New features could upset titles that had worked before, and work on an unusual game could accidentally damage a common one. Public release notes let authors admit the regression and users help check whether the repair held.

Gens, developed by Stéphane Dallongeville, followed its own path through the same crowded field. Its late-2000 builds continued to draw attention, with contemporary December notices reporting updates. Getting a title screen to appear was no longer enough. Sound fidelity, controller response, timing, saves, and special hardware all shaped how well a game played. An emulator someone preferred overall might still lose out to a rival when it came to their favorite cartridge.

A working Genesis library did not necessarily cover everything attached to the console. The Sega CD and 32X, covered in Part II through AGES and other projects, added processors, storage, and video paths of their own. Someone with a shelf of ordinary cartridges and one cherished CD game might need different software for each. Emulator directories helped players find their way through those divisions.

Master System, Game Gear, and the people who kept them visible

Sega’s older 8-bit machines had dedicated authors too. MEKA was already a recognizable name, while SMS Plus continued work on Master System and Game Gear behavior. Their libraries were smaller and older than the PlayStation’s, but accurate video and sound still took work, as did mappers—the cartridge hardware controlling which parts of a game the machine could access. A Game Gear title could make display demands that a Master System game never did, and a regional variant could expose a timing difference.

Ports brought this work to Windows, Mac, and other environments, opening the same libraries to people with different computers. Marat Fayzullin also continued developing the commercial MasterGear; a September 2000 notice reported version 1.4. The site editor was irritated by its registration price. Some fans expected emulators to be free, while some authors charged for mature software. That argument was older than 2000, but a growing scene gave it a larger audience.

SMS Power! gave the Sega 8-bit community a place for documentation, preservation, and discussion, with its website story covered more fully in Part IV. Emulator authors needed technical documents, reports of game behavior, and people willing to test obscure titles. A specialist site could gather that knowledge before a general news portal even knew a game had a problem.

The machines shared enough hardware for a fix to travel, but each brought its own complications. The SG-1000 had related yet distinct video behavior, while the Game Gear had its portable display and palette; regional and cartridge differences added more surprises. Fixing a PSG sound chip’s noise channel or correcting sprite timing in one system could help another that shared the hardware. DarcNES put several of those relatives on the same workbench: its January change log covered SG-1000 and Master System drivers alongside ColecoVision and NES work.

Sometimes the problem was the game file. It might have the wrong label, contain a bad dump, or require a cartridge board type the emulator could not identify on its own. Specialist sites collected checksums, cartridge details, and release information so testers could establish what they were running. Otherwise, a corrupt file could make an emulator look broken, while a hacked version could make it look more capable than it was.

NES projects refuse to become footnotes

The NES might have seemed old enough for its emulation to be settled by 2000. FCE Ultra, RockNES, DarcNES, Pasofami, and others still had plenty to work on: speed, sound, debugging, support for different computers, and cartridge mappers. Even the names could undersell the job. The January DarcNES archive covered a ColecoVision keypad interface, early Apple II support, repairs to a Genesis CPU core, and adjustments to several other system drivers. DarcNES was not just a NES emulator despite its name.

RockNES kept finding details to fix, right down to the keyboard. A November 2000 Zophar notice reported version 1.600, followed by a quick re-release because a function key had been mapped incorrectly. Other notices covered sprite DMA timing—the transfer of sprite data—along with graphics memory layout, Famicom Disk System behavior, and mapper support. A favorite game could expose any of these faults without offering the player much help in diagnosing them. Release notes gave testers something specific to try again.

Even saving a game had complications. A save state had to capture enough of the emulated machine to let play resume predictably. A new mapper, revised sound unit, or more accurate timing model could change how an old state behaved. Some projects also read another emulator’s save format, letting players take their progress with them. After hours spent getting through a game, switching programs was much more inviting if it did not mean starting over.

FCE Ultra’s January 0.19 notes show how much could sit behind a seemingly small update: corrected sprite-hit timing, a batch of mapper changes, improved raw PCM sound, PAL timing, and a joystick strobe fix. Those changes gave games with unusual cartridge hardware, European display timing, or sensitive controller routines a better chance of behaving properly. A later September release notice added extra Namco sound channels and NSF music playback. Emulating the console was only part of the work; some NES cartridges brought hardware of their own.

RockNES X, the Windows-side companion to RockNES, made a late-year advance too. A December 7 notice reported major speed gains, better battery saves, screenshots, mapper fixes, and a new save-state format. The catch was explicit: older states would not work with it. Players with an unfinished game had a practical reason to pause before upgrading, however tempting the improvements looked.

SNES emulation turns toward playing together

For ZSNES and Snes9x, already familiar names by 2000, another challenge was getting people playing together. A September Zophar archive recorded ZSNES 1.000 for Windows alongside a statement from zsKnight: he intended to leave emulation coding after helping with Windows netplay. As the emulator reached a new platform and worked toward network play, one of its best-known contributors was preparing to move on.

The November release notes described TCP/IP support and save states during network play, with limits on connection count and hardware speed. Two people could share a Super Nintendo game without sharing a television, provided their PCs and connection could keep up. SNES games expected two controllers attached to one console, with one machine keeping everything in step. Across a network, each computer had its own clock and input delay, and packets could go missing. The emulator had to stop the two copies of the game from drifting apart. The notes’ suggested ping and CPU requirements put practical limits on the invitation to play together.

Snes9x kept improving alongside it. A January Windows 1.28 notice listed bug fixes, cheat dialogs, and more working games; later releases brought translations and platform variants. Players had reasons to try both projects, depending on which games worked, which interface they preferred, which operating system they used, and whether they wanted features such as recording or netplay. Even with two established emulators to choose from, an update could still determine whether a favorite game ran properly.

SNEeSe was working on the picture itself. A September 2000 Zophar note described version 0.48’s assembly work on sprite and background rendering. ZSNES and Snes9x were better known, but SNEeSe offered another route toward speed and compatibility. Where some authors favored code that could travel between platforms, others used assembly to squeeze more out of a particular PC. Different approaches could uncover different game bugs, giving players another emulator to try when their first choice stumbled.

zsKnight’s planned departure left ZSNES relying on other contributors to carry the work forward. A programmer could be proud of a project and still be ready to make games instead of emulating them. In a scene where a paused update could be treated as a betrayal, a change of job or interest could become harder to explain than a stubborn bug.

Game Boy Color makes the handheld question harder

On the handheld side, a New Year’s Visual Boy 1.3 notice announced sound, zipped game loading, and compatibility fixes. A nearby update for BeGameboy on BeOS listed support for Game Boy, Super Game Boy, and Color Game Boy, while acknowledging bugs. As the Game Boy Color library grew, these projects had more to reproduce than the original handheld’s display and sound.

Adding color took more than replacing a grayscale palette. Some games used Color-only hardware features; older games could gain enhancements on the newer device. For someone settling into a long handheld adventure, accurate speed and battery-backed saves mattered as much as the picture. Loading classic Tetris was a useful beginning, but by 2000 it did not establish that an emulator could handle the whole handheld family.

Which computer you owned also shaped your choices. BeOS users could try BeGameboy, Windows users might choose Visual Boy, and DOS and Unix users had other options. Features rarely reached every port together. Getting the display right on one operating system still left input or sound work when the emulator moved to another. Players using only one PC might never notice that effort; players on another system could be waiting for it.

Atari, PC Engine, and other machines outside the headline race

Away from Nintendo and Sega, Stella-X continued fixing practical Atari 2600 problems on Windows, including joystick handling and display behavior. For PC Engine and TurboGrafx players, Hu-Go!, Magic Engine, and YAME faced multiple display modes, different sound hardware, and CD-based games. Much of that library was less familiar to North American PC users, so getting an obscure title working could pass unnoticed by a general audience even when it filled a real gap.

Old computer disks had their own reasons to come out of storage. Gemulator 2000, from Darek Mihocka, became freeware after earlier commercial versions, adding DirectX 7 support and other Windows improvements. Atari ST emulation drew less mainstream attention than an N64 breakthrough. For someone with old projects or demos, though, it could offer something more personal to return to—and the move from paid to free distribution let more people try.

Even the Atari 2600 still had awkward behavior to untangle. A September z26 update documented Starpath loading, PAL detection, tracing changes, and Windows fixes. The machine’s age did not make it simple: games used unconventional cartridges and display timings. An emulator might run a familiar title yet miss a cassette-style loading scheme or misread the number of scan lines. These fixes reached parts of the library that ordinary cartridge support alone could leave behind.

Atari ST users gained another option when Steem Engine 1.0 arrived in September after a long development period. The notice said it required the ST’s TOS operating system and warned about particular TOS versions. Downloading the emulator was only the first step: an unsuitable operating-system image or old disk could still keep a user from getting started. Bringing back creative work meant getting the emulator, system software, disk format, and host computer to cooperate.

That same month, WinSTon author Paul Bates announced a much unhappier departure. In a September 2000 news entry, he said his computer had been hacked and WinSTon’s source taken. He released version 0.5 and its source himself, then ended his own development. His angry first-person account also raised the effect of game copying on people who made games for a living. A new Atari ST emulator had arrived, while another developer was leaving under circumstances he found intolerable.

On a PC, even the color of a handheld game was up for debate. The September VisualBoy 1.4.5 notice listed sound changes, color-mode choices, saved cheats, and several interface languages. Some users wanted the washed-out look of a real handheld LCD; others preferred a more saturated picture. Reproducing the hardware still left room to disagree about how it should look. The same archive reported DBOY for DOS and work on the Neo Geo Pocket emulator NeoPocott, including a RISC OS port. Which computer you owned helped determine which handheld emulator you could use.

That September also brought a September RockNES notice listing fixes for Famicom Disk System behavior, interrupt timing, and several unusual cartridge boards. If a game froze before the first level, a fix for one obscure board could be the best item in the release notes.

Release news crossed language barriers as well as hardware ones. A contemporary notice described a French translation of Snes9x, while VisualBoy offered several interface languages. Japanese Saturn and PC Engine projects reached English-speaking readers through imperfect translations of their readme files. The phrasing could be awkward, but it carried technical discoveries to people who otherwise might never have heard about them. Translated interfaces and release notes helped the scene travel beyond any one English-language news desk.

A 2000 game in the GameBase

Meanwhile, the handhelds themselves were still getting new games. The Retro Replay GameBase entry for Bionic Commando: Elite Forces lists it as a 2000 Game Boy Color release, placing it alongside the emulator authors’ ongoing work on Color behavior. Emulating the hardware meant keeping up with a library that was still growing.

People in this chapter

• Nicola Salmoria — MAME founder.
• Aaron Giles — contributor to MAME’s 2000 memory-interface work.
• Stéphane Dallongeville — Gens developer.
• Marat Fayzullin — MasterGear author.
• zsKnight — ZSNES co-author whose 2000 departure statement belongs in the record.
• _Demo_ — ZSNES and ePSXe contributor associated with the Windows netplay transition.
• Dave, author of the early Final Burn releases — identity needs separate verification before a full biography.

Sources and further reading

• MAME official previous releases and full history.
• MAME 0.37b9 contributor and change notes.
• MESS official prior versions.
• Zophar January 2000 archive.
• Zophar September 2000 archive.
• Zophar November 2000 archive.
• Callus/CallusFR historical directory.