Retro Replay Retro Gaming History, Reviews & Emulation
Remembering an arcade cabinet’s name was not always enough to play it again in 1999. A missing file could stop you before the game began; a missing graphics layer could leave it looking wrong once it did. While lawsuits and N64 headlines drew attention to three or four programs, ordinary weeks in the emulation news archives were crowded with work on arcade boards, eight-bit consoles, handhelds, computers, and stubborn sound chips. Much of it was unlikely to make television. It could still bring a favorite game within reach.
MAME starts the year with a wider toolkit
In February, MAME tackled one recurring graphics problem by introducing shared tilemap code in version 0.35 beta 3. Tilemaps build backgrounds and foregrounds from small graphic pieces, and many of the program’s drivers—the code handling individual arcade boards—had previously managed them independently. A shared system let a rendering correction benefit more than one board. For a player, that might mean a missing layer finally appearing. For a contributor, it meant less time solving the same problem again.
Already the broadest public arcade project, MAME had hundreds of drivers to maintain. Giving them common tools made further work easier, even when a release lacked a famous new game to draw attention. The programmers were documenting and reproducing machine behavior as well as making games playable. The official release archive traces a rapid sequence of betas through 1999.
Other changes helped players find their way around that growing library. In May, MAME switched its primary screenshot format from PCX to PNG. Screenshots helped users browse unfamiliar games and gave websites a way to catalog progress. In July, the project’s history records early history.dat support, allowing explanatory text to accompany a game entry instead of staying on a separate website. The emulator was gaining room for the history surrounding the machines it ran.
Getting those machines to start could still require some detective work. As MAME expanded, a game might need a parent ROM set containing shared files, a BIOS, or files with exact checksums. A familiar cabinet name did not tell the player which pieces were missing. Frontends and ROM managers tried to make that preparation less painful, while the scene spent plenty of time explaining why a failure came from a mislabeled archive, an old dump, or a missing dependency rather than an emulator bug.
MESS and the idea of one framework for many systems
MESS, first publicly released in 1998, was bringing the same shared-framework approach to consoles and computers. During 1999 it moved closer to MAME; MAME’s milestones date the synchronization of their version numbers to October 10, 1999. Behind the matching numbers, the projects were aligning their code base and development rhythm so that console and computer drivers could use infrastructure developed for arcade emulation.
That did not make every MESS machine ready for an evening’s play. An old computer might need a keyboard, a tape or disk image, the right memory configuration, and working peripherals. “Load a ROM and press start” only got you so far. Still, the techniques used to document an arcade board offered a way to tackle other electronic machines, and the official MESS version archive shows the project working through that variety in its 1999 releases.
Richard Bannister and Brad Oliver had been associated with the early MESS effort, alongside the wider work of the MAME contributors. MESS would grow beyond those early figures. Modern MAME includes the former MESS systems in one program, but in 1999 players still encountered two separate projects at different levels of maturity. The later merger depended on engineering and coordination that were still being worked out.
The arcade specialists remain stubborn
Meanwhile, Richard Bush’s Raine kept chasing arcade boards that fans wanted to see in motion. One particular Taito or Jaleco game could mean more to a player than a hundred unfamiliar names in another emulator. Getting it right meant untangling graphics layouts, inputs, sound, and the hardware quirks that shaped the game. A pretty title screen was encouraging. It was also a long way from knowing whether you could finish playing.
Larry Bank took another specialist route. After CAGE, he rewrote his arcade approach as HiVE, reported in 1999, tackling Williams and other hardware with attention to how particular games felt. The local history archive places its release in April and records version changes through December. Surviving arcade directories place HiVE among the other narrowly focused projects of the period. Even with MAME covering so much ground, a specialist could still get to a particular game first.
Retrocade, led by Neil Bradley, continued to cater to players who remembered the older cabinets, before the more visually elaborate arcade games of the 1990s. A program built around those favorites could feel welcoming straight away. Bradley’s work also entered conversations about other emulator projects, and later cross-project contributions make a simple rivalry hard to sustain. Programmers could race to deliver a game’s first playable version and still share what they had learned about its hardware.
Getting an arcade game to run was only part of the job. One team might solve a cabinet’s sound while another worked out its timing, and a third made the emulator easier to use. Players had reasons to try all three: a faithful command-line program, a fast emulator built for a particular game, or a polished Windows wrapper. In 1999, those overlapping efforts often turned up in the same weekly news post.
NeoRage becomes NeoRageX
The DOS-era NeoRage had made SNK’s hardware a major story in 1998. In 1999, Anders Nilsson and Janne Korpela brought it to Windows as NeoRageX. Its graphical interface and DirectX support made an exciting but demanding library easier to approach. Players could spend less time configuring the program and get to the games sooner—including, inevitably, the ones it could not handle.
Nilsson and Korpela had already worked together on Rage and NeoRage before making the Windows version. Later download sites often kept only the executable and a change log, leaving little trace of the years of focused work behind that familiar Neo Geo game on the screen. Nor was the Neo Geo a safely retired machine: it still had commercial relevance, which made the project both exciting and contentious.
Windows did not automatically make NeoRageX the better choice for every PC. DOS could offer speed and direct control on the machines of the period; Windows offered easier browsing, more familiar input setup, and a different graphics path. Users argued over speed and compatibility because their computers could give them different answers.
Sega’s eight-bit machines get a champion
Sega’s older consoles were getting attention too. Omar Cornut, known online as Bock, began work on MEKA in 1998, and the project’s own history places its first public phase in 1999. It targeted the Master System and related Sega machines, entering a field that already included Marat Fayzullin’s MasterGear and other programs. MEKA developed a distinctive interface and tools, along with a lively relationship with the people who cared about Sega’s eight-bit hardware.
The old MEKA news pages follow that work through Cornut’s changes, frustrations, and plans as he discussed them at the time. Getting a game to start left plenty to fix: colors, sprite behavior, sound, controllers, and regional quirks all needed to behave properly. The Master System had a smaller audience than the PlayStation, but its bugs were no easier to solve. A player returning to Wonder Boy III could tell immediately when the movement or audio felt off.
MEKA’s 1999 appearance also connected the program to a website that would grow into SMS Power!, a specialist community for Sega eight-bit preservation. Its later breadth was still ahead, but the exchange had begun: users tested games, the emulator gave them a reason to collect accurate information, and the site made that information easier to share.
Genesis: Gens and DGen enter a crowded room
On the Genesis, a newcomer had to compete with programs players already liked. Steve Snake’s KGen98 and Bloodlust’s Genecyst had set expectations when Stéphane Dallongeville‘s Gens entered the field in 1999. Source-code lineage and copyright notices preserve that origin. Gens would later become especially notable for its Sega CD work. For now, players had another contender to try alongside the established favorites.
Stéphane Dallongeville Stéphane Dallongeville created Gens, entering the busy Sega Genesis emulator field in 1999 and building a project that later became especially important for Sega CD play.
DGen, associated with Dave, also appeared publicly in 1999, offering another option for Windows and DOS users. Its source archive tracks rapid releases and different CPU-core choices during the year—the parts of the emulator that reproduced the console’s processors. A faster core might get a demanding game running on a modest Pentium. A more accurate one might fix behavior the faster core missed. Giving users a choice let them find the compromise that suited their PC and the game they wanted to play.
Even when a Genesis game looked convincing, its music could give the emulator away. The console used both FM synthesis and a PSG sound chip, and a timing error or missing channel could spoil the sound. Sites such as Zophar’s Domain posted DGen and Gens updates as they arrived, making audio fixes another reason to download a new build. The May 1999 Zophar archive captures how many small technical changes could pass before a reader in a single month.
Behind those releases lay shared knowledge about the 68000 processor, the Z80 sound processor, cartridges, graphics hardware, and controllers. Some emulator code was open and some was not, and credit could get messy: a faster release might draw more attention than the program that had documented a chip. The work of Dallongeville, Dave, Snake, Addis, and the people maintaining technical references reached players through those downloadable ZIP files, even when their names did not.
PC Engine: Hu-Go! and Magic Engine
For many Western players, a few familiar TurboGrafx-16 releases were only the doorway into the PC Engine’s much larger Japanese catalog. David Michel’s Magic Engine continued to mature in 1999, with work on CD support and a polished commercial distribution. It gave some players a dependable way to try games that had been difficult to reach outside their original market. Charging for an emulator still prompted arguments about payment and preservation, but this was a different setting from the lawsuits in Part I: an older machine that was no longer being actively marketed to the same extent.
Hu-Go! took another route into that library. Associated with Olivier Jolly, known as Zeograd, it emerged in 1999 from Bero’s earlier FPCE work and began establishing an identity of its own. Public DOS releases, followed by ports to other systems, let more people try PC Engine games. Its connections to other authors’ code and documentation were part of that development. Before a player could see a game running, someone had to map the hardware’s behavior and dump the software accurately; Hu-Go! built on that earlier work.
Olivier Jolly (Zeograd) Olivier Jolly, known as Zeograd, built Hu-Go! into a free, portable PC Engine emulator and helped make that console’s wider library easier to explore.
Older projects could reach new players through ports, too. Hu6280 and its ports remained in the conversation. An emulator could find a second life on another operating system even after its original author slowed updates. Moving from DOS to Windows or Mac meant adapting input, sound, timing, and CD access, so the experience was not automatically the same on each system. The Zophar monthly archives show ports and beta updates keeping older programs in front of readers alongside newer rivals.
NES, Game Boy, and the value of unfinished improvements
An NES emulator could run plenty of games and still greet a favorite cartridge with a blank screen. The culprit might be its mapper: hardware inside the cartridge that changes how the console accesses memory and displays graphics. After NESticle, projects including FCE Ultra, RockNES, Nofrendo, fwNES, and the older iNES kept working on mapper support, sound, timing, disk-system behavior, and user interfaces. Adding support for another cartridge’s mapper was less showy than an N64 breakthrough, but for the player waiting to run that game, it was a good reason to download an update.
Some programs also let players look beneath the game. Debuggers, tile viewers, cheats, save states, and recording features helped fans translate games, investigate glitches, and work out how the console operated. Someone who arrived just wanting to revisit an old favorite could end up studying memory banks and video registers. The emulator put those workings within reach, alongside the controls for actually playing.
Game Boy emulation had its own unfinished business: battery saves, color hardware, sound, link behavior, and unusual cartridges all needed attention. Marat Fayzullin’s Virtual GameBoy remained part of the field while other projects competed on speed, platform support, or accuracy. The tiny display was unforgiving. A misplaced sprite or an incorrect palette could occupy a large share of the picture, leaving an obvious flaw in a program that otherwise ran dozens of titles.
DarcNES refuses to be only a NES emulator
Alastair Bridgewater’s DarcNES was beginning to outgrow its name. During 1999, it added more machines and reached more operating systems. The research archive records Game Gear, PC Engine, Master System, ColecoVision, and SG-1000 work arriving in stages, along with DOS, Amiga, BeOS, and Linux ports. A NES-focused project was becoming a multi-system emulator, one driver and port at a time.
Alastair Bridgewater Alastair Bridgewater made DarcNES a portable multi-system experiment in 1999, expanding a NES-focused emulator across Sega, NEC, and older computer hardware.
Getting DarcNES onto those computers took more than changing a compiler setting. Moving a Unix build to DOS could require new work on video output, sound, input, timing, file handling, and configuration. An Amiga or BeOS player benefited from that effort without needing to know how the program ran elsewhere. Where UltraHLE pursued a spectacular target, Bridgewater was testing how many consoles and host systems one architecture could span, making access to their games less dependent on a single operating system. The expanding workload brought a familiar risk: a newly added machine could arrive before its sound or other quirks were complete. DarcNES’s ports and drivers tracked both its reach and the work still needed to finish it.
Atari and Intellivision still count
Dan Boris gave the Atari 7800 a dedicated emulator with V7800 in 1999. Nintendo and Sega had commercially overshadowed the console, but reproducing its hardware still posed technical problems worth tackling. A standalone program gave Boris room to work on them before that work was ready for a larger framework such as MESS. He already had experience with Atari emulation; V7800 continued that practical interest in keeping the machines playable.
Dan Boris Dan Boris released V7800 in 1999, bringing his Atari-emulation experience to the 7800 while its planned MESS home was still developing.
The Intellivision got a dedicated emulator too. Joseph Zbiciak‘s jzIntv first reached the public in 1999, according to the project history preserved in the research archive. Behind the distinctly un-store-bought name was an author working to reproduce one machine in software and share what he learned. It served a smaller audience than SNES or PlayStation emulation, but gave Intellivision players another way back to their games.
Joseph Zbiciak Joseph “Joe” Zbiciak brought jzIntv into public view in 1999, building an Intellivision emulator for players and for people who wanted to understand the machine.
Older systems also returned through commercial compilations and one-off emulation projects. Mike Livesay, whose Atari 2600 work appeared earlier in this history, contributed technology to later classic-game products. A commercial collection could put old games in front of a large audience without players ever noticing the emulator inside. Independent releases often reached fewer people, but could expose more of the technical work. Both approaches had a place in the emulation landscape of 1999.
Super Nintendo progress is measured in hard cases
Snes9x and ZSNES were already famous by 1999, and both could still stumble over a difficult cartridge. The Super Nintendo’s special chips, layered graphics, and audio timing could defeat a build that ran simpler games beautifully. A team might improve dozens of ordinary titles, then spend weeks on one that used the SA-1 processor or an unusual graphics mode. These were features of the console that developers had used to make their games, so getting the easy titles running left plenty of work.
Even a game that worked well in one port could cause trouble in another. Snes9x served Windows, DOS, Mac, and Unix-like users, with frontends and controls that often differed between platforms. Two ports could share a version number while one still had a bug specific to its host system. The September 1999 Zophar archive puts news of a Windows port, Mac updates, and other platform work alongside ordinary release announcements. Readers arrived with different sound cards, controllers, operating systems, and favorite games; an update that helped one player might do little for another.
ZSNES drew a loyal audience with its performance and an interface that became familiar to thousands of players. Its 1997 dispute with Snes9x remained part of the history, but by 1999 both projects also had substantial technical work to show. They were making a complicated console run on computers that often had less spare power than a modern phone. Speed could turn a sluggish game into an enjoyable one; greater accuracy could recover behavior that a shortcut missed. Players often kept both emulators installed.
Networking and display options gave players more reasons to experiment. Two friends with suitable machines and connections could try playing across a distance, while graphics settings helped make a low-resolution console picture comfortable on a PC monitor. Each addition brought bugs as well as convenience. Users increasingly expected an emulator to do things the original machine had never offered, alongside the difficult business of reproducing what it did.
PlayStation work outside the courtroom
Away from the commercial PlayStation cases covered in Part I, independent developers were dividing up the console’s problems. PSEmu Pro’s plugin system separated the emulator core from graphics, sound, and CD handling, establishing a model that lasted beyond the project. Pete Bernert and other plugin authors could tackle one part without writing a whole emulator. Players could swap between two renderers on the same game and test where a slowdown came from. Troubleshooting became more complicated, though: a crash report needed plugin versions and settings before anyone could make much sense of it.
In June, Zophar reported PSEmu’s end after a private beta leaked and public accounts of the team’s communications became tangled. The site revised its own interpretation of earlier messages. A leaked, unfinished build could leave strangers judging work that was not ready for them and undermine trust among its developers. PlayStation emulation continued elsewhere, but this collaboration had been damaged.
FPse appeared publicly in 1999 as another free attempt at PlayStation emulation. Its early releases were limited. Executing tests or reaching BIOS behavior was a step forward, but still some distance from playing discs in Connectix’s commercial product. FPse’s authors were letting people see that earlier stage of development. AdriPSX, Psyke, and other projects were working through the same difficult machine at different stages. A boot screen, a running demo, partial graphics, and a playable commercial game each showed progress, but offered very different prospects for someone hoping to sit down and play.
Around those emulators grew a collection of smaller tools: disc identifiers, graphics and sound plugins, memory-card utilities, and debuggers. Players might never learn their authors’ names, even when the tools made a release usable. The May 1999 Zophar log captures some of that surrounding work. While the legal arguments concerned whether a product could be sold, programmers were often occupied with more immediate obstacles: getting a game to load a CD track, or keeping its music synchronized.
Smaller arcade projects do not mean smaller engineering
Looking for an arcade emulator in 1999 meant picking through a crowded directory. JFF, GalEmu, System 16 Emulator, M72, Cinematronics emulators, Shark!, and numerous single-board projects sat beside MAME, Raine, and NeoRageX. Some were new, some were fading, and some concentrated on one beloved cabinet. The Archaic Ruins arcade directory preserves that crowd: plenty of developers were pursuing the same games through different approaches to their hardware.
Narrowing the target could help. A vector display drew differently from a raster display, and a Capcom board did not work like a Williams board. Even a program that could draw the whole scene might be fooled by a cabinet’s custom protection device. A specialist could concentrate on that one obstacle. Once they worked out how a chip behaved, a broader emulator might use the discovery too—provided the knowledge could travel. Credit, access to code, and relations between developers all affected whether an isolated success became a shared improvement.
When two programs added the same game in the same month, news readers had an obvious question: which should they use? Speed, sound, and correct colors gave them plenty to argue about. A screenshot offered only an imperfect check on the colors; it could say little about how the game played. Useful comparisons meant playing on a known host PC and recording where each emulator failed. Players who did that gave developers something they could work with, rather than another declaration that somebody had “won.”
The directories also held projects at different stages of winding down. System 16 Emulator’s final activity was separate from its later ports: a port could arrive after work on the main program had stopped. Some code was lost; other work carried on in new frameworks or in its authors’ careers. A project could disappear from the news while its ideas survived in another program. The projects pictured here were not all equally active at the end of 1999.
Frontends, controllers, and the last mile
Before a player could compare speed or sound, there was a less glamorous challenge: getting the game to start. Each emulator could have its own command-line switches, filename rules, ROM folders, video modes, and controller mappings. Frontends such as ArcadeOS and project-specific launchers put a familiar game-selection screen in front of that machinery. Some players called them cosmetic. A ZIP file in the wrong folder could make a convincing argument otherwise.
Hardware companies were paying attention too. Zophar’s May 1999 report described a HotRod arcade joystick package that included MAME, a special Arcade@Home edition, and licensed Capcom game ROMs. The arcade-at-home pitch brought together a physical controller, an emulator, a website, and authorized games. A hobby built around free downloads now also had a retail hardware bundle with a publisher’s permission.
Tim Eckel, whose work is covered in his Arcade At Home biography, was not an emulator author, but his site became part of the experience a hardware maker wanted to offer players. Webmasters and interface authors helped turn working code into something people could enjoy, through news, configuration help, accurate files, and—when hardware joined the package—something pleasant to hold.
The CD and cartridge boundary
Getting a game to start became more complicated when it came on a disc. By the end of the decade, “game file” no longer necessarily meant a compact cartridge image. The PlayStation used CD-ROMs, while the PC Engine and Sega CD libraries also required emulators to coordinate data tracks, audio, loading delays, and disc changes. A BIOS screen could appear perfectly, only for the program to fail when a game streamed music. An emulator that ran HuCards might have no CD support at all. Players who saw a console’s name on a download page could easily expect more of its catalog than the program could deliver.
Magic Engine’s CD work in 1999 pushed into that territory. Gens would later become known partly for Sega CD support, but that capability should not be read back into its first 1999 release. Independent PlayStation projects, meanwhile, had to work with physical drives and disc images as well as emulate the CPU and graphics. Disc handling reached straight into the experience of playing: whether a game started, whether the next scene loaded, and whether its soundtrack sounded as it should.
Discs also put a heavier load on sharing games. A small cartridge image could fit easily on a fan site’s server; a CD image could run to hundreds of megabytes, a substantial burden for a 1999 host and a more conspicuous presence to rights holders. Even sites that offered only emulator binaries could receive requests for discs. Others built archives that made publishers nervous. Moving from cartridges to CDs intensified the social and legal disputes discussed in Part I, while writing an emulator remained a separate activity from distributing games.
What a 1999 release number could hide
A game could reach its title screen and still fall apart before the end of the first level. That made release numbers a shaky guide to what you could actually play. One project’s 0.1 might run several favorites; another’s 1.0 could still fail on an obscure board. Each author set their own numbering, and a compatibility percentage depended on which games had been tested and what counted as “working.” Reaching the credits was a different achievement from getting past the menus. News sites linking the latest ZIP did not always have room to spell that out.
The most useful release notes told players exactly what had changed: a mapper fixed in RockNES, a sound chip improved in DGen, a new arcade board in MAME, or a demo that Nemu64 could now display. You could look for the fix you needed rather than guess from a version number.
Nobody was waiting for the headlines
Even playing the most recognizable game did not make an emulator the winner of this crowded field. The teams had different goals. MAME could document an arcade board while warning that its sound was incomplete. A Sega specialist might fix an obscure mapper that kept a small group of players from enjoying a particular cartridge. An Intellivision author could spend months on hardware that drew only a fraction of the attention given to the Nintendo 64. The long list of names reflected how much there was to tackle, and how differently programmers chose to spend their time.
Work also passed between projects. A bug report on one site could lead a programmer to a hardware document; a frontend writer could make several emulators easier to use without writing any CPU code. Early source archives preserve the patient work behind later releases.
Players wanted the next game to work now. Programmers needed reports precise enough to track down faults in timing, graphics, and sound. A volunteer’s first message after a release might be a complaint about a game they had never promised to support—a fairly joyless reward for getting a new build out the door. Still, enough people tested again, wrote down odd results, and sent useful feedback to keep the work moving. While the legal battles in Part I drew headlines, these quieter exchanges between makers and players helped emulators improve.
A 1999 game in the GameBase
Pokémon Gold belongs to the 1999 handheld world these programmers were trying to understand. Its GameBase image marks the game’s release year, without implying that every Game Boy emulator available that year could run it correctly.
People in this chapter
- Stéphane Dallongeville — Gens creator who entered the Genesis emulator contest.
- Olivier Jolly (Zeograd) — Hu-Go! author who helped bring the PC Engine to more players and platforms.
- Alastair Bridgewater — DarcNES author whose project expanded beyond its NES roots.
- Dan Boris — Atari emulator author whose V7800 focused on a machine others could overlook.
- Joseph Zbiciak — jzIntv creator and a new voice in Intellivision preservation.
- Omar Cornut — returning figure whose MEKA moved into public release in 1999.
- Anders Nilsson and Janne Korpela — returning NeoRage authors behind the Windows-era NeoRageX.
Sources and further reading
- MAME project milestones, MAME release archive, and MESS version archive.
- MEKA official history and original news archive.
- Gens source-code lineage and Zophar’s May 1999 news.
- Archaic Ruins arcade emulator directory.
Part of: The Complete History of Video Game Emulation
Browse biographies: People in the History of Video Game Emulation