1993: Pasofami, fMSX and the Birth of Portable Emulation

A Famicom cartridge was a tidy little object. The files needed to run it on a computer were less tidy. Pasofami asked users to keep program data, graphics data, and parameter files together; a game could be in pieces before they even tried to play it. In 1993, programmers were beginning to turn isolated experiments into software other people could use—and perhaps build on.

Pasofami began tackling that second challenge on the FM TOWNS. Its early package carries a date widely reported as May 1, 1993, and gave users a way to work with dumped Famicom cartridges split into program, graphics and parameter files. Meanwhile, Marat Fayzullin began developing fMSX. His MSX emulator took a different approach: write the emulation code in portable C so it could move between host computers, rather than remain tied to one machine.

The two projects left different trails. Pasofami’s preserved FM TOWNS package predates the public “debut” remembered on the developer’s later official site. For fMSX, Fayzullin’s documentation places the start of development in 1993 on Unix-based DEC Alpha workstations. Other programmers could see its source from the beginning, though its versioned public history becomes much clearer by 1995.

An emulator someone else could build on

The previous three years had shown that a programmer could study another machine closely enough to reproduce at least some of its behavior. Getting beyond a small experiment was harder. An emulator might run on only its developer’s workstation, understand a handful of games or depend on private tools nobody else knew how to use. Neither early Pasofami nor early fMSX should be mistaken for the polished emulators with broad game compatibility that players would encounter later in the 1990s. They were beginning to address the less spectacular work that let an emulator grow beyond its author.

That work started with the files. Users needed a consistent way to store a cartridge’s contents, and developers needed a way to describe differences in cartridge hardware. Code had to be organized so it could survive a change of host computer. Documentation needed to travel with the program, and copies had to remain available long enough for someone else to study them. File formats, version numbers, source distributions and bulletin-board copies were becoming part of the story alongside the emulation itself—and later recollections would not always line up neatly with the surviving files.

Pasofami Appears in the FM TOWNS Story

Pasofami’s early trail leads back to the FM TOWNS, where Udagawa’s Family Computer Emulator had demonstrated Famicom emulation years earlier. Fujitsu’s expensive Japanese multimedia computer offered an x86-family CPU, high-resolution graphics modes, CD-ROM support and a rich multimedia environment. It was a much more flexible host than the consoles programmers were trying to imitate, and a natural home for technically ambitious software.

A surviving package gives Pasofami’s FM TOWNS history something concrete to work from. Modern preservation-oriented histories report an information-file date of May 1, 1993. There are also surviving video demonstrations of an early build running inside an emulated FM TOWNS. The original distribution route and the full sequence of versions remain incompletely documented, but the early branch has left more than a name in a timeline.

Developer Nobuaki Andou gave a later date on his official Pasofami website: he wrote that Pasofami “debuted” in 1995 as a domestically produced Famicom emulator. The preserved FM TOWNS material appears to be an earlier branch or predecessor of the Windows-era product remembered on that site.

Nobuaki Andou Enters the Story

Person in the Story

Nobuaki Andou was the Japanese programmer behind Pasofami, a Famicom/NES emulator lineage that began on the FM TOWNS and later became a long-running Windows shareware project with ROM-dumping and cartridge-analysis tools. Pasofami’s split PRG/CHR/PRM image format became part of the early vocabulary of NES emulation and remained important enough for later utilities to support conversion to and from it.

Read the full Nobuaki Andou biography →

No verified photograph of Andou has surfaced in the sources used for this chapter, so Retro Replay is using its standard No Known Photo placeholder rather than inventing a face or attaching an unverified image to his name. That may seem like a small editorial choice, but the 1992 ToyBoy investigation demonstrated exactly why provenance matters. A biography system is only useful if the image attached to a person is trustworthy.

An early date, a thinner paper trail

Andou’s 1995 date may mark Pasofami becoming a formal Windows product, when its shareware identity, registration system and wider user base became more visible. The reported May 1, 1993 information-file date places the earlier FM TOWNS material in time, but does not establish when development began or how the package reached users. How the two stages were distributed and named—and how much of the earlier program carried into the later one—remains unclear.

The earlier FM TOWNS material gives us a glimpse of the work before that Windows product. Pasofami’s ideas grew out of a Japanese PC environment where developers had already been investigating Famicom emulation for years.

The Famicom Was More Than a CPU

Getting a Famicom game to run required more than copying its program ROM. By 1993, anyone attempting more than the simplest early cartridges faced a problem Udagawa had already exposed: part of the hardware an emulator needed to reproduce lived inside the cartridge. Different boards used mapper circuitry to switch banks of program or graphics data, control mirroring—the arrangement of background-screen memory—and provide extra RAM. Some added sound or timing behavior of their own. Reproducing the console under the television was only part of the job.

Once someone had copied the ROM chips, the emulator still needed to know which cartridge board it was supposed to imitate. Where would that information go?

PRG, CHR and PRM: Pasofami’s Split Image Format

Pasofami’s answer was to split a game image across several files. Later technical documentation and conversion utilities preserve the format’s basic layout. A .PRG file held the program ROM data. A .CHR file held character, or graphics, ROM data when the cartridge used CHR-ROM. A third file, .PRM, supplied the parameters the emulator needed to interpret the cartridge correctly.

For the user, this meant that one game could arrive as several files to keep together. Less convenient than a single ROM image, certainly, but the split followed the hardware: program and graphics data could live on separate chips, with the cartridge board determining how the console accessed them.

Later NES emulation overwhelmingly settled on the iNES format, which put PRG and CHR data in one file behind a compact header. Old iNES conversion documentation explains how to turn a Pasofami image into one: discard or interpret the PRM parameters, join the PRG and CHR data, then add the 16-byte iNES header. Modern tools such as uCON64 still understand Pasofami’s split format well enough to convert between it and iNES.

A file format can outlast the emulator that introduced it. Once hundreds or thousands of dumps use a particular layout, later software needs a way to read them, even if players have moved on from the original program. That work produces converters, documentation and import routines; people preserving the files learn to recognize them by extension and size. Pasofami’s format survived in the tools built to handle it.

Those shared conventions were still rough. Mapper descriptions evolved, and some early formats could not fully describe unusual cartridge boards. Dumping devices produced different headers. Region assumptions, trainers, disk images and homebrew added further complications. As emulation moved beyond private experiments, developers had to agree on how to describe the games their programs would load—not just how to imitate the machines that played them.

Pasofami Would Outgrow the FM TOWNS

Before Pasofami could run a cartridge’s game, someone had to get the data out of the cartridge. Long after its early FM TOWNS days, the project grew around that practical problem, becoming better known for its Windows emulator, shareware distribution and cartridge-dumping utilities. Andou’s official site described years of free updates and later offered hardware services for reading ROM data directly from cartridges. By 2013, the site claimed that the service had produced more than 20,000 dumping adapters. It also documents USB-connected ROM-dumping hardware and a broad range of cartridge adapters.

Pasofami brought dumping, image conversion and emulation into the same workflow: extract the cartridge’s data, put it into a usable format, then run it. Modern emulation communities often divide those jobs among separate programs and devices. Early projects frequently treated them together, since an emulator was little use to someone whose game was still locked inside a cartridge.

The Windows versions became shareware, with registration limits described in contemporary and retrospective accounts. Translation patches and cracks also circulated around the program. Most of that story belongs to later years, when NES emulation became a visible Internet subculture, but it helps explain how Pasofami stayed in the conversation after the FM TOWNS had faded as a mainstream computer platform.

The Windows warning comes later

One story from those later years has sometimes wandered back into 1993. It claims that Pasofami contained anti-cracking code capable of damaging or deleting a user’s Windows directory. Whatever the details of that account, it cannot describe the 1993 FM TOWNS build. The tale concerns Windows software from a later generation, and retellings have blurred the two.

Surviving emulator archives place Andou’s Super Famicom/SNES emulator, Super Pasofami, in 1996. Archaic Ruins catalogs Super Pasofami v1.3a on June 10, 1996 and v1.7a on August 6, and warns that later versions may corrupt the Windows directory. Community recollections attach the most extreme anti-crack behavior to this Windows-era line, though the precise implementation and affected versions remain unresolved. That controversy belongs with the 1995–1996 Windows era, separate from Pasofami’s earlier FM TOWNS work.

Meanwhile, Marat Fayzullin Started fMSX

While Pasofami developed ways to get Famicom games into an emulator, another project tackled the computer running the emulator itself. Could the same code move between very different machines without having to be rewritten for each one?

Person in the Story

Marat Fayzullin became one of the defining independent emulator programmers of the 1990s. In 1993 he began fMSX, a portable MSX emulator whose reusable C architecture and visible source code became the foundation for ports and derivative projects; the experience later fed directly into his work on Virtual GameBoy, iNES, MasterGear, ColEm and other emulators.

Read the full Marat Fayzullin biography →

Marat Fayzullin set out to do that with fMSX. On Fayzullin’s own fMSX page, he recalls that he started developing fMSX in 1993, when he knew of only two other MSX emulators, both restricted to DOS. He wanted a portable program from the outset. He began writing it on Unix-based DEC Alpha workstations, rather than DOS or Windows machines.

That goal shaped how the code had to fit together. An emulator built for one computer could mix its imitation of the original machine with whatever the host operating system expected. Moving between computers required a cleaner separation. The MSX side—the Z80 processor core, memory model, video emulation, sound behavior and machine state—needed to stay apart from the host-specific code that opened a window, read the keyboard and produced audio. Otherwise, changing computers meant untangling the emulator along with it.

Fayzullin’s route to the United States

Fayzullin’s early work is sometimes placed vaguely in Russia, where he had studied at Perm State University, and he later became strongly associated with Russian-speaking computing communities. His own résumé gives a more precise sequence: Perm State University from 1989 through 1991, then a bachelor’s program in computer science at the University of Maryland at College Park from 1993 through 1995, alongside consulting work in Columbia, Maryland during 1993–1994. It does not locate every line of fMSX code, but it places this period of his life in Maryland, rather than supporting the familiar account of a Russian university project. His account identifies DEC Alpha Unix systems as the original development environment.

Early emulation already crossed plenty of borders. Japanese PC communities, British development studios, American universities and European Amiga archives all contributed to the growing body of knowledge, as did programmers whose studies and working lives took them through more than one country. Fayzullin’s path was part of that international story.

Started in 1993, released later

Fayzullin’s official documentation puts the start of continuous fMSX development in 1993. A surviving Internet announcement dated October 18, 1995 announces fMSX 1.0 as a release, describing its portable MSX/MSX2/MSX2+ architecture and source distribution. The project’s beginning and that documented public release were two different events.

Why MSX Was an Ideal Test of Portable Emulation

MSX was a fitting machine for Fayzullin to take from one computer to another. Conceived in the early 1980s as a standardized home-computer architecture, it was built by Sony, Panasonic, Yamaha, Philips and other manufacturers. The computers could look different, but they shared a broad hardware specification and software environment.

The original MSX standard put a Z80-family processor at the center, with standardized graphics, sound, cartridge slots and memory organization around it. MSX2 and MSX2+ later expanded the hardware while keeping a recognizable family resemblance. Across Japan, parts of Europe, South America and the former Soviet Union, MSX accumulated an enormous library of games and applications.

The standard had let software travel between compatible physical computers. With fMSX, Fayzullin aimed to move the computer itself, recreated in software, onto machines that had never been MSX-compatible.

A working Z80 emulator alone would not get those games running correctly. fMSX also had to reproduce the MSX’s memory slots and banking, video hardware, keyboard and joystick behavior, cartridge mapping, sound chips and later hardware extensions. A game expected the whole machine to behave as it remembered, right down to how it found its data and responded to a button press.

The code was meant to travel

Fayzullin’s current documentation describes fMSX as portable C capable of running on any sufficiently fast 32-bit platform. Over its long life, the project reached Unix, Windows, Macintosh, MS-DOS, Amiga, Symbian, Android and many other environments. Those ports arrived over time, rather than all being available in 1993, but they show how far the original design could travel.

The trick was to keep the code describing the MSX separate from the code dealing with the computer running the emulator. A CPU core could stay in place while display drivers changed. The video model could survive a rewrite of keyboard input. Timing logic could be tested across platforms instead of remaining tied to one operating system. This approach became familiar in later open-source emulation, but it was a different ambition from the platform-specific programs that dominated the early experiments: Fayzullin wanted an emulated MSX he could carry to another host without starting over.

Source Visibility Changed the Shape of the Scene

Other programmers could look inside it, too. Fayzullin also states that he made fMSX source code available for others to see from the beginning. He retained copyright, required attribution, restricted commercial use and asked programmers to contact him about ports and changes. These were not the modern permissive or copyleft terms developers might expect today, but the code was there to read and learn from.

Running an emulator showed a user what it could do. Reading its source showed a programmer how its author thought the machine worked. The CPU’s instruction-dispatch loop, memory maps, video code and input abstractions laid out that understanding in detail. Others could compare behavior, spot mistakes, borrow ideas, write drivers for another platform or use the architecture to help build an emulator of their own.

Fayzullin notes that many later MSX emulators derived from fMSX code. Even when a descendant replaced or rewrote those components, the source had given its programmers somewhere to begin. A private experiment could disappear with its author’s copy; code that others could study and build on had a life beyond the original program.

That was especially useful when hardware documentation was incomplete, official specifications were unavailable and commercial console manufacturers had little interest in helping. Emulator source could serve as both a working program and a detailed account of how its author believed the hardware behaved. Another programmer could run that account, test it and challenge it.

Pasofami and fMSX Pointed in Different Directions

Pasofami and fMSX were tackling different parts of the same growing workload. Pasofami’s story followed the steps a user needed to get cartridge software running: dumped data, file formats, metadata and conversion, followed later by registration and physical cartridge-reading tools. fMSX concentrated on what developers needed to keep an emulator moving between computers: portable C, reusable cores, visible source and a clean separation from the host hardware.

Later, a player would download one ROM file, open it in an emulator and start playing without thinking about any of this. The file would hold both the game data and compact metadata describing its hardware. The emulator might share CPU and device cores across Windows, Linux and other systems. Getting to that ordinary-looking experience took conventions that were still being worked out.

1993 and the Beginning of Emulator Infrastructure

Only a few years earlier, getting the code to run elsewhere had been the challenge. In 1990, that meant Famicom code. In 1991, Naka’s experiment showed that even a rival game console could serve as the host. In 1992, ToyBoy and Argonaut exposed the differences between simulation, imagined hardware and genuine reverse engineering, while Aminet showed how networked archives could keep software available.

The surviving evidence became just as scattered. An executable might outlast its source; a source archive might lose its original announcement. A developer’s later website could give a debut date that differed from the timestamp in an early build. Sometimes a conversion utility preserved the workings of an obsolete file format better than the original manual.

Two beginnings worth following

The year’s two milestones were beginnings, not finished products: a preserved Pasofami FM TOWNS package reported with a May 1, 1993 information-file date, and fMSX development beginning in 1993 according to Fayzullin. Andou later identified 1995 as Pasofami’s debut; the surviving fMSX 1.0 announcement also comes from 1995.

The Road to 1994: The 16-Bit Wall Starts to Crack

The next machines would ask more of emulator developers. Most targets so far had been rooted in 8-bit architectures or relatively modest handheld hardware. By the mid-1990s, programmers were beginning to tackle the Super Famicom/Super Nintendo generation, with more complex graphics modes, richer sound and cartridge enhancement chips. Its games were built around capabilities well beyond those of the early Famicom.

Surviving histories identify VSMC — Virtual Super Magicom, attributed to Chris “The Brain” George of Damaged Cybernetics, as a public SNES-emulation milestone in 1994. Early versions could handle only a small selection of homebrew material, but even that limited reach showed that the 16-bit console era was becoming an emulation target.

These systems were still commercially relevant when their emulators began to surface. Developers were reproducing hardware that the games industry had not yet left behind, bringing the technical work into closer contact with legal and cultural questions. The formats and portable code taking shape in 1993 would help support that expansion. In 1994, they faced a tougher test.

Sources and Further Reading

• Marat Fayzullin — official fMSX page and project history
• Marat Fayzullin — fMSX documentation, portability and licensing
• Marat Fayzullin — résumé and 1993–1995 education/work chronology
• Nobuaki Andou — official Pasofami site
• Pasofami official notice — later retrospective identifying 1995 as the product’s debut
• Emulation General Wiki — preservation chronology reporting the May 1, 1993 FM TOWNS Pasofami date
• NESdev — technical recollection of the early Pasofami PRG/CHR/PRM format
• Historical iNES header documentation — Pasofami image conversion and PRM role
• uCON64 documentation — conversion to and from Pasofami image format
• Archaic Ruins — Super Pasofami 1996 release listings and Windows-directory warning
• SnesLab — VSMC and the 1994 beginning of public SNES emulation