Retro Replay Retro Gaming History, Reviews & Emulation
The title screen appeared. That was encouraging. Then the scrolling broke, the sound disappeared, or the game refused to go any further. Getting a Nintendo game onto a computer screen in 1996 could feel like a small miracle. Getting through a level was another matter.
Sometimes the trouble started before the game loaded. The emulator wanted several files, the files had the wrong extensions, and the instructions assumed you already knew what to rename. There was plenty to do before pressing Start.
The 1995 chapter followed emulation into commercial products and a growing Internet audience. In 1996, Nintendo fans began getting more choices: Pasofami, iNES, small DOS experiments, and competing attempts at the Super Nintendo. Each promised something the others had yet to deliver.
One of those attempts, Jerremy Koot’s Snes96, would help lead to Snes9x. None of the programmers could see the whole future from here. They had games to make work, machines that struggled to keep up, and users waiting for the next download.
The surprise inside the cartridge
An NES cartridge looked reassuringly simple from the outside. Put it in the console, turn on the power, and play. An emulator author had to deal with what was under the plastic.
The console’s processor and graphics hardware were only part of the job. Many cartridges carried extra circuitry that changed which portions of memory the game could access. Later games could demand behavior an early, smaller cartridge never needed.
Players came to know these arrangements as mappers. An emulator could run the processor’s instructions and still scramble a game because it handled the cartridge incorrectly. Supporting another mapper could suddenly open up a whole group of games.
That made a successful demonstration wonderfully deceptive. One little cartridge might run beautifully. The next could expose a piece of Nintendo hardware the programmer had barely started to understand.
Before playing, assemble the files
Nobuaki Andou already had Pasofami in circulation when this new competition arrived. Following his project meant following an emulator that kept changing, along with a workflow that could test a newcomer’s patience.
A cartridge image might come as separate program, character, and parameter files. Leave one behind or misunderstand the setup, and there might be no game to judge. Japanese documentation and registration added another obstacle for readers who could not understand them.
Those surviving instructions capture a chore modern users seldom encounter: keeping the right pieces together and telling the emulator what they represented. The familiar game was waiting somewhere behind the housekeeping.
Andou kept revising the program. Archaic Ruins lists Pasofami 2.6b in July and 2.8a in October 1996. NES WORLD’s earlier coverage shows users already comparing it with alternatives. Pasofami had helped get them here; now it had to give them reasons to stay.
A tiny Mario picture was enough
A screenshot could sell the whole idea in seconds. There was Mario, or Popeye, recognizable even in a small image on a homemade webpage. Someone had persuaded a computer to show a game you knew from a Nintendo console.
NES WORLD’s preserved May 1996 page carries that excitement alongside the practical frustrations. The images gave visitors a reason to try. The surrounding notes explained what trying would involve.
A promising screenshot and a list of shortcomings could sit on the same page without cancelling each other out. For an early user, the possibility was often enough to justify another download.
The programmers who almost disappeared
M. Kami appears in the May 1996 record with emulators for both the Famicom and Super Famicom. The surviving name is brief and the personal record is thin, but the software places Kami among the independent programmers expanding Nintendo emulation beyond its earliest pioneers. Kami’s story survives chiefly through contemporary listings and archived programs.
In May, NES WORLD announced two emulators associated with M. Kami: one for the Famicom and another for the Super Famicom. Its SNES list placed Super Famicom Emulator v1.01 for DOS beside Super Pasofami and VSMC ’96.
Kami’s programs leave a clearer trail than Kami’s personal story. Later Archaic Ruins material identifies a DirectX Famicom emulator using PRG/CHR files. Other listings use generic names that make it easy to confuse one author’s work with another’s.
These small projects belong in the story even when their authors remain elusive. The field was filling up with independent attempts. The names that became famous had no guarantee of outlasting the rest.
LandyNES: a rough start with a long shadow
Alex Krasivsky wrote LandyNES and the initial code behind the project that became iNES. Marat Fayzullin credits him with finding Famicom programming information and starting the work before Fayzullin rewrote and expanded it. Krasivsky connects one of the scene’s short-lived experiments to one of its most enduring emulator and file-format lineages.
Alex Krasivsky left two connected trails: LandyNES, a short-lived emulator of his own, and the initial work that became iNES. One survives as a rough experiment. The other led much further.
Archaic Ruins records a September 8, 1996 prerelease of LandyNES under the unflattering label “Stupid” version. It expected ROM and VID files and handled only a limited range of cartridge hardware. The archive’s assessment was blunt, but the surviving program shows what Krasivsky had managed to get running.
Donkey Kong made a sensible early target. A small cartridge gave the author a more contained problem than a later game full of bank-switching demands. Seeing it run was progress, even if the rest of the library remained out of reach.
LandyNES did not become the emulator people kept using for decades. Krasivsky’s lasting place in the story comes through the work he started and another programmer took over.
Marat Fayzullin takes the work further
Marat Fayzullin had already appeared in the 1992 chapter, then pursued fMSX and Virtual GameBoy. Nintendo’s older console became another target for his portable approach to emulation.
In his own account, Krasivsky found Famicom programming information online and wrote the initial code. Fayzullin later rewrote and expanded it. Period coverage described their contributions somewhat differently, but both accounts leave Krasivsky at the beginning of the effort.
The resulting iNES appeared in 1996, sometimes called interNES in contemporary coverage. Fayzullin wanted the console’s underlying model to travel between computers, with the display and controls adapted for each host.
Archaic Ruins records a Windows 0.5 build dated September 9. That gives us one dated release, rather than a birthday for every version of the project. iNES was already growing beyond a single machine and a single build.
Which emulator gets your favorite game right?
NES WORLD’s comparison gets straight to the player’s dilemma. Pasofami had colors and sound its author preferred. iNES handled more demanding games, but the version being reviewed had its own color and sound shortcomings.
Your favorite cartridge could decide the argument for you. So could registration, the effort of preparing files, or the prospect of playing in silence. There was no reason for every user to choose the same program.
That competition raised expectations. Once another emulator could handle a game, failure stopped looking inevitable. Users had something to compare, and programmers had something specific to chase.
The later iNES captures here show further development. The choice that drove it was already familiar in 1996: try this release, test the game that failed last time, and see whether anything changed.
One file, fewer chores
One of iNES’s most durable changes happened before a game reached the screen. It put cartridge information and game data together in a single file, with the now-familiar .nes extension.
A 16-byte header told the emulator how to approach the contents: the sizes of program and character data, the mapper, and details including mirroring, battery-backed memory, and an optional trainer. The bytes came with a small set of instructions for interpreting them.
Fayzullin’s NES architecture documentation identifies iNES as the format’s first implementation. For users, its attraction was easier to explain: one file was less troublesome to copy and organize than several companions that had to stay together.
Bad dumps and ambiguous hardware details could still cause trouble. A common container at least spared users and authors from starting the packaging argument over with every emulator.
The mapper number also gave developers a shorthand. It identified a hardware arrangement the emulator needed to reproduce. Files of similar size could require very different behavior once the game began running.
The Unix/X captures show how those conventions could travel with the software. The window system changed; the cartridge’s demands did not. A portable emulator and a shared format made it easier for people on different computers to work with the same material.
Older formats did not vanish because iNES offered a tidier one. Users still met PRG/CHR files, ROM/VID pairs, and configuration files. NES WORLD explained how Damaged Cybernetics’ NesImage utility could join or split the data, with extensions renamed along the way.
A conversion tool could be the difference between staring at a directory and starting a game. The scene needed this less glamorous work as much as it needed another impressive screenshot.
Paul Robson tries the lean approach
Paul Robson created NESA, a compact NES emulator for DOS written in assembly language. His work represents another route through the same difficult hardware: use a small, machine-specific implementation to make emulation practical on contemporary PCs. Surviving NESA releases preserve his authorship and his place in the expanding 1996 field.
Paul Robson took a different route with NESA, a compact DOS emulator written in assembly language. A PC that could barely keep up offered a powerful reason to make the program small and closely tuned to its processor.
The preserved 0.11 beta identifies Robson, carries a 1996 copyright, and acknowledges Fayzullin. Even this little DOS project shows the exchange of ideas behind apparently separate programs.
Archaic Ruins later emphasized NESA 0.17’s tiny size and assembly implementation. Fayzullin’s portable approach could reach more kinds of computers; Robson’s approach could work closely with a particular one. Neither advantage meant much if the game itself failed.
The SNES was a much less forgiving opponent
On the Super Nintendo, a recognizable screen could conceal a lot more unfinished work. Backgrounds might stack in the wrong order. Color effects could disappear. An introduction could start and then freeze.
The main processor, graphics units, DMA transfers, and separate audio system all had to cooperate. Some cartridges added still more hardware. Reproducing one piece convincingly left plenty of ways for the others to go wrong.
Meanwhile, Nintendo’s library was still growing. Super Mario RPG: Legend of the Seven Stars arrived in 1996, putting Mario into Square’s isometric adventure. Console owners had a new game to explore. Emulator authors had a target that refused to stand still.
VSMC had a head start
Chris George, known as The Brain, had already brought Virtual Super Magicom into public circulation. The 1994 chapter followed that early step; a September 1, 1994 prerelease of version 0.70 survives. By May 1996, NES WORLD was listing VSMC ’96 among a growing set of SNES attempts.
Its name connected it to the Super Magicom cartridge copier. The physical device put cartridge data onto disks. George’s virtual counterpart tried to supply the console that would run it.
That earlier start did not make the remaining work gentle. A fast processor core still needed graphics, transfers, interrupts, and timing to cooperate. The later 97.02(D) screens here show where VSMC went next, rather than everything the 1996 version could do.
Andou follows Nintendo into sixteen bits
Super Pasofami gave people who knew Andou’s NES work another project to follow. NES WORLD listed version 1.2a; Archaic Ruins records 1.3a from June and 1.7a from August 1996. He was revising the program through the year.
The Super Bomberman images explain the temptation. Familiar characters were there on a computer screen. For someone watching early SNES emulation develop, that was an appealing reason to investigate.
Settings and instructions supplied the less photogenic side of the experience. A convincing picture could not tell a user whether the sound worked, how fast the game ran, or whether the session would survive the next few minutes.
A warning nobody wanted to read
The 1993 chapter left a troubling part of Andou’s story for this year: Archaic Ruins warned that Super Pasofami 1.7a could corrupt a user’s Windows directory. The catalog dates that version to August 1996.
The warning survives; a full explanation of the reported damage does not. It records a serious problem associated with that release, without establishing that Andou intended harm.
For users picking up unfamiliar software from personal sites and mirrors, a version-specific warning could be more urgent than a compatibility improvement. Knowing where to find trustworthy information was becoming part of using an emulator.
Snes96 gives the next programmers somewhere to start
Jerremy Koot created Snes96 for Windows and later worked on Snes97 and Snes9x. Known in the scene as The Teacher, he enters the story while SNES emulation is still an unfinished experiment. His original Windows program became the starting point for further work by Gary Henderson, linking the projects of 1996 to a much longer history of portable SNES emulation.
Read the full Jerremy Koot biography →
Undated portrait identification from an archival profile; original photographer unverified.
Jerremy Koot’s Snes96 looked at home on a Windows desktop: a display area, a few menus, ordinary controls. Patent Pending preserves Win32 version 0.3.2 with an August 22, 1996 date.
The modest interface did not advertise the project’s future. Its more lasting contribution was code other programmers could carry forward.
In May 1997, Gary Henderson described his Linux work as a port and rewrite of Koot’s original Windows 95 emulator. That announcement connects the projects while also recording how much remained unfinished.
Snes97 and the eventual Snes9x collaboration lay ahead. In 1996, Koot had supplied something the next programmer could build on.
Henderson’s announcement names one especially stubborn obstacle: missing sound emulation was causing game failures. A silent game could be more than a game without music.
The SNES audio system had its own processor and memory. The main game expected to communicate with it. If a response never came, play could stop while a perfectly recognizable picture remained on screen. That 1997 report helps explain why sound had been such a substantial problem along the way.
The files had baggage too
Before the emulator could wrestle with Nintendo’s hardware, it might have to untangle the file. SNES cartridge copiers such as the Super Magicom and Super Wild Card had left their own conventions: headers, interleaved data, and pieces split for removable storage.
The first byte in a file was not always the first cartridge byte the emulator wanted. Loading could involve recognizing and rearranging the contents before the game’s instructions began.
These collections and formats had a history before mature SNES emulation. The programmers inherited that history along with the console. Their software had to accommodate what people already possessed.
Duck Hunt looked ready. The gun was another matter
NES WORLD showed Duck Hunt while describing trouble with its light-gun requirements. The ducks could appear without the player having the means to deal with them. It was an unusually clear example of a picture promising more than the software delivered.
A later Archaic Ruins SNES overview described Chrono Trigger beginning and then failing during its introduction. That page includes 1997 releases, so it belongs to the continuing story rather than a precise report on a particular 1996 build.
Getting beyond these failures took more than screenshots. Version notes and reports from people who had actually tried to play could expose the trouble hiding beyond the captured frame.
A file dialog could be a breakthrough too
Someone arriving because they recognized Mario might have little appetite for a command line. Windows offered menus and file-selection dialogs that made the first steps more familiar. Snes96 and Windows builds of iNES brought emulation onto that desktop.
DOS still offered authors a direct route to the PC’s hardware. Speed mattered desperately when a machine struggled to keep up. Windows made convenience another thing users could compare, even when a friendlier interface left the console’s bugs untouched.
The same practical choices ran through the code. Portable C helped Fayzullin move an emulator between hosts. Robson’s assembly tied NESA more closely to its machine. A user with a Unix workstation and a user with a slow PC had different reasons to care.
Authors could mix approaches, too. Henderson’s later Snes96 announcement describes C++ with an assembly CPU core for Linux and DOS ports. They used the tools that helped get the game moving.
A failed game could teach its author something
Krasivsky’s discovery of Famicom programming information helped start the work behind iNES. A document could turn an ambitious idea into something a programmer could attempt. It could also leave questions the games themselves would expose.
A broken scene might mean a coding mistake, or it might mean the author had misunderstood Nintendo’s hardware. Sorting that out required testing the explanation as well as the program.
Users widened that testing effort. They tried cartridges the author had not tried, reached later stages, and found failures that looked similar across several games. Those patterns could point toward a mapper, graphics behavior, or communication with the audio system.
Useful reports needed specifics: the version, the game, its files, and the action that made it fail. Another emulator running the same scene gave everyone an extra clue. Frustration could become something a programmer could work with.
The next download had something to prove
By the end of 1996, a Nintendo fan had more programs to watch and more reasons to try them. Pasofami kept changing. iNES offered broader ambitions and a file format that would last. NESA pursued small, fast code. On the SNES, VSMC, Super Pasofami, and Snes96 were tackling a machine that could fail in spectacularly unhelpful ways.
The excitement of seeing a familiar title screen had not worn off. But people increasingly wanted to know what happened after it: whether controls worked, whether the game kept moving, whether the music played, and whether their favorite cartridge survived beyond the introduction.
The next release might fix exactly the thing that had ruined the last attempt. That was enough to bring people back.
Next: finding the people who knew which version worked
Keeping up brought another set of chores. A version appeared on a personal homepage. A link vanished. Someone knew a conversion trick, or had translated the instructions, or had discovered that one release was best avoided.
The sites collecting those discoveries became places worth returning to. They helped users find the software and make sense of it once it arrived.
1996 Part II follows NES WORLD, Archaic Ruins, Damaged Cybernetics, IRC, and the arrival of Zophar’s Domain. The programmers had given people something to try. The people gathering online would help them keep trying.
Part of: The Complete History of Video Game Emulation
People introduced in this chapter: M. Kami • Alex Krasivsky • Paul Robson • Jerremy Koot
Returning figures: Nobuaki Andou • Marat Fayzullin • Chris George (The Brain)
Browse biographies: People in the History of Video Game Emulation
Sources and Further Reading
- NES WORLD: early Pasofami and iNES comparison and file-conversion instructions.
- NES WORLD: May 1996 emulator listings and game-image gallery.
- Marat Fayzullin: official iNES project history and documentation.
- Marat Fayzullin: NES architecture and cartridge-file format.
- Archaic Ruins / Damaged Cybernetics: preserved NES emulator catalog. This page includes 1997 material as well as 1996 release records.
- Archaic Ruins / Damaged Cybernetics: preserved SNES emulator catalog. Its overview is a later snapshot, not a contemporaneous report of every 1996 build.
- Patent Pending: preserved SNES releases, including Snes96 0.3.2.
- Gary Henderson: May 1997 Snes96 release announcement, documenting the original Windows lineage and continuing technical limitations.
- Marat Fayzullin: personal homepage and portrait.