A PC that ran NES games at a comfortable speed could still struggle with a single Super Nintendo game. In the second half of 1997, emulator authors pushed toward newer, more complicated consoles, and players could see both the progress and the failures on their screens. Behind the SNES race, developers shared hard-won technical knowledge—and became embroiled in one of the scene’s loudest public arguments.
More machines than any one person could follow
Arcade and NES emulators had already found audiences far beyond the original experimenters. Now a busy 1997 news page carried updates for Sega Genesis, Super Nintendo, PC Engine, Game Boy, PlayStation, and even Nintendo 64 projects. Some offered games you could play; others offered a glimpse of what might eventually work. A program that displayed a PlayStation logo could make headlines while remaining nowhere near a pleasant way to play. On the webpage, these projects sat a few lines apart. On a PC, the gap could be enormous.
People moved between these projects as rivals, sources, and friends, sometimes in the same month. Alongside the emulator authors were people documenting hardware and writing front ends to make the programs easier to use. Gary Henderson could help another SNES project understand sound and later accuse people near a competing project of improperly accessing his own work. Generous exchanges and bitter disputes belonged to the same scene, and the console race was still unfinished when December arrived.

Gary Henderson carried SNES emulation forward through Snes96 and Snes9x. He worked on difficult sound behavior and shared discoveries even as the SNES race grew tense.
The image labels keep a few dates straight: a preserved emulator screenshot may show a build later than its first 1997 release, and a modern capture of an old article shows the surviving page, not a browser from 1997. The pictures show how the software and pages looked; their version and capture dates tell us where they belong in the story.
Genesis emulation stops feeling hypothetical

The Genesis, also known as the Mega Drive, had a large, familiar library that looked a clear step beyond most NES games. Getting those games onto a PC meant imitating a Motorola 68000 main processor, a Z80 sound controller, video modes, and awkward timing behavior. A title screen was encouraging, but by 1997 players wanted to get past it. KGen and GenEm were already pursuing that goal, with different approaches and uneven compatibility. Bloodlust Software would enter a field where other authors had been making progress.
Steve Snake’s KGen was among the Genesis emulators players compared during 1997, as contemporary directories and later emulator histories record. Its progress came through repeated, detailed work: running a game’s 68000 code, drawing the right layers, and keeping music and controls together. Then came another game whose developers had used the hardware differently. KGen drew attention by making that difficult machine increasingly accessible on an ordinary PC. Steve Snake’s work would continue far beyond 1997, but he was already a recognized name in this competition.

Steve Snake wrote KGen in the crowded Genesis field. His work helped make Sega games feel increasingly accessible on ordinary PCs.

Icer Addis followed his April NES hit with Genecyst, another Bloodlust program that attracted players with its speed and distinctive interface. Moving from NES to Genesis required different processor and sound work; there was no shortcut through changing the name on an NES core. The polish players could see and use helped give Genecyst its appeal. It addressed the practical question of whether a PC could play a game that evening, beyond the achievement of making a console boot. Addis would later produce Callus for Capcom arcade hardware, extending his work to yet another machine.
Genesis authors also drew on reusable components and public notes. Marat Fayzullin’s processor work, along with discoveries traded among emulator developers, saved others from solving every problem again. No one had a complete official manual covering every hardware behavior games relied on. Authors examined code, compared their output with real machines, and followed up on oddities reported by users. Seeing a game work in a competitor’s emulator could help reveal what their own was missing. That was a normal part of tackling a shared problem, though in 1997 exchanges of code and ideas through private channels sometimes stirred suspicions of theft.

The Super Nintendo problem had too many answers

The SNES drew an even larger crowd of developers. Jerremy Koot’s Snes96 had already given way to his work on Snes97, while Gary Henderson continued developing the earlier code, including its difficult audio emulation. The two strands later came together in Snes9x, bringing experience from those successive attempts into one project. Meanwhile, other authors were trying their own approaches to the same stubborn console.
An emulator could draw Super Mario World well enough for a convincing screenshot, then stumble over the next game. The SNES gave developers several ways to build backgrounds and layer sprites over them, and a simple renderer could put the pieces in the wrong order. Mode 7 rotated and scaled a plane to create some of the machine’s most recognizable effects. Direct memory access moved data at precise times, while sound ran on a separate processor with its own memory and behavior. Getting one game to look right left plenty of ways for another to go wrong.
Gary Henderson was working through those problems as he carried Snes96 forward, developed its sound emulation, and contributed to the merger that produced Snes9x. He also shared information beyond his own project. Retrospective accounts describe his help with the SPC700 sound processor for ESNES, and ZSNES’s own 1997 changelog later thanks “Gary of Snes9X” for information on missing instructions. Before and after the public accusations that would erupt in October, these teams were still part of the same technical conversation.
ESNES, NLKSNES, and the Spanish SNES workshop

Carlos A. Lozano, known as Lord ESNES, began ESNES in late 1996 and released it for DOS in March 1997. The surviving Archaic Ruins directory dates an early build to March 20. ESNES supported joypads, screenshots, cheat-device codes, and a range of cartridge dump formats. That last feature could spare players an annoying first hurdle: game data circulated in several competing formats, and opening the file you already had was easier than converting it. In April, a front end called ESNES Loader made the command-line program easier to use.
Getting the game open was only the start. The SNES’s SPC700 sound processor and DSP shaped the music and effects players heard from the first moments of play. The retrospective archive describes a later ESNES release incorporating Henderson’s sound work, so the March debut and later 1997 builds offered different experiences.

Another Spanish effort, NLKSNES, came from Miguel Ángel and Alberto de Hoyo of the Nerlaska group. They aimed to make SNES games run quickly on a 486-class PC, a machine many players still owned. Their July 1997 DOS release did not reach full speed across the board, but it tackled a practical obstacle: an emulator that worked on a Pentium was little comfort if the old family computer was a 486. Lower hardware requirements could let more people play.
In the fall, ESNES and NLKSNES began moving toward a combined project, NLKE, whose name borrowed pieces of both names. Its first public release would arrive in 1998; during 1997, the merger was still work in progress. While users compared speed tables and screenshots, the two teams were trying to combine their strengths. Collaboration did not remove the everyday obstacles, though. Delays, school obligations, and limited Internet access could still push a release into the next year.
Smaller names, real work

Other developers were trying their own approaches. SNEeSe, associated with Lee Hammerton and Santeri Saarimaa, appeared in 1997 as another DOS effort. SNEmul!, by Archeide and v0x, was available by November 3, when a surviving StormWorld news archive announced an alpha release. It was still an early experiment, but players could try it. Contemporary lists also mention SNES Professional and SNESLite. Some projects were short-lived or incomplete; others left little more than an archived file or article instead of a lasting official site.
With so many projects in motion, each advance put pressure on the others. If another team solved sound or posted a beta that ran a troublesome game, users could soon ask for the same improvement elsewhere. Yet the authors were not all chasing the same target. Speed on a 486 demanded different choices from maximum accuracy on a fast Pentium, and publishing source invited a different kind of participation from keeping code private. Even a brief project could offer a useful technique, debugger, or performance experiment; a front end could save users hours without lasting for years. Competition encouraged that work, but it could also make a bug feel like a public defeat. By October, the scene was already measuring itself daily.

October 14: ZSNES enters at speed

On October 14, 1997, ZSNES published its first public release, version 0.150. Its own preserved changelog is unusually useful: it separates what was in that initial release from the fixes and additions that followed. The program was created by zsKnight and _Demo_. It drew attention for speed and ambition on DOS PCs, and it arrived in a field where users already had strong opinions about the best way to play SNES games. Its release did not settle those opinions. It intensified them.

_Demo_ co-created ZSNES with zsKnight. Their rapid 1997 releases pushed graphics, sound, and speed while drawing intense attention from rival SNES teams.

zsKnight co-created ZSNES and helped bring its fast first public release to DOS players in October 1997. The project soon became central to a heated argument about shared technical knowledge.
Version 0.150 supported the SNES’s 65816 instruction set, though bugs remained. It also handled SRAM for saved games, the LoROM and HiROM cartridge layouts, multiple graphics modes, sprites, mosaic effects, DMA and HDMA data transfers, and Mode 7 effects. That was a lot of the machinery needed to put a game on screen and keep it moving fast enough to enjoy. It was also unfinished machinery: the authors explicitly listed bugs rather than pretending every game would behave.

The version history soon filled with repairs. On October 16, the authors fixed 65816 timing, graphics, sound, and configuration problems. On October 22, they removed two SPC700 sound-processor instructions, TCALL and PCALL, while seeking reliable information on how to implement them. They restored both the next day and thanked Gary Henderson for his help. November 4 brought version 0.200, with a simple GUI, stereo sound, scanlines, and many fixes. On Christmas Day, version 0.270 credited Sardu, Y0SHi, Lord ESNES, and others for help with particular details. Even amid competition, the authors kept turning to one another to get the hardware right.
For someone who had watched a Super Nintendo game crawl in an earlier emulator, ZSNES’s speed could make playing on a PC feel newly practical. Its small team was squeezing a complex console into the performance limits of a 1997 computer, then releasing improvements in quick succession. The visual reputation and familiar features came later: network play, extra-chip support, and elaborate menus were not part of the October debut.

The email that lit the fuse
Three days after the debut, the competition spilled into a public dispute. The contemporary Archaic Ruins article “The End of SNES ‘9x” preserves emails circulated through EmuNEWS that October. On October 17, Gary Henderson accused a former Snes9x associate known as Mr. Grim of taking private source information and passing it to the ZSNES team. Henderson objected to months of SNES investigation reaching a rival through a collaborator, then being presented as independent progress. The accusation was serious, and it was contested from the start.
zsKnight replied that Mr. Grim had not sent him the Snes9x source code. Mr. Grim denied passing source to anyone and said he had shared information about documented sound concepts. Their replies left a crucial question unresolved: had private code changed hands, or had someone shared knowledge about how the SNES worked? Leaving a team did not erase what a programmer knew, and exchanging hardware observations did not necessarily mean copying a program. The surviving emails preserve the accusation and the denials, without settling what passed between the participants.
The removal and restoration of TCALL and PCALL in the ZSNES changelog leave a concrete technical trace of the dispute—and of Henderson helping the rival team afterward. Luke Sneeringer’s article “The Snes9x Past,” published by Archaic Ruins on November 1, argued that the evidence for source theft was weak and faulted EmuNEWS for publishing the allegation without checking the other side. Writing as a participant-observer, Sneeringer put the news site’s role under scrutiny: a quickly posted accusation could look like an established fact to readers.
A goodbye that did not stay goodbye
By October 30, Jerremy Koot had written a public farewell saying Snes9x could not continue. He cited other people’s conduct, personal circumstances, and a possible Nintendo claim. Henderson also wrote that arguments and requests had exhausted him, and suggested Nintendo was involved. The preserved article records those fears, not a documented lawsuit: it includes no Nintendo legal notice or court filing, and leaves later private contacts unclear. The prospect added pressure, and the farewells gave readers reason to believe one of the leading SNES emulators was ending.
Snes9x did not stay gone. It continued beyond 1997 and became one of emulation’s enduring names, though that future was hardly assured during the October crisis. Its authors faced rivals, strained relationships, and the fear that a rights holder might stop their work.
The editors covering the dispute shaped how readers understood it. Chris Hickman wrote about the scene’s appetite for conflict and the burden it placed on emulator authors. Sneeringer’s response warned against unverified accusations. Their articles preserve voices, dates, and competing interpretations, but neither gives a complete account of events.
The PlayStation was a different level of trouble

While SNES teams fought over instructions and sound, Marcin Dudar, known as Duddie, was trying to get a PlayStation running on a PC. His project, PSEmu, began around March 1997, according to his own October interview with Archaic Ruins. The early releases were prototypes. Exploring the console’s BIOS or drawing part of a game was an achievement, but anyone expecting to play a new CD from start to finish would be disappointed. The PlayStation under the television still had a job.

Marcin Dudar (Duddie) built the early PlayStation emulator PSEmu. In a 1997 interview he described the painstaking reverse engineering behind a project many people thought impossible.
Dudar was frank about where the time went. Programming took a small share compared with examining PlayStation executables and working out what they did. Without complete documentation, he had to infer the machine’s behavior from the evidence. A game depended on a MIPS CPU, a geometry engine, a graphics processor, CD-ROM timing, and audio all working together. Getting one piece running did not settle the others: polygons might appear while the game logic stalled, or a boot sequence might run without useful sound. There was a long way between a picture on the screen and a game someone could sit down and play.

The name PSEmu Pro appeared later in 1997. In the October interview, Dudar discussed plans for Windows NT and dynamic recompilation, rather than presenting them as features already available. He wanted to prove that a PlayStation emulator could exist when many people doubted it. That ambition attracted attention partly because the console was still a major commercial platform. Reproducing a current machine brought technical excitement into close company with legal and ethical anxiety.
Later accounts sometimes call PSEmu the first PlayStation emulator. That depends on what counts as a start: an announcement, a public release, a working BIOS, or a commercial game running. PSEmu was among the earliest public PlayStation projects, and Dudar’s contemporary interview gives an unusually clear account of the work. The archive also describes its early progress, though the chapter’s image is from 1998 and cannot establish what was playable in June 1997.

Nintendo 64 appears at the edge of the map

The Nintendo 64 was barely a year old in North America when Project UnReality appeared in late 1997. Michael Tedder, using the name Breakpoint, led the effort, with Dave Mayer associated with graphics work. A surviving StormWorld news entry announces the debut Windows release on November 29 and points readers to a Pong test program. It was experimental, incomplete, and demanding by the standards of many home PCs. Its importance is not that every player could enjoy Nintendo 64 games on a computer by Christmas. It is that programmers were already trying to document and reproduce a machine whose hardware and software were very much current.

Michael Tedder (Breakpoint) led Project UnReality as Breakpoint. Its experimental 1997 Nintendo 64 release offered a glimpse of a new frontier, even though commercial play remained far away.
Turning that early work into finished games meant tackling more than the Nintendo 64’s CPU instructions. Its 3D graphics, custom chips, cartridge formats, and controller behavior made the gap between a promising screen and a playable game wider than it was for an NES. Hardware notes and cartridge-dump information circulated online and helped developers, but an inaccurate or incomplete document could send them down a long wrong road. Project UnReality showed pieces of the path; more features would follow in 1998.
Even a small sign of life from an N64 game on Windows could make a reader wonder what the next year might bring. The early screenshots captured that possibility, not smooth commercial play. Emulation was reaching beyond machines people had grown up with toward machines still in stores—a shift that would change its audience and the legal attention it attracted.
PC Engine, the compact console with big ambition

In spring 1997, DOS users got another console to try: Jens Christian Restemeier’s VPCE brought PC Engine emulation to their computers, with ports to other systems following. The console was also known as the TurboGrafx-16, and later that year David Michel‘s Magic Engine offered another route into its HuCard library—and even its CD-based games. Magic Engine was commercial shareware with a limited demo. VPCE pursued its own technical path, with separate ports and supporters. Players had more than one project to follow, and more than one way to pay—or not pay—for the attempt.

David Michel created Magic Engine for the PC Engine and helped other emulator projects. His work shows how knowledge and code traveled between teams and machines.
The PC Engine was small, but reproducing its games was a sizeable job. Loading a HuCard file was only the start: graphics, sound, and controller input all needed to behave correctly. CD games added media access, timing, audio tracks, and the behavior of the CD add-on itself. For someone who had never owned the console, even choosing a game image could be confusing. Japanese and North American names, different formats, and seemingly similar images that behaved differently all needed explaining. A clear archive page could save a player a good deal of menu hunting.

Michel also helped the emerging xNES project. Work on one console could be useful on another: experience with CPU cores, graphics, and portable code could travel between teams, along with less glamorous lessons about interfaces and documentation. The same programmers kept turning up because there were plenty of problems to share.
NES, Game Boy, and the rest did not pause

xNES developed through 1997 with Nicolas Hamel, Robert Rosario, Brad Oliver, and other contributors. Ports and help from Richard Bannister, David Michel, and others widened the effort. While NESticle drew players to Bloodlust’s popular program, xNES concentrated on portable code and a foundation that multiple collaborators could take to different systems. Its later influence on MESS belongs to 1998; that groundwork was already being laid.
NES users also had Famicom.exe, fwNES, and the continuing iNES line to consider. Some projects accepted different image formats or concentrated on particular hardware behaviors, so a directory full of emulator names was not simply a row of interchangeable choices. Depending on the project, the attraction might be running on a slower computer, loading an unusual cartridge dump, or using a debugger to investigate a game. Archive listings helped users choose, especially when they explained what an emulator could not do.

On the handheld side, Paul Robson developed Gameboy 97 after his earlier emulator work, while Martin Korth’s NO$GMB was another important tool of the period. Playing Tetris on a PC was an obvious attraction, but Game Boy emulation also gave programmers a compact system to explore through debugging and homebrew. Getting it right still meant tackling sound, timing, and cartridge-bank behavior—the way a cartridge made different portions of its data available to the machine. A small screen did not make those problems disappear.
The Atari 2600 posed a different problem again. John Saeger‘s z26 reached its first release, version 0.8, on August 28, 1997, according to the project’s own repository history. Much of the 2600’s picture depended on software keeping pace with the television beam as it drew the screen. There was no convenient frame buffer holding a complete image for an emulator to translate. Even amid the rush toward SNES and 3D games, a console from the seventies could demand painstaking work. Homebrew developers and preservationists would later use z26 to test programs as well as replay old cartridges.

John Saeger created z26 for the Atari 2600. Its August 1997 debut kept one of gaming’s oldest consoles in a year crowded with newer and flashier targets.
Away from the busiest news pages, authors continued maintaining and porting emulators for ColecoVision, MSX, Atari, Commodore, and other machines. Marat Fayzullin’s libraries and utilities crossed several of those boundaries. Much of this work belonged to long-running projects rather than dramatic new arrivals, but it kept older computers and consoles in the year’s activity.
Games, translations, and the reason people cared

Most users, though, arrived with a game they wanted to play. In 1997, that could mean a Japanese game that had never received an official English release. Fan translation projects used emulators to test and share patches, and the emerging English translation of Final Fantasy V became a touchstone for that work. Players wanted to follow the story, not just get the game running.
Getting those games into English took more than a good translation. Someone had to find the text in a ROM image, work out its encoding and compression, edit the dialogue, and squeeze the new words into limited space. Then came testing in an emulator. A translator might never write a CPU core; an emulator author might never translate a line. Their work still met on the same screen. News sites brought them together, too: someone looking for a new SNES build could discover a translation patch, while someone looking for the patch could learn why a particular emulator’s behavior mattered.
Meanwhile, new games kept moving the target. Nintendo 64 owners could buy Diddy Kong Racing in 1997, and its image in Retro Replay’s GameBase puts a familiar game beside the ambitions of the early N64 projects. Their authors were trying to reproduce hardware with a growing library that people were still buying and discussing. Sharing a release year with the game did not mean any emulator covered here could run it well. There was a considerable gap between choosing that target and reaching it.
What the race cost
For an emulator author, releasing a build could bring more bug reports than one person could answer. Users wanted their favorite games to work, sometimes without first reading the documentation. Other programmers watched for techniques they could adapt, and news pages rewarded speed and novelty. An unfinished build could be hailed as the best emulator overnight, then dismissed as abandoned after a few quiet weeks. The October Snes9x messages showed how exhausting that pace had become.
Behind the public arguments were practical pressures: limited documentation, private code, overlapping projects, legal uncertainty, volunteer labor, and a fast-growing audience. Calling the scene immature does little to explain how its authors were supposed to manage all that. Much of the negotiation happened in public, through email, IRC, release notes, and hand-built sites. Those exchanges left a rich record of the work, but also of people hurting one another while trying to keep it going.
Help extended beyond the code, too: a former network member gave Archaic Ruins a new home. The sites carrying releases and arguments depended on the same community they covered.
An unfinished ending to a crowded year
By New Year’s Eve, there was still no universal emulator, and the scene’s ethical arguments remained unsettled. MAME had established a model for arcade preservation, though specialist programs could still do work it could not yet handle. NESticle had made NES emulation feel immediate without stopping other authors from exploring different designs. The public argument had briefly made Snes9x look finished, but it and ZSNES were both still alive. Farther out, PSEmu and Project UnReality had made current consoles imaginable as targets, with plenty left to solve. PC Engine and Game Boy authors continued working through their own hardware problems, often away from the biggest headlines.
Players ended 1997 able to see old and new games running on their PCs, sometimes beautifully and sometimes badly. The authors were learning in public, with trust breaking and being rebuilt alongside the software. No single winner could neatly close out a year like that. Ahead in 1998 were larger audiences, more commercial attention, and tougher technical goals. Many of the promises—and arguments—of 1997 were coming with them.
People in this chapter
- Gary Henderson — Snes96 and Snes9x programmer whose sound and compatibility work shaped the SNES race.
- zsKnight and _Demo_ — the founding ZSNES programmers, whose October release pushed speed and ambition.
- Marcin Dudar (Duddie) — early PlayStation emulator author who described the difficulty of reverse engineering in a 1997 interview.
- Steve Snake — KGen programmer in the Genesis field.
- David Michel — Magic Engine programmer and collaborator in the wider 1997 emulator network.
- Michael Tedder (Breakpoint) — Project UnReality programmer at the leading edge of Nintendo 64 emulation.
- John Saeger — creator of z26, the Atari 2600 emulator whose first release arrived in August 1997.
Sources and further reading
- ZSNES’s official release history for October–December versions, features, and contemporaneous technical credits.
- The End of SNES ‘9x and The Snes9x Past, two contemporary interpretations of the October dispute. Accusations are attributed; neither page alone establishes source-code theft.
- Interview with Duddie, conducted by Chris Hickman in October 1997.
- StormWorld’s November 1997 news archive, recording SNEmul’s November 3 alpha and Project UnReality’s November 29 debut.
- z26 project repository, which records the August 28, 1997 first release.
- Archaic Ruins article index for dated 1997 pieces on emulation, sites, and community arguments.
- System 16 Emulator project page and MAME project history for the parallel arcade story.
Part of: The Complete History of Video Game Emulation
People introduced in this chapter: Gary Henderson, zsKnight, _Demo_, Marcin Dudar (Duddie), Steve Snake, David Michel, Michael Tedder (Breakpoint), John Saeger
Browse biographies: People in the History of Video Game Emulation
Retro Replay Retro Gaming History, Reviews & Emulation