Retro Replay Retro Gaming History, Reviews & Emulation
A commercial game reached its title screen, then froze. In 1998, that could still count as progress for an emulator. Elsewhere, a sound effect finally played or a new window made a program easier to use. Players had good reasons to welcome all three, but getting a game to start was a long way from getting to play it.
The year behind the game list
The websites in Part I delivered these updates quickly, sometimes in a dizzying jumble. A Game Boy emulator improved its timing. A Super Nintendo build added Super FX support. A PlayStation project changed its entire interface, while an N64 author managed to display a logo. Each programmer was wrestling with a different problem. A Pentium that ran an NES emulator at full speed might struggle with a 16-bit console and have almost no chance of faithfully reproducing a Nintendo 64 game.
The computer on your desk also shaped what you could play. DOS remained important because it gave programmers close control of graphics and sound. Windows 95 and 98 offered a friendlier desktop and more standardized multimedia APIs—the interfaces programs used to work with sound and graphics. Macintosh, Amiga, Unix, and other ports brought projects to different audiences. An emulator could be impressive on one machine and awkward, or simply unavailable, on another. “Does it run?” depended on the program, the game, and the host computer together.
Even programs with similar compatibility lists could feel different in use. One programmer concentrated on speed for modest hardware; another built a plugin system so specialists could work on graphics or sound independently. Others were still trying to show that a brand-new console could be understood well enough to emulate at all. Those choices shaped both the games users could play and the code later programmers inherited.
NES: the race did not end with NESticle
Icer Addis’s NESticle had dominated the previous year’s conversation, but NES emulation was far from settled in 1998. The machine looked simple beside a PlayStation. Its cartridges complicated things. Many contained mapper chips that changed how games accessed memory, generated interrupts, or handled graphics. An emulator could run Super Mario Bros. beautifully, then fail on a favorite role-playing game because its cartridge used different extra hardware. Making the central 6502 processor run faster would not fix that. Developers had to understand the individual cartridge boards, too.
RockNES was among the projects appearing in Patent Pending’s September news, which listed version 0.54. FCE and its later FCE Ultra branch also attracted attention, alongside fwNES, Famicom.exe, Pasofami, iNES, and other Japanese and Western projects. They offered different combinations of speed, platform support, cartridge compatibility, and interface design; their authors also differed in how willing they were to share code. Some programs were shareware, others tiny technical demonstrations. Players had a practical reason to keep several installed: the stubborn game that failed in one might finally work in another.
FanWen Yang FanWen Yang’s fwNES98 offered another route through the NES’s stubborn cartridge library, with versions for DOS and Linux and a distinctive interface.
One of those small programs was very small indeed. Zophar’s February 1998 archive described NESemu 0.01b as just four kilobytes and fast on a Pentium 75. Its listed features covered the processor, palette, background, sprites, joypads, and register behavior. That gave readers a picture of what the author had built, though it did not establish that the program could run the whole NES library. The same page mentioned Hexposure, a tool for editing text in NES game files. Emulation, translation, and ROM hacking drew on shared knowledge of how games stored their data, and the people who wanted to play those games were often also interested in changing or translating them.
English-language news sites could not always keep up with Japanese programs. A November Zophar report on the FAN98 family described FCFAN98, an NES emulator whose documentation and interface proved difficult for the editor to translate. The site could confirm that it produced sound and ran The Legend of Zelda, but could not confidently explain every feature. Parallel communities were making technical discoveries that an English release report might only partly capture.
Meanwhile, players were asking for more. Save states and controller mapping were becoming expectations. Support for an uncommon mapper could make all the difference if it brought a cherished game into reach. Clear menus helped users who did not know which command-line option selected a cartridge image. Speed still counted on home PCs with limited memory and graphics capability: a more accurate emulator could be less enjoyable on the computer you actually owned. NES developers spent 1998 balancing those demands, with plenty left to fix.
November: FCE Ultra grows from an earlier experiment
FCE Ultra grew out of Bero’s earlier NES emulator, FCE. The FCE Ultra project’s version history records that another code path was tried and set aside before work restarted from the original source under DOS. FCE Ultra Beta 1 appeared at the end of November 1998. The new name marked a restart, with the earlier FCE work still underneath it.
Players who know the much later FCEUX may recognize the family name, but its familiar tools were not waiting in that first beta. Ports, debugger features, movie tools, and broader support for cartridge mappers came through later work by multiple people. In November 1998, FCE Ultra was a new foundation built from Bero’s earlier contribution, with that growth still ahead of it.
Restarting an emulator could mean losing time and breaking games that had worked before. It could also offer a way out of code that had become difficult to extend. Timing and mapper errors could otherwise lead to a growing pile of game-specific fixes, each patch working around a problem rather than removing it. The FCE Ultra history records a change of course, not a public feud.
The Game Boy and the machines beside it
The original Game Boy had inspired emulators well before 1998, but its games could still trip them up. Behind that modest handheld screen were timing and interrupt details capable of breaking an individual title. Then Game Boy Color arrived that year and gave developers more hardware to account for. Running monochrome cartridges well did not automatically mean an emulator could handle the new color features. News pages followed Boycott and other portable-system projects while players compared speed, palettes, and compatibility.
Marat Fayzullin’s Virtual GameBoy was already an established name; newer authors were finding their own ways to make handheld games comfortable to play on a PC. A November Zophar report described a forthcoming Boycott update with color files, VESA detection, GUI improvements, and speed work. These were everyday conveniences: getting the screen to look right, detecting the video mode, finding a game through the interface, and running it quickly enough. There was plenty to improve after an emulator could first put a game on screen.
Sega’s Master System and Game Gear had active projects too, including BrSMS and Massage. Omar Cornut was working on Meka during this period, though its public debut came in 1999. Its origins and the beginnings of his SMS Power site belong here in 1998. Before the emulator reached players, the website was already a place to share knowledge and document games, laying groundwork for the program it would eventually support.
Omar Cornut (Bock) Omar Cornut was building the foundations of MEKA and SMS Power in 1998. The public emulator breakthrough belongs to 1999, but the work already shows his deep affection for Sega’s 8-bit machines.
Further back in console history, John Saeger continued work on the Atari 2600 emulator z26. September news lists the release of version 1.11. The Atari’s display behavior remained surprisingly difficult to reproduce: games that depended closely on its peculiar timing gave emulator authors little room for error. A machine from the 1970s could still make a modern PC programmer work for it.
Super Nintendo: the contest gets technical
After their public dispute over technical information, ZSNES and Snes9x kept developing through 1998. For players, the test was immediate: did the game scroll correctly, sound right, save reliably, and run at a decent speed? Meeting all four demands meant wrestling with the Super Nintendo’s graphics modes, windows, transparency, sound processing, and cartridge enhancement chips. A visible improvement could require a major rewrite of the video path. Fixing one rare game could uncover a faulty assumption affecting many others.
ZSNES version 0.400 offered a good view of that work. The May 1998 Zophar archive lists Super FX support, explicitly described as buggy, alongside sprite-window fixes, sound DSP changes, interleaved file detection, faster drawing options, Mode 7 optimization, and numerous graphics corrections. A player could gain speed or see a troublesome scene draw correctly, yet still find that another game relied on a feature the new build had only begun to handle.
Super FX was an especially visible step. Players knew the chip from Star Fox and other games that squeezed surprising 3D scenes out of a 16-bit console. It was extra hardware inside selected cartridges, so an emulator had to reproduce more than the base SNES to run those games. Even a program that handled ordinary cartridges well could fail completely on a Super FX title. ZSNES’s early support made headlines by reaching into that part of the library, but the release notes’ warning still applied: support had arrived with rough edges.
Snes9x’s core work could stall for a reason no amount of clever programming would fix: its author needed a computer. A September 1998 contemporary update reported that Gary Henderson had a new laptop and could resume that work, while other volunteers offered help with the Windows port. Henderson and his collaborators fitted development around jobs, family, and the demands of different ports. Players around the world might be waiting for an update, but a missing computer or a busy month could delay it. Getting a volunteer back at the keyboard was news.
Snes9x and ZSNES did not have the SNES to themselves. SNEeSe, SNEmul, ESNES, NLKSNES, and platform-specific ports tried different balances of compatibility and speed. Front ends made programs easier to use, while separate SPC sound-file players let fans listen to soundtracks without playing the games. Someone might choose one emulator for a favorite action game and another to examine its graphics. There were practical reasons to keep several programs around, and the competition encouraged authors to spell out what each new release had fixed.
Genesis: speed, sound, and a crowded shelf
On Sega’s Genesis, also known as the Mega Drive, Steve Snake’s KGen and Icer Addis’s Genecyst had already made games approachable in 1997. More programmers kept joining the race. [James Ponder] dates Generator’s first public release to August 1998 in his project description (https://www.squish.net/generator/description.html). Megasis arrived later in the year, joining GenEm and other efforts. These projects ran on different host platforms and made different compromises. A player listening closely to the FM music and watching for crisp scrolling might choose a different build from someone trying to get full speed out of an older PC.
James Ponder James Ponder turned a university investigation of fast processor emulation into Generator, a Genesis project whose August 1998 release challenged the assumption that speed required hand-written assembly.
Getting that music right was particularly frustrating. The Mega Drive’s Yamaha FM sound could produce a recognizable melody that still lacked the sharpness or balance a fan remembered. Cartridge games brought unusual memory layouts and control schemes, too. Beyond them lay the Sega CD and 32X, which added processors, media handling, and more hardware behavior to reproduce. The local history records AGES and CDX1 experimenting in that territory, but those efforts did not mean a typical 1998 emulator could play the whole Sega family. An ambitious name on a download page could promise rather more than the program delivered.
Fans also watched for signs of progress between downloads. The May Zophar archive reported that KGen was still in development. A homepage update could reassure users that work continued; a long silence could set rumors going. Some programmers posted work-in-progress screenshots, while others waited until a feature worked before showing it. News sites speculated either way. Their readers wanted to know when a favorite game might finally become playable.
Even when a game worked, the computer running it could shape the experience. A DOS build tuned for a particular graphics card or sound setup might be startlingly quick, while a Windows program offered easier controls and file browsing. Macintosh, Amiga, and Unix ports brought more people in, but each needed maintenance of its own. The same Genesis game could run smoothly on one setup and turn choppy, silent, or incompatible on another. Surviving compatibility notes capture those differences far better than a later declaration that Genesis emulation was “done.”
PC Engine: a smaller machine with a persistent following
For PC Engine fans, a sprite fix or a working save state could be enough to make a new release worth trying. The machine, also known as the TurboGrafx-16, had a devoted following, but its HuCards, CD games, regional names, and range of host platforms gave emulator authors plenty to handle. David Michel’s Magic Engine had begun earlier; Hu6280 was another project readers followed through 1998. The May Zophar archive records Hu6280 updates that fixed sprites, adjusted palettes, and added load/save states. Those changes could make the difference between a brief test and settling in for a long session.
Hu6280 took its name from the console’s HuC6280 processor, but decoding that processor’s instructions was only part of the job. Graphics layers, scrolling, sound, and cartridge behavior all had to cooperate for a game to look and feel right. A sprite bug might leave a simple test game untouched while breaking a favorite title. Even save states depended on capturing every piece of the machine’s state; miss something, and returning to a saved moment could be unreliable. The release notes show programmers tackling these defects one at a time.
Magic Engine also asked players to pay, challenging the scene’s assumption that emulators should be free and bringing a different development pace and set of user expectations. The argument reached beyond the PC Engine. In November, Zophar reported Japanese FAN98 emulators sold as shareware with directional controls disabled until registration. Some users saw payment as a reasonable return for demanding technical work. Others found an emulator that would not let them move a particularly cruel demonstration. Volunteer and commercial programmers were working alongside one another, and players had yet to agree on what they owed either group—or what they should expect in return.
PlayStation: PSEmu Pro chooses a modular future
Marcin Dudar’s PSEmu had appeared in 1997, taking on a PlayStation that was still current hardware, with publishers still selling games. It was a much tougher target than an NES or Game Boy. In 1998, PSEmu Pro moved from DOS toward Windows and split some of the work among interchangeable plugins. The Zophar file archive retains a January 14, 1998 DOS release and a December 31 Windows-era release, and credits the program’s plugin standard with lasting influence. Separate components let specialists tackle graphics, sound, and input without requiring a complete new emulator for every improvement.
Players inherited some of that work. They had to choose a graphics plugin that suited their video card, find settings that improved speed without breaking effects, and make sure the sound plugin matched the build. An integrated emulator could hide those decisions, but its author then had to stick with one implementation. PSEmu Pro offered more choices—and more ways to get confused. Its main program supplied the machine framework while plugins handled some of the demanding parts, a pattern future PlayStation emulators could adopt.
The interface was getting friendlier even as developers uncovered errors deep inside the emulated machine. Zophar’s November 18 report announced PSEmu Pro 1.0.19 as a public beta with a GUI, better compatibility, and additional or updated plugins. A November 27 follow-up described a fix for a large GTE bug. The Geometry Transformation Engine handled central parts of the PlayStation’s 3D math. Get one of its operations subtly wrong and a game could load, only to draw broken geometry. A nicer set of menus could not fix that.
Pex and Psyke were exploring PlayStation emulation too. Some projects produced intriguing screenshots before they could sustain gameplay, and a current console made those first pictures especially exciting. A logo, menu, or opening 3D scene could be greeted as proof that the machine had been “cracked.” The programmer might still face years of work; a publisher could see a threat, and a player could expect far more than the program could deliver. News traveled faster than the code improved.
Nintendo 64: homebrew play and commercial impossibility
On the Nintendo 64, even a game of Pong was hard going. Zophar’s February 1998 report said Michael Tedder’s Project UnReality 0.3a could play the homebrew Pong64 at roughly eight frames per second on the editor’s Cyrix 6×86 machine. The release offered stronger 2D behavior, controller emulation, and very primitive audio. That month’s compatibility document also said no commercial games were playable, though some displayed the Nintendo 64 logo. Getting a homebrew game moving was progress. Players hoping to run their commercial cartridges still had to wait.
The Nintendo 64’s main CPU, graphics and signal processors, memory behavior, and cartridge formats all had to work together. Drawing a startup logo showed that an emulator understood some display code and startup behavior. Keeping a game responsive, drawing its scenes, playing its audio, and holding everything in sync for hours demanded much more. Project UnReality, TrueReality, Reality64, and other experiments tackled different parts of that problem in 1998. Some announcements promised more than the public builds could manage, but the experiments exposed how much of the current console programmers still had to understand.
Development could also stop for reasons that were difficult to pin down from outside. According to the site’s May report, Reality64 development had resumed after legal trouble appeared to be resolved. Rumors flourished around Nintendo. A private pause could turn into a supposed cease-and-desist letter among readers, while a news editor might have only a short message from the developer. Programmers were publicly trying to reproduce hardware its maker was still marketing, with incomplete documentation.
Meanwhile, the console’s games kept moving ahead. A 1998 Nintendo 64 release, The Legend of Zelda: Ocarina of Time in Retro Replay’s GameBase, offered the kind of 3D world, sound, and controls fans wanted to bring to a PC—far beyond the slow homebrew Pong64 described in February. The 1998 UnReality record does not show players running Ocarina of Time.
Saturn: the machines that would not yield
The Sega Saturn was proving even harder to coax into running games. Its combination of processors and video hardware posed an exceptionally difficult problem, and early projects such as Satan, SSEmu, and A-Saturn appeared in directories and news items with modest capabilities. Zophar’s later Saturn directory describes Satan as little more than a CD-header reader and says A-Saturn did not run games. That directory covers several years, so it cannot date every project’s debut, but it does show how far these efforts remained from something a player could use.
SSEmu stopped before Saturn owners could play commercial games on it. In November 1998, Zophar reported SSEmu canceled, with a sharp personal note from the editor about Saturn documentation he said he had supplied. Shared technical material had led to disappointed expectations and a public complaint. Meanwhile, the machine’s complex display and timing still needed untangling. Reading a CD header or getting part of a processor working could take real effort without producing anything a player could use.
PlayStation emulators could put scenes on screen, and Nintendo 64 homebrew was beginning to crawl. Saturn games remained out of reach. Its processors had to stay in step, and their interactions could undo work that looked correct when tested alone. Adding processors meant adding synchronization problems, not simply more of the same work. The Saturn scene would spend longer with technical demonstrations, abandoned projects, and hopeful news than with people playing full games.
Computers, ports, and the missing half of the scene
Away from the console race, home-computer communities had been preserving software for years. Some of that work on the Commodore 64, Amiga, Atari ST, MSX, and Sinclair Spectrum predated the console scene’s explosive growth. Getting a game running could involve more than loading a cartridge: emulators had to account for disk drives, keyboards, memory expansions, and software written for different hardware configurations. UAE tackled the Amiga; VICE handled Commodore machines. With problems like these across so many systems, MESS’s broad architecture was an ambitious undertaking.
Then there was the computer you wanted to play on. Windows PCs, Macintoshes, Amigas, and Unix workstations used different graphics interfaces, audio systems, file dialogs, and input devices. Moving an emulator between them could expose assumptions its original author had never needed to question. A hard-coded DOS video mode did not fit neatly into a Macintosh desktop, and sound code tied to one PC library might need rebuilding. Porters did that work so a breakthrough on one developer’s machine could reach players on others.
Richard Bannister helped make that crossing on the Macintosh. Generator’s later Macintosh page credits him with porting James Ponder’s Genesis emulator. The Generator project description says Ponder developed it as a college project studying optimized processor emulation, and highlights its performance without assembly code. Fast emulation did not always require hand-written assembly: careful algorithm choices could count for more than the language’s reputation.
Those choices came with tradeoffs. A higher-level language could make code easier to move between systems and easier for collaborators to inspect. Hand-tuned routines for a particular platform could squeeze more speed from a modest PC. An arcade experiment built to run one game might reasonably favor the author’s own machine; a multi-system project intended to survive years of hardware changes had more reason to stay adaptable. In 1998, developers had good reasons to take either route.
A scene learning to credit its tools
Even an emulator written for one machine rarely stood alone. A PlayStation graphics plugin needed an interface agreed with the main program. A SNES developer might rely on another team’s Super FX notes. News editors translated Japanese release notes or mirrored files after a homepage vanished, while ROM-checking utilities needed accurate information about the sets they checked. Code, documents, and file formats passed between people, giving other developers something to build on and players something they could actually use.
The ZSNES 0.400 notes thanked the Snes9x team for Super FX information, despite the previous year’s ugly public dispute. The argument had not made technical cooperation impossible. Developers could clash over conduct, disagree about the balance between speed and accuracy, and still help one another understand the same chip.
PSEmu Pro’s plugins made some of that shared work visible to players. Instead of keeping every hardware subsystem inside one program, it let users choose components made by different authors. Pete Bernert‘s own project site dates his first PlayStation emulation releases to late 1998 and describes plugins handling graphics through the GPU, sound through the SPU, CD-ROM access, and controllers. His later plugin code and documentation show the approach continuing beyond PSEmu Pro. The choices in a 1998 beta’s settings dialog were the beginnings of a collection that would keep growing.
Pete Bernert Pete Bernert entered PlayStation emulation in late 1998 and became one of the people who made PSEmu Pro’s plugin architecture more than a clever idea.
Sharing the work also meant becoming reachable. Each public release brought support requests, and each new combination of plugins offered another chance for something to go wrong. A developer with a day job could find strangers expecting replies to questions already answered in the documentation. A site operator might get blamed for an emulator’s failure after linking a broken file. The excitement came with a support burden, one reason a project could pause or stop without a dramatic legal threat.
What 1998 did not finish
Some projects vanished; others restarted under new names. A port might lag behind its DOS original, and a PlayStation game could improve with one plugin and break with another. These were problems the next year’s programmers inherited alongside the breakthroughs.
Several famous arrivals were still ahead. Meka’s public debut came in 1999, as did UltraHLE and its commercial Nintendo 64 emulation. Bleem! and Virtual Game Station also became public stories in 1999. Their ingredients were taking shape during 1998, and readers could sense something approaching. They could not yet download anticipation and play it. The projects already available had achievements of their own, even when they fell short of what the following year would bring.
A game that starts, a game you can finish
Even “first” depended on what had happened: a screenshot, a public build, a running homebrew game, a commercial title screen, or a game someone could comfortably play. Project homepages and news archives sometimes greeted these different milestones with the same triumphant language. A programmer could learn something important from a small demo while a player still waited for an emulator that could finish a level, play the soundtrack, save progress, and work again tomorrow.
The strongest projects gave users ways to judge that progress: compatibility lists, known issues, and release notes. News sites helped when they carried the caveats alongside the exciting screenshot. They made life harder when a promised feature became a finished one in the retelling, or a technical demo was presented as a replacement for a console. Developers had to explain what their programs could do as well as make them do it. Game companies, curious players, and competitors were all watching.
No one ended 1998 with every console solved. They did leave working software, useful experiments, and routes for others to follow into 1999, when the gap between an experiment and a playable commercial game would narrow considerably.
People in this chapter
- Marcin Dudar — returning PSEmu creator whose project moved into the Windows and plugin era.
- Michael Tedder — returning Project UnReality leader at the center of the early N64 effort.
- Gary Henderson — returning Snes9x programmer balancing difficult core work and the realities of a volunteer project.
- Omar Cornut — SMS Power and Meka creator whose groundwork preceded Meka’s 1999 public release.
- FanWen Yang — fwNES author in the crowded NES field.
- James Ponder — Generator developer in the Genesis/Mega Drive race.
- Pete Bernert — graphics-plugin contributor whose work mattered to PSEmu Pro’s modular direction.
Sources and further reading
- Zophar’s Domain, February 1998 news
- Zophar’s Domain, May 1998 news
- Zophar’s Domain, November 1998 news
- Patent Pending, September 1998 news
- PSEmu/PSEmu Pro release archive
- Zophar’s Saturn emulator directory
- SMS Power
Part of: The Complete History of Video Game Emulation
People introduced in this chapter: Omar Cornut (Bock), FanWen Yang, James Ponder, Pete Bernert
Browse biographies: People in the History of Video Game Emulation