Retro Replay Retro Gaming History, Reviews & Emulation
Haruhisa Udagawa could get a small group of Famicom games running on a Fujitsu FM TOWNS computer in 1990. Getting them to behave properly was another job. His Family Computer Emulator interpreted dumped game software, but it was slow, lacked proper sound and could not yet reproduce many of the console’s hardware behaviors. In 1991, he kept working on it. Meanwhile, inside Sega, Yuji Naka tried running Famicom software on a rather less likely machine: the Mega Drive.
Udagawa’s work reached a later version, v0.45, associated with Fujitsu’s Freeware Collection 3. That gave his early emulator a place in the FM TOWNS software library and a route to survival. Naka’s experiment remained private. No code has surfaced publicly, and the account rests primarily on his own confirmation years later that he had written a Famicom emulator for Sega’s Mega Drive.
The two projects left very different trails. Udagawa’s emulator ran on an expensive Japanese multimedia computer and survives as freeware, with files and documentation to examine. Naka’s ran on a rival game console and appears never to have left Sega’s internal world. Both attempted the same basic feat: reconstruct enough of Nintendo’s hardware behavior for its games to run somewhere else.
Family Computer Emulator Did Not End in 1990
The v0.35 build examined in the previous chapter ran under MS-DOS on the FM TOWNS and took separately dumped program and character ROM data as its input. Udagawa’s documentation laid out the obstacles: no useful bank-switching support, restricted scrolling, incomplete graphics behavior, poor speed and no proper sound. That December 1990 version could run only a small group of early Famicom games, but it was not the end of the project.
A later v0.45 survived into 1991. Modern research identifies it as the last known version, with many restrictions still in place. Sprites and backgrounds still had a fixed drawing priority, limiting what could appear in front of what. Vertical scrolling remained the practical focus, ROM size was tightly constrained, colors were not fully accurate and sound reproduction was incomplete. Udagawa had improved the emulator, but it was still a long way from the general-purpose NES emulators that would become familiar later in the decade.
Getting the processor’s instructions to run was only the beginning. A game also depended on its cartridge electronics, the PPU that handled the picture, sprite priority, scrolling, audio and timing. An emulator could understand a 6502-derived instruction stream and still stumble over the behavior the game expected around it. Family Computer Emulator’s limits show how much work remained beyond that first running game.
V0.45 left a lasting trace through Fujitsu’s Freeware Collection 3. RetroReversing’s NES-emulation history documents the later build, its remaining limitations and its appearance on the collection. Modern MAME software lists independently catalog Freeware Collection 3 as a 1991 Fujitsu FM TOWNS CD-ROM release.
A CD-ROM helps the experiment survive
Landing on that compilation gave Udagawa’s emulator a better chance of surviving. Early programs could disappear with a failed hard drive, a degraded floppy or a vanished bulletin-board archive. Expensive, regional or short-lived machines made their software harder to keep, and small utilities were easy to discard once they stopped being useful. Copies on shareware CDs, magazine disks, FTP mirrors and bulletin boards could outlast the developer’s own copy. For Family Computer Emulator, the FM TOWNS compilation provided a way back to its original software environment decades later.
Meanwhile at Sega, Yuji Naka Was Trying Something Stranger
Naka’s experiment had no comparable public distribution trail. It ran on Sega’s Mega Drive—the 16-bit console sold as the Genesis in North America—and came from one of Sega’s most technically accomplished young developers. Nintendo software running on a Sega console was an unusual prospect even before anyone asked how well it worked.
Yuji Naka was one of Sega’s most prominent programmers during the rise of the Mega Drive. In the same era that his low-level programming helped define Sonic the Hedgehog, Naka privately experimented with making Sega’s console run Famicom software. Years later he personally confirmed the emulator and said that it could run games such as Dr. Mario, although imperfectly.
Naka was known for working close to the hardware, using assembly-language programming to extract performance from it. By 1991, he was the lead programmer on Sonic the Hedgehog, one of the games that transformed Sega’s position in the console market. Sega’s modern Sonic Origins documentation dates the first release to June 23, 1991 in the United States and Europe, followed by July 26 in Japan.
In a later interview with The Next Level, Naka confirmed that he had programmed a Famicom emulator for the Mega Drive primarily for study and amusement. He remembered Dr. Mario running, though it did not work perfectly. His recollection is the strongest surviving evidence for the private experiment.
An experiment without a confirmed name
Older emulator histories, including the archive that became the foundation of Retro Replay, commonly call the experiment “Famicom For Mega Drive.” It is a handy description of what Naka built, but there is no good evidence that he gave it that name. In the surviving interview, he simply calls it a Famicom emulator for the Mega Drive.
There may never have been a public release to name. No executable, source code or release documentation—such as a box, manual or version history—has surfaced publicly. For now, Yuji Naka’s private Famicom emulator for the Mega Drive describes the project without giving it the trappings of a finished product.
The date comes from later accounts
The experiment is traditionally dated to 1991. Early emulation histories and later retrospective accounts repeatedly place it in that year, which fits Naka’s deep involvement with the Mega Drive at the time.
Naka’s interview confirms that he built the emulator, but does not say precisely when. No dated 1991 build survives publicly, so the year remains a plausible historical attribution rather than a verified development date.
One Confirmed Game: Dr. Mario
Dr. Mario gives the experiment something concrete to work with. Naka recalled that it ran games “like Dr. Mario,” with imperfect results. He had gone beyond getting a few Nintendo instructions to execute: a commercial Famicom game was making progress on Sega’s console.
That meant recreating or translating enough of the Famicom’s behavior to support meaningful portions of a game with a functioning game loop, graphics, controls and sound expectations. Drawing a Nintendo-looking screen would have been much easier. Getting the program behind that screen to keep running was the challenge.
Later retellings sometimes mention Mario more generally or suggest that numerous Famicom games were playable. Naka supplied no systematic compatibility list, and his account described imperfect results. Dr. Mario is the named example we have; without the code, broad compatibility remains speculation.
The Mega Drive Was Not Simply a Faster Famicom
Why was this difficult? The Mega Drive was a newer, 16-bit machine facing an older, 8-bit console, but extra power did not give it the ability to understand a Famicom cartridge. Before a game could respond to a button press or draw its next frame, the emulator had to bridge two different hardware designs.
The Famicom and NTSC NES use a Ricoh processor with a 6502-derived CPU core. Modern NES technical documentation puts the NTSC CPU at approximately 1.79 MHz and describes how the 2A03 combines that core with audio, controller and DMA functions. The Mega Drive instead has a Motorola 68000-family main processor, a separate Z80 used primarily for sound, Sega’s own video-display hardware and a different memory architecture. A clock-speed comparison leaves most of that work out.
Sega’s Genesis Software Development Manual Version 2.0, dated July 1991, spends substantial space explaining how the 68000, Z80, video display processor (VDP), interrupts, controllers and console bus work together. Alongside it, NESdev’s CPU documentation shows Nintendo’s quite different processor and timing model. Naka’s program had to make software written for one arrangement operate within the other.
A Famicom game could not run natively on the Mega Drive. The 68000 did not understand 6502-family instructions, and Sega’s VDP did not behave like Nintendo’s picture processing unit, or PPU. Memory addresses meant different things; controller input arrived differently; the sound hardware was unrelated. Some cartridges added mapping schemes with further hardware behavior to reproduce. The emulator needed a way across each mismatch the game encountered.
How he made it work remains a mystery
One approach would have been to interpret the Famicom’s CPU instructions as the game ran. Another would have been to translate blocks or routines into code the Mega Drive’s 68000 could execute. Naka might have combined those methods, or reproduced only the hardware behavior his test games needed. Without the executable, source code or a technical explanation from him, we cannot choose among them.
Sound presents another unanswered question. The Mega Drive had a Z80 processor, but it could not simply stand in for the Famicom’s CPU. Nintendo’s 2A03 is derived from the 6502 and is not Z80-compatible. Its integrated audio processing also works very differently from Sega’s YM2612 and PSG-based sound hardware. Naka may have used the Z80 somewhere in his emulator; its presence alone tells us nothing about how well the game sounded.
The console becomes the host
Udagawa’s FM TOWNS work had already shown that a capable general-purpose computer could reproduce part of a console. Naka tried something stranger: making another closed game machine do the job.
Running an emulator on a console feels almost routine now. Emulators would eventually turn up on Dreamcast, Xbox, PlayStation Portable, Nintendo DS, Wii, smartphones, handheld PCs and nearly every programmable device powerful enough to run them. In 1991, using a console as the host was still an unusual proposition.
The Mega Drive was built to boot Sega-compatible cartridges and run software written for its own architecture. Reproducing Nintendo’s system was not part of the brief. Yet Naka’s account describes repurposing that hardware to run Famicom software. No public release is known, but the experiment explored a possibility that later homebrew and emulator communities would pursue: a console could host an emulator for another console.
The Irony of Nintendo Software Running on Sega Hardware
There was a pleasing irony in the choice of machines. In 1991, the Mega Drive/Genesis was becoming the foundation of Sega’s direct global challenge to Nintendo’s console dominance. Sonic the Hedgehog gave Sega a mascot built around speed, technical spectacle and an attitude deliberately different from Nintendo’s image. Meanwhile, Nintendo software had found a private route onto Sega hardware.
That might sound like the beginning of a corporate espionage story, but there is no good evidence that Sega commissioned the emulator as a commercial weapon, planned to offer Nintendo compatibility or intended to use it against Nintendo. The personal experiment Naka described does not need that extra drama.
Naka’s description of the emulator as a study project makes sense in technical terms. Reproducing an unfamiliar machine is a demanding way to learn it. Every instruction needs a meaning. Memory must behave correctly, interrupts must arrive at the right time, and graphics must be composed as the game expects. Then come the undocumented assumptions that real games rely on. Building an emulator could teach a programmer far more about the Famicom than simply playing its games.
1991 Was Also a Year of Expanding Cartridge Ecosystems
The target was getting harder to reproduce, too. The Famicom and NES libraries had grown well beyond the simple fixed-ROM cartridges that were easiest to emulate. Extra hardware in cartridges, known as mappers, expanded program and graphics size, changed memory behavior and added scrolling options. Sega’s cartridge library was also growing quickly around a very different architecture. An emulator intended to run a wide range of games would have to understand the console and the cartridge hardware that modified or extended it.
That helps explain why early emulators often concentrated on a handful of known games. A developer could reproduce the behavior those cartridges needed long before building a machine model accurate enough for hundreds of titles. One working game did not guarantee that the next cartridge would cooperate. Naka made no claim to have recreated every Famicom game, and the gap between getting a game to run and emulating a console broadly would remain a challenge throughout the decade.
Nintendo Was Already Fighting Over Control of What Its Hardware Could Do
In 1991, Nintendo was fighting Lewis Galoob Toys over a device players could actually buy. The Game Genie sat between an NES cartridge and the console, temporarily altering values sent to the CPU. It had nothing directly to do with emulation, but the dispute over what players could do with their games foreshadowed legal and philosophical arguments that emulators would later encounter.
The Game Genie still needed a real NES and a real cartridge. It changed how a game behaved; it did not recreate Nintendo’s hardware on another machine. But the dispute put a related question before a court: how much control did a copyright owner retain over the way someone played software they had bought?
On July 12, 1991, the U.S. District Court for the Northern District of California ruled that consumers making temporary changes to games with the Game Genie did not create an infringing derivative work. As an alternative basis for its decision, the court concluded that the personal use at issue would qualify as fair use. That ruling concerned temporary game modification, not the legality of emulators.
The case, Lewis Galoob Toys, Inc. v. Nintendo of America, Inc., belongs in the background of emulation’s history. Before public console emulation became widespread, Nintendo was already confronting devices that let consumers and third parties make its games behave in ways it had neither designed nor authorized.
A New Generation Was Arriving Before the Old One Had Been Understood
Meanwhile, programmers were trying to reproduce the Famicom as the console industry moved beyond it. Nintendo’s Super Famicom had launched in Japan at the end of 1990, bringing more complex hardware into living rooms. Sega’s Mega Drive was already showing what the 16-bit generation could do. The older machines had barely become emulation targets before programmers had another generation to puzzle over.
That chase would continue for years. By the time one generation became practical to reproduce, developers were already studying the next. The NES/Famicom’s 6502-derived processor architecture and tile-based graphics would eventually become well understood. The Super Famicom brought more sophisticated graphics modes, audio hardware, cartridge enhancement chips and timing behavior to work out. Sega’s hardware evolved too, while arcade boards raced ahead even faster.
Faster personal computers and accumulating documentation would dramatically narrow the gap between commercial hardware and enthusiasts’ ability to reproduce it. In 1991, though, getting even one game to run imperfectly on the wrong console was still a striking achievement.
Nobody else could download it
Naka’s experiment gave Mega Drive hardware an unexpected job, but almost nobody could try it. That left other programmers with little to build on.
No public binary or source archive is known. Mega Drive owners did not get a Famicom emulator on a magazine cover disk, and no BBS community formed around compatibility reports. There was no standardized ROM set circulating alongside it either. The experiment remained inside a private programming environment, out of reach of people who might have tested it or taken it further.
Udagawa’s project, limited as it was, could circulate. People could copy it, test it, discuss it and potentially modify it. Availability, documentation, source code and file formats all helped determine whether a project could support a community. An earlier breakthrough could remain a private curiosity while a later, accessible program gave other developers somewhere to start.
By the end of 1991, these two Famicom projects offered very different ways into emulation. Haruhisa Udagawa had a documented FM TOWNS program that circulated as freeware. It survives well enough for modern researchers to run it inside an FM TOWNS emulator—a second layer of emulation that lets them study the first program’s shortcomings directly.
Neither project had the support network that would later grow on the Internet: public repositories with nightly builds, collaborative compatibility databases, or thousands of users reporting bugs. Yet both involved work that would become familiar to emulator developers—low-level hardware research, ROM-based software, cross-platform execution and reverse engineering. Each tried to make one machine do another’s job.
Other basic details remain missing: a confirmed contemporary title, a version number and a dated screenshot. Cartridge mapper support is unknown too, as is whether Naka worked entirely on Sega development hardware or used supporting tools elsewhere.
Why the Missing Code Matters
A surviving copy of Naka’s emulator would let researchers move from his recollection to the machine itself. They could test which games ran and compare them with later accounts. Source code could show whether he interpreted Famicom instructions, translated them or combined techniques, and how he used the Mega Drive’s VDP to approximate Famicom graphics. Controller inputs, memory layout, cartridge assumptions and timing would all be open to inspection—the details that could explain why a game worked, or nearly worked.
The code could also show how a leading commercial programmer tackled these problems before there was an established emulator-development culture to draw on. Modern authors inherit decades of techniques, documentation, test ROMs and hardware research. Naka had far fewer shared resources. Private prototypes can leave a gap in game history when their development files are lost or remain inaccessible.
IBM had used computers to emulate computers; home computers had emulated other home computers. Udagawa had made a powerful multimedia PC run Famicom software. Naka’s account added another kind of host to that history: a game console.
A console is a programmable computer, even with its specialized hardware and restrictions. Give programmers enough control and they can try to run software its manufacturer never intended. That possibility would later underpin homebrew scenes, console ports of arcade emulators, handheld emulator collections and retro-gaming ecosystems built on repurposed hardware.
Few programs, very different paths
At the end of 1991, anyone hoping to try console emulation had few options. Family Computer Emulator still faced severe technical limitations, and Naka’s Mega Drive project was unavailable to consumers. There was no mainstream scene or broadly distributed, all-purpose Famicom emulator. The standards and communities that would eventually make these programs accessible had yet to form, though console emulation was no longer confined to a single experiment.
Next: an Amiga file with a misleading reputation
In 1992, the trail leads to an Amiga archive with a promising name: Gameboy68000. Its reputation would eventually run far ahead of what the surviving program could do. The next chapter follows that mix-up back toward the Game Boy development experiments behind the story.
Part of: The Complete History of Video Game Emulation
Person introduced in this chapter: Yuji Naka
Continuing figure: Haruhisa Udagawa
Browse biographies: People in the History of Video Game Emulation
Sources and Further Reading
- The Next Level — Yuji Naka interview confirming his Famicom emulator for Mega Drive
- RetroReversing — The History of NES Emulation
- MAME MiniMaws — Fujitsu FM TOWNS CD-ROM software list, including Freeware Collection 3
- SEGA — Genesis Software Development Manual, Version 2.0, July 1991
- NESdev Wiki — NES/Famicom CPU architecture and timing
- SEGA — Sonic Origins manual and original Sonic the Hedgehog release dates
- Lewis Galoob Toys, Inc. v. Nintendo of America, Inc., 780 F. Supp. 1283 (N.D. Cal. 1991)