Retro Replay Retro Gaming History, Reviews & Emulation
At the start of 2001, a Windows player looking for MAME could find a program called MAMEW. The familiar MAME name still belonged to its DOS counterpart. Even as emulators brought more old games back to life, using them meant navigating different builds, front ends, and settings. Players wanted something comfortable enough to use every day. That year, Windows gained ground, stubborn arcade hardware began to yield, Nintendo 64 developers worked on better graphics, and the brand-new Game Boy Advance gave emulator authors another machine to understand.
Progress could also take an emulator somewhere its players had not expected. A PlayStation emulator whose maker had won a significant legal fight was sold to the company that had sued it. Another commercial PlayStation emulator closed down by the end of the year. Meanwhile, Dreamcast owners were using Sega’s console to play games from older consoles, putting up with missing sound or awkward disc preparation for the pleasure of getting them running at all. An Xbox website appeared before ordinary buyers could even take the new console home. Some people were improving familiar tools; others were barely waiting for the hardware.
This first part follows desktop emulators and the brand-new Game Boy Advance; Part II turns to the Dreamcast, the Xbox’s pre-launch web scene, and the legal battles. Developers carried code, plug-ins, bugs, friendships, and grudges from one machine and website to the next, so the scene rarely stayed as neatly divided as the names on the download pages suggested.
MAME’s quiet but consequential change of address
By the late 1990s, MAME had grown into an arcade preservation effort with a development community and a culture of testing. Getting a game to appear on screen was only part of the job: developers wanted to understand a board’s strange behavior rather than hide it. Windows users could already run versions and front ends, but the project’s names and development structure still reflected its DOS beginnings.
On May 24, 2001, release 0.37b15 brought that structure into line with its growing Windows audience. MAMEDEV’s own release history records Windows becoming the primary development target. MAMEW became MAME, and the DOS build became DMAME. The release also reorganized parent and clone sets—the groupings used for games and their variants. Players maintaining a collection might have to check their sets again; developers now had Windows as their main target.
The version numbers changed that summer, too. MAME 0.53, released August 12, followed 0.37b16 and dropped the long-running 0.37b beta labels. On a download page, it looked like a much bigger leap than it was. Compatibility had not suddenly jumped with the number. The team was still doing the patient work of documenting, testing, and improving an unruly collection of arcade machines.
August also brought the first AdvanceMAME check-ins and the first Windows release of MESS, according to the official chronology. These were distinct projects responding to some of the same pressures: computers were changing, users expected native Windows tools, and authors had to choose which platforms and workflows to keep supporting. For arcade players, those choices reached into audio, controls, and even how bugs were reported. A DOS loyalist and a new Windows user could both say they were running “MAME” while dealing with different builds and front ends.
MAME reached 0.56 in November. The official release table traces the steady pace: January’s 0.37b11, successive spring betas, the Windows transition in May, the final 0.37b16 in July, then the August numbering change and three more numbered releases before year’s end. Between those downloads, developers kept returning to machines that still refused to behave.
The CPS-2 wall begins to give way
Capcom’s CPS-2 arcade boards presented a particularly stubborn problem. They powered fighting games people could still find in arcades, but their program code was encrypted. An emulator could reproduce the graphics and sound and still fail to run the game if it could not read and execute that code correctly. Getting CPS-2 working promised something close to contemporary arcade play, bringing both the technical challenge and the ethical questions into public view.
In early January, news that the encryption barrier was giving way spread across emulation sites. Work associated with CPS-2 Shock and developments in Final Burn gave players something they could see running. Later accounts sometimes fold months of discovery, key recovery, driver work, and releases into a single “cracked” moment; contemporary coverage shows a longer process. Reading the code opened the way, but developers still had to make games playable, identify bad dumps, handle variants, and get sound and timing right.
CPS-2 emulation put games still sold by an active company within reach of players at home. Developers could see their work as documentation and preservation; players could use it as a shortcut to those games. Both shaped the reaction to the breakthrough. The emulator code and the copyrighted game data it ran were separate things, though download pages and message boards often blurred them together. As those sites drew people beyond the small groups who had built the first emulators, that old disagreement became harder to avoid.
On January 4, the January 2001 Retrogames news archive celebrated Final Burn 0.60 as a working CPS-2 emulator. The staff credited the CPS-2 Shock team and Final Burn’s author, Dave, with help from Gridle. Requests for more games soon followed, along with reminders that development was still under way. By the end of the month, Final Burn 0.08x builds were arriving so quickly that the writers joked Dave never slept. The updates tackled the things players encountered once a game actually ran: EEPROM saving, ROM checking, scanlines, and fixes to graphics and sound.
Dave (Final Burn) The programmer credited as Dave turned Final Burn into one of the fastest-moving CPS-2 stories of 2001.
A Retrogames writer called Opi wondered whether he was getting carried away over CPS-2 Shock and Final Burn, then defended the “sense of wonder” he felt at seeing an apparently impossible board become playable. Other readers were less patient. One post urged them to cool down: the CPS-2 work was not yet a polished release. When the general emulation board became swamped, Atilla created a separate CPS-2 message board. Getting games to run had solved one problem and delivered a fresh queue of requests.
Behind the excitement was a decision about how much to release. In January, Retrogames pointed readers to Razoola of CPS-2 Shock explaining why the group had published decryption tables rather than the full method behind them. That choice shaped what emulator authors could do with the work. It was also the group’s way of drawing a line around games still earning money. How that boundary would hold was still an open question.
Razoola Razoola helped make Capcom’s encrypted CPS-2 arcade boards understandable, then helped the 2001 scene decide how much of that work to release.
Final Burn soon had company. On June 5, Retrogames announced Kawaks 1.00, a fast new CPS-1 and CPS-2 emulator. Razoola introduced it, but the announcement said its author wished to remain anonymous. The original June news page records version 1.01 soon afterward, followed by 1.03, 1.04, 1.05, and 1.06 by June 23. Even by emulation’s brisk standards, that was a busy few weeks. A later 1.06 note advertised CPS-1 sound emulation with a catch: it needed a powerful CPU. A new feature on the download page did not mean every player’s computer could keep up.
Nebula and Calice added more choices. Late in June, the archive recorded Nebula 1.5 and Calice 0.3.6 alongside repeated CPS-2 Shock releases. These were separate projects, each taking its own approach. A player trying several emulators might be looking for support for a particular arcade board, a sound fix, or an interface they preferred. Sometimes the hope was simpler: perhaps the game that broke in one program would work in another.
Getting those games into players’ hands also took work outside the emulator cores. On June 14, Stijn Hoop released an xcps2mame patch for the new Windows-focused MAME line, incorporating CPS-2 Shock’s releases. Guru reported new arcade boards being dumped after a PCB drive, while M.A.S.H. updated mameinfo.dat. That companion file helped users tell an emulator fault from a known quirk of a particular game. Patches, board dumps, and notes gave authors and players more to test—and fewer mysteries to chase.
Final Burn grows a team
Final Burn itself was growing beyond Dave’s work. FinalBurn Alpha began as an unofficial Final Burn build and gained contributors through 2001. Retrogames’s August archive names LoopMaster, KEV, Mike_Haggar, and TrebleWinner as the team behind an update, with credits for other contributors too. Their releases included patches for The King of Dragons, U.N. Squadron, and Strider, along with online-play work using Kaillera. As the game list and options grew, the team divided the work of fixing game drivers, developing netplay, and keeping the program running.
Updates did not always go smoothly. One August release accidentally shipped as a slow debug build and needed a quick correction. Another warned users to delete their old configuration files before updating. FinalBurn Alpha was growing in public, with players encountering mistakes as the developers worked to fix them. Sometimes the next thing to download was a repair for the thing you had just downloaded.
That family of emulators continued to branch. Readers can find a later descendant, FinalBurn Neo in Retro Replay’s emulator directory, though it is a different program from the one Dave released in January 2001.
There was also another player to consider. In 2001, Kaillera let people take local multiplayer games online, provided they could manage the setup and the connection held. FinalBurn Alpha’s August notes gave netplay fixes the same urgency as graphics problems and game drivers. Getting an arcade game running on a PC was one pleasure; having someone to compete with brought back another part of the arcade experience, bragging included.
Project64 and the value of a shared interface
A favorite Nintendo 64 game could run astonishingly well on a PC while the next cartridge refused to cooperate. Players had learned that during the excitement and controversy around UltraHLE: the right game and hardware could produce impressive results, but one success promised little about the next. When Project64 1.0 appeared on May 26, 2001, there was still plenty of room for a more dependable way into the console’s growing library.
Emulation64’s Project64 guide names zilmar, Jabo, Tooie, and Witten as the people behind the project and confirms that first public release date. Nintendo 64 emulation often divided the work among a core emulator and separate video, sound, and controller plug-ins, sometimes written by different people. If a game failed, a player could try swapping one of those components. That flexibility offered another chance to get it working, but also left users choosing among pieces whose differences might only become clear when something broke.
zilmar Known publicly as zilmar, the Project64 co-creator helped make Nintendo 64 plug-ins a common language across emulators.
Jabo Jabo’s graphics and sound work helped give Project64 its practical identity when the Nintendo 64 emulator debuted in 2001.
Zilmar helped those pieces fit together through a plug-in specification used by other emulator projects. Jabo’s graphics and audio work shaped what Project64 players saw and heard. The shared specification gave independent developers a common way to contribute, and a plug-in could reach players beyond a single emulator. It did not guarantee that every component would work interchangeably, or settle arguments about which combination looked “right.” It did allow useful work to outlive the project where it began.
Other developers soon put that shared interface to use. On June 3, Retrogames reported Daedalus 0.07b, an open-source Nintendo 64 emulator that had added support for zilmar’s graphics plug-in specification. Its notes credited Morloc with a texture-correction change and listed fixes for problems that had stopped several games working in the previous build. Players also gained an F12 screenshot key, more display options, a status bar, and configurable folders for games and saves. Alongside new plug-in choices came small conveniences that made the emulator easier to use once a game was running.
The same June news page directed readers to the new Emulation64 address for 1964, another open-source Nintendo 64 emulator. Apollo, Mupen64, and separate audio and graphics plug-ins gave players more approaches to try. Each project struck its own balance among speed, accuracy, and openness. For someone stuck at a favorite game’s first troublesome scene, those differences were practical: another emulator or plug-in might get them further. Communities kept comparing results, a useful habit that could be rather less comfortable for the person fixing the bugs.
On December 25, Project64 1.4 arrived with a Christmas farewell. A contemporary EmuTalk post preserved the announcement from the Project64 site: zilmar and Jabo were stepping away to focus on real life. They called 1.4 the final version, thanked Smiff for his sustained support work, and made some source code available. Players received a better emulator and the news that its developers intended to stop. The forum responses mixed gratitude with sadness that the team seemed to be breaking up, alongside questions about what other programmers could do with the released code.
Project64 later returned, but users reading the Christmas announcement in 2001 had reason to believe it was over. The developers intended to stop; they could change course later. For now, they had reached the ordinary limits of volunteer work. Building and supporting a widely used emulator could swallow years of evenings, while a growing audience brought still more glitches to investigate and questions to answer.
The maintenance did not stop with the farewell. On December 26, Smiff wrote that he had already corrected mistakes in the Project64 ROM database, including fixes for Perfect Dark saves and PAL Zelda behavior. Version 1.4 was supposed to be final, yet somebody was still making it more dependable. Saving a game properly was less spectacular than getting it running for the first time, but rather more useful when you wanted to come back tomorrow.
The older machines kept changing too
Players returning to Super Nintendo games had improvements to try, too. Retrogames reported Snes9x 1.34 in January, with work on ZSNES save-state compatibility and fixes for games as varied as Chrono Trigger and Rendering Ranger R2. Moving a saved position between emulators could spare someone hours of replaying. Trying a different program was a much easier decision when it did not mean starting the adventure again.
By September, Snes9x 1.39 had reached several systems. The project’s own news page announced Windows, Linux, and Solaris builds, followed by a PowerPC Linux release on September 27. That last post gets down to the pleasingly small details: the porter had finally obtained the source and slipped in a fix to improve the music in Gundam Wing: Endless Duel and other games. The team also wanted a volunteer to overhaul the Windows interface. Getting the games to behave was one job; making the menus agreeable was another.
Retro Replay has a Snes9x directory page for readers who want to follow the emulator beyond this particular year.
June brought a quick succession of ZSNES releases: 1.29, 1.30, 1.30b and 1.31. The contemporary June archive credits whatabubba, pagefault, and zsKnight in the 1.29 notes, which covered triple buffering, DirectDraw speed improvements, and fixes for games including Rock N’ Roll Racing and Lennus II. An eight-line rendering defect in Final Fantasy Mystic Quest was corrected, restoring the missing part of the picture. A video-path optimization offered a 10 to 15 percent speed improvement. For someone whose PC was only just keeping up, those percentages could be more welcome than a new feature.
On the NES side, RockNES followed a similar rhythm. Retrogames’s June report of version 1.930 separated the fixes by Fx3 and Richard Bannister, including compressed-file support and a small optimization to the PPU, the hardware responsible for drawing the picture. Another June entry described NNNesterJ 0.19, which drew from Nester, UOnester, and NesterJ. The names looked like a family tree because they were one. With permission and access to code, developers could build on earlier work rather than begin again; a new prefix did not necessarily mean a new emulator built from scratch.
Richard Bannister Richard Bannister kept Macintosh users connected to a changing emulator world, including a 2001 Boycott Advance port.
PlayStation emulator development continued while commercial developers fought their legal battles. Retrogames announced ePSXe 1.4.0 on June 25, alongside a redesigned site and plans for an installer bundling current plug-ins. The same page recorded AdriPSX updates addressing video decoding, CD-ROM behavior, and failures in particular games. A striking picture was welcome, but an RPG also had to survive its movie sequences and disc transitions. Players had practical reasons to try more than one emulator, and the legal troubles of Virtual Game Station and bleem! had not stopped that experimentation on Windows.
By Christmas, ePSXe users were waiting again. In the ePSXe team’s own December 24 update, they explained that the website had been offline for a long stretch and development had slowed during the summer. They had hoped to finish a new version for Christmas. It was not ready. The team wished readers a happy holiday and said the release would come when its features were finished. For anyone regularly refreshing emulator news pages, seeing the site return was at least a start. The next major version would arrive in 2002.
A quiet release page did not mean the work had stopped. On a PlayStation emulator, a change to CD timing or video decoding might fix one famous game and break another. Developers then had to test across computers, discs, graphics plug-ins, and sound hardware. Users saw months between downloads; the team had to get through the fixes in between. Waiting rather than wrapping an unfinished build as a Christmas present could be the better choice.
Elsewhere, the same contemporary archive followed gnuboy across Unix, Linux, DOS, and Windows, and MEKA on Master System and Game Gear. It also carried news of Virtual X68000, Atari and Spectrum emulators, and MESS drivers for machines that rarely reached mainstream gaming magazines. The familiar console names were only part of the activity. People kept working on the machines they cared about, including plenty that never topped anyone else’s wish list.
A new handheld, and the race to understand it
Nintendo’s Game Boy Advance reached buyers in 2001 while emulator authors were already trying to reproduce it on a desktop. A player could still be discovering the handheld’s games as a developer worked out how to run them elsewhere. Early builds supported homebrew tests, graphics modes, or a small group of games. That gave people something to try, but it did not mean commercial games were perfectly emulated from day one.
Gollum developed the core of Boycott Advance, and Richard Bannister brought it to Macintosh users. Bannister’s own project page describes the Mac port and its early use for Game Boy Advance homebrew software. A contemporary June 18 report from Inside Mac Games singled out the Mac release in a batch of emulator updates, with a warning: commercial titles might run without sound or below full speed. By early July, Mac players were being invited more directly to try the new handheld’s games on their computers. Getting a game to run and getting it to feel right were still separate jobs.
Gollum Gollum wrote the core of Boycott Advance while other programmers, including Richard Bannister, brought it to more users.
Bannister’s work in 2001 extended across emulator projects and Macintosh platforms. Porting, maintaining, and presenting those programs gave Mac users access to a wider range of systems, even when Windows-centered download sites treated their computers as an afterthought. Boycott Advance was one part of that work.
The June Retrogames archive records a Boycott Advance 0.1.9 Macintosh release in a post signed richard, along with links to work-in-progress screenshots. Such images could reach a news headline before the software was available to download. Then came a more painful kind of early exposure: a post reported that a private beta had been leaked, even though the emulator was free. The writer reacted angrily. A free program could still have an unfinished build meant only for testers, and a leak took the decision to publish it out of the developer’s hands. The writer hoped the leak would not end the project; the post did not report that it had.
The same June archive was already busy with other Game Boy Advance news: Marat Fayzullin’s vGBA, a DOS front end called QBFE, and screenshot collections cataloging the endings of GBA games. Emulator authors were learning how the machine worked while front-end creators, screenshot archivists, and players built ways to use and document it. Someone visiting for one emulator update could leave with several other things to investigate.
VisualBoyAdvance and the earlier GBAEmu were also in the race. Calling any project “first” depended on whether you meant a private demonstration, a public download, a homebrew test, or a working commercial game. For a player hoping to try a favorite cartridge, a promising screenshot was only a start. The milestone they wanted was a program they could download, configure, and trust with a save.
The modern VisualBoyAdvance-M directory entry follows the project’s later lineage, rather than the capabilities of its 2001 builds.
A new GBA emulator could run a demo and still stumble over a commercial game. For developers, the handheld offered a clear hardware specification to investigate and an audience ready to test their work. Commercial games soon exposed shortcuts, but ordinary play had not yet revealed all the machine’s quirks. A bug could be a clue to how the hardware actually behaved. The first releases had small compatibility lists beside their later successors; they also had much more left to discover.
A handheld target before the paint had dried
The handheld race had begun months earlier. Retrogames was following iGBA in January, before most North American players could buy the handheld. Its developer reported getting demo programs to run at the cost of speed: putting the right picture on screen was only part of the job. By June, VisualBoyAdvance updates reported working DirectSound emulation, remaining glitches, and a possible release soon. The author was also keeping the older VisualBoy Game Boy project alive, though limited time slowed that work. The June Retrogames archive catches several projects in motion, with progress and unfinished work sitting side by side.
In the August archive, Kervin’s DreamGBA moved through versions 1.8, 1.9b, 2.0, 2.1, and 2.2. Its announced fixes dealt with problems that could spoil a session: missing audio on some sound cards, an erased save file, and games that needed different flash, SRAM, or EEPROM save-memory behavior. Getting a game to start was welcome progress. Keeping the player’s save intact made it much easier to come back tomorrow. Chinese-language sites were central to this release trail, too; following GBA emulation meant looking beyond English-language news.
Meanwhile, Otaku no Zoku was approaching the handheld from the other direction. A June Retrogames post showed preliminary screenshots of an Atari 2600 emulator for Game Boy Advance. Instead of running GBA games on a desktop computer, this project proposed running a much older console’s games on Nintendo’s new handheld. The enthusiastic post showed work in progress, not a finished public release. While other developers were still learning to reproduce the GBA, someone was already trying to make it a portable home for older games.
A 2001 game in Retro Replay GameBase
Players had more ways in
By year’s end, players had more ways to get games running—and more choices to make about builds, plug-ins, and settings. The arguments increasingly turned on what happened after the title screen: whether the sound worked, the save survived, or another player could join in.
Part II moves to the Dreamcast, a living-room console that programmers were already treating as an open canvas for older games, then follows commercial emulators through Sony’s legal fights. The websites connecting the scene also lead to a small pre-launch Xbox fan site whose readers were imagining what they might do with Microsoft’s console.
People in this chapter
- Razoola — Razoola helped make Capcom’s encrypted CPS-2 arcade boards understandable, then helped the 2001 scene decide how much of that work to release.
- Dave (Final Burn) — The programmer credited as Dave turned Final Burn into one of the fastest-moving CPS-2 stories of 2001.
- zilmar — Known publicly as zilmar, the Project64 co-creator helped make Nintendo 64 plug-ins a common language across emulators.
- Jabo — Jabo’s graphics and sound work helped give Project64 its practical identity when the Nintendo 64 emulator debuted in 2001.
- Gollum — Gollum wrote the core of Boycott Advance while other programmers, including Richard Bannister, brought it to more users.
- Richard Bannister — Richard Bannister kept Macintosh users connected to a changing emulator world, including a 2001 Boycott Advance port.
Sources and further reading
- MAMEDEV release history
- MAMEDEV old releases
- Retrogames January 2001 archive
- Retrogames June 2001 archive
- Retrogames August 2001 archive
- Project64 1.4 contemporary discussion
- Snes9x project news
- Boycott Advance Mac project page
- ePSXe official news
Part of: The Complete History of Video Game Emulation
Browse biographies: People in the History of Video Game Emulation