1995: Virtual GameBoy, Commercial Emulation and the Internet Scene

In 1995, Activision put fifteen Atari 2600 games in a retail package and let a software emulator run them on contemporary computers. The company did not have to rewrite each game from scratch. It had to reproduce the machine those games expected to find—a small old console that could still give a much newer computer plenty of work to do.

Other programmers were finding ways to bring old games to new machines, too. At nearly the same time, Marat Fayzullin was applying the portable architecture and experience behind fMSX to Nintendo’s Game Boy. His new emulator, Virtual GameBoy, reached users through publicly distributed versions that could run commercial handheld games on computers radically different from Nintendo’s hardware. In Japan, Pasofami was becoming increasingly important to Famicom emulation. Sites such as NES WORLD were beginning to give these scattered projects an online home, with information that helped users and programmers find their way into the scene.

An emulator reaches the shop shelf

Earlier chapters in Retro Replay’s History of Video Game Emulation followed private demonstrations, development tools and small archives passed around university networks. Some programs left so little documentation that even identifying the hardware they reproduced became a puzzle. By 1995, emulators were reaching beyond those circles: into retail boxes, onto Windows desktops and across the Internet.

Faster computers made that reach possible. An emulator has to do far more than run an old processor’s instructions. It must fetch each instruction from the emulated machine’s memory, work out what it means, reproduce its effects, and update registers and timing. It must also imitate graphics and sound hardware and handle the player’s input. All of this has to happen quickly enough that the game feels like it is running on the original system. A console with a processor running at only a few megahertz could therefore demand a computer many times faster.

Fast 486 PCs, improving Macintosh systems and powerful Unix workstations were giving programmers room they had lacked only a few years earlier. Windows was becoming a practical place to run emulators, while the Internet helped developers share the work of understanding the machines. Technical notes could travel beyond a company, laboratory or local bulletin board. Programmers compared discoveries, players reported broken games, and websites mirrored files and kept hardware information available for the next person to build on. The much larger emulator boom of 1996 and 1997 was still ahead, but commercial releases, portable code and online communities were already taking shape together.

Activision Puts an Atari 2600 Emulator in a Retail Box

Activision’s retail example was Activision’s Atari 2600 Action Pack, released in 1995. Its fifteen games came from the company’s early Atari VCS/2600 catalog, including Pitfall!, River Raid, Kaboom!, Chopper Command, Freeway, Seaquest and Spider Fighter.

Underneath the familiar titles was an Atari 2600 emulator executing the old game data. The developers reproduced enough of the console’s hardware environment for the original software to run again. Building a native Windows version of Pitfall!, then starting over for River Raid and every other game, would have meant fifteen separate jobs. Emulating their shared machine gave the collection one foundation.

That approach offered publishers a way to rerelease games without necessarily needing the original development team or source code. Nor did each game have to be recreated by hand. If the software version of the machine was accurate enough, the old program could run inside it.

Today, mini consoles, digital rereleases, anniversary compilations and museum-style collections regularly pair original ROM images with customized emulators. Activision was trying that business model in 1995, when commercial game emulation was still unusual.

Mike Livesay and the Machine Inside the Package

In a surviving March 1995 technical post, Livesay dated the start of development to June 1994. He described Action Pack as a deliberate return to the early days of game programming, when cartridges were measured in kilobytes and the MOS 6502 processor family dominated large parts of the industry. Getting those small games running on a newer machine was a serious engineering job, however nostalgic the packaging might be.

Livesay wrote roughly ninety percent of the Windows emulator in 486 assembly language, leaving the interface portions to C or C++. In his account, that choice came down to speed. Windows already took its share of the computer’s resources, and reproducing the Atari 2600’s timing could be expensive. The old console looked simple. Making it behave properly inside a PC was another matter.

Why the Atari 2600 Was Harder to Emulate Than It Looked

The Atari 2600’s specifications hardly suggested a demanding machine: a 6507 processor running at roughly 1.19 MHz, just 128 bytes of internal RAM, and cartridges that were tiny by later standards. But those limits forced game programmers to work directly with the graphics hardware, timing their instructions with extraordinary care.

There was no conventional framebuffer—a finished picture stored in memory—waiting for the television circuitry to display. Instead, games manipulated Atari’s Television Interface Adapter as the television beam moved across the screen. Programmers synchronized their code with individual scanlines, changed graphics registers while the picture was being drawn, repositioned objects and reused the limited hardware several times within one frame. Every clever trick that put more action on the television gave the emulator another behavior to reproduce.

Getting the 6507 instructions in roughly the right order was therefore only part of the job. CPU timing had to line up with collision registers, sprite positions, color changes, controller input and audio. Games relied on those relationships to look, sound and respond as they had on the console.

Livesay explained that unusual access patterns could force extra checks, using more of the PC’s CPU time. Different games pushed the emulator in different ways, leaving him to balance compatibility against speed. A hardware specification could get an emulator started; real games could depend on behavior the documentation barely mentioned, and reproducing it accurately cost more work.

The Action Pack Included a Debugger

The Windows Action Pack also had a tool tucked beneath its game-selection interface: a debugger. Surviving technical notes explain how users could launch the emulator executable directly to expose a debug menu for inspecting the emulated 6502 environment. Memory, registers and execution flow were available for examination—the sort of tools a developer needs when a simulated machine refuses to behave like the original.

The Cartridge Was Becoming Software Again

Action Pack also loosened the bond between a game and its cartridge. An Atari cartridge had been both software and a physical object: a plastic shell containing ROM chips made for a particular console. With emulation, the game’s code could be kept as data, and a program could take the console’s place.

That gave games another route past aging hardware. Physical media fail; proprietary chips disappear. Consoles acquire broken video circuits, dead capacitors and corroded contacts, while their display standards become obsolete. A faithfully preserved software image and an accurate description of the machine could let the program run beyond the life of its original equipment.

For Activision, there was a more immediate use: selling the old games again. Its Atari catalog no longer had to remain tied to an extinct platform. Emulation made those games a library the publisher could package for another computer.

Marat Fayzullin Moves From MSX to Game Boy

While Activision was putting emulation in a retail box, Marat Fayzullin was building emulators that could move between computers. His work on fMSX, begun in 1993, centered on portable C code, reusable emulation components and host-specific layers that could be adapted for different machines. The emulator did not have to stay tied to one PC environment.

MSX itself encouraged that approach. It was a hardware standard used by Sony, Panasonic, Toshiba, Philips and numerous other manufacturers, rather than a single company’s computer. An emulator needed to reproduce the architecture those machines shared. Fayzullin emphasized modularity and portability, an approach that would become increasingly useful as emulators spread across Unix workstations, DOS PCs, Windows machines, Macs and eventually mobile devices.

Building fMSX also gave Fayzullin experience he could carry into another project: CPU emulation, memory mapping, video logic, keyboard or controller abstraction, and platform-specific display code. The next machine would have its own demands, but he no longer had to build every part from scratch.

Virtual GameBoy Begins in 1995

In his retrospective Virtual GameBoy history, Fayzullin dates VGB’s beginnings to 1995. He describes finding Game Boy programming information on the Internet and applying what he had learned from fMSX. Older emulator timelines sometimes tried to connect VGB directly to the incompatible ToyBoy/Gameboy68000 experiment discussed in Retro Replay’s 1992 chapter. Fayzullin’s account instead identifies fMSX as the technical foundation for his move to Nintendo’s handheld.

The Game Boy’s modest clock rate and monochrome screen hid a demanding emulation target. The handheld’s CPU is related to the Intel 8080 and Z80 families, but it is not an off-the-shelf Z80. Reproducing its instructions was only part of the job. Timers, interrupts, LCD registers, tile graphics, sprites, controller input, serial communication and cartridge-specific memory banking all had to work together. To run commercial cartridges reliably, an emulator needed an increasingly complete model of the handheld.

Virtual GameBoy Reaches Users Through the Internet

By the October 5, 1995 Usenet announcement, Fayzullin was offering Virtual GameBoy version 0.3 for Unix and Windows. He described it as a portable emulator written in C and discussed compatibility with dozens of games. VGB was still young, but users were already testing it against a broad library rather than one carefully chosen demonstration cartridge.

Usenet gave Fayzullin a direct route to thousands of technically interested users. He could announce a build; they could download it, try their games and report what failed. The emulator was now a public project with a testing audience far beyond its author’s computer.

That exchange would become a powerful way to improve emulators. One programmer did not need to own every cartridge. Users scattered across the world could uncover problems the author had never encountered, and each broken game offered a clue about some behavior the emulator still needed to reproduce.

More computers could join in

VGB’s portability widened that audience. An emulator tied to one kind of computer could attract users there; carefully written C code could travel from Unix to Windows, bringing communities on several host platforms into the same project. It could also outlive those first hosts and reach computers that did not yet exist when the original version was designed.

Programmers were learning how to keep the parts that described the old machine separate from the parts that talked to the new one. CPU cores could become reusable components, and sound-chip implementations could move between projects. Video code could be isolated from the host operating system, allowing the hardware logic to stay intact while the code that drew a window or read a keyboard changed. Authors still had very different styles and goals, but successful projects gave other programmers patterns to study. Emulation was developing a shared engineering practice.

Famicom Emulation Was Growing Alongside the Game Boy

Nintendo’s home console presented a related problem, with an extra complication inside the cartridges. The Famicom had launched in Japan in 1983. By 1995, its library held more than a decade of cartridge technology, including increasingly complicated hardware that Nintendo and third-party publishers had used to extend the console. Reproducing the base machine would only get an emulator so far.

Unlike a fixed computer configuration, the Famicom and NES could gain hardware with each game inserted. Memory-management controllers switched banks of ROM into the CPU’s address space. Some cartridges changed the organization of graphics memory, while later boards added more advanced behavior that their games expected to find. An emulator could execute the CPU’s instructions correctly and still fail badly if it did not understand the cartridge board. Part of the machine was in the game.

Pasofami and Nobuaki Andou

Nobuaki Andou had already appeared in Retro Replay’s timeline through earlier Japanese Famicom emulation work. His surviving official Pasofami site retrospectively dates the program’s debut as a Japanese Famicom emulator to 1995, though other evidence points to earlier experimentation on Japanese computer hardware.

Those dates can describe different stages of a project’s life. Work could begin privately or on a specialized system before reaching a wider audience. Around this period, Pasofami was moving into the rapidly expanding PC ecosystem, alongside the wider push to make Famicom emulation accessible.

Getting a game onto the screen was only part of Pasofami’s work. The project also developed around a more immediate obstacle: the game’s data was still sitting inside a physical Nintendo cartridge. Software needed that data in a file before it could do anything with it.

A ROM File Was Becoming a Standard Object

Today, a cartridge dump can seem straightforward: one file, one game. Early Famicom emulators did not always agree on what that file should contain or how it should be arranged. Pasofami used formats that could keep program ROM, character ROM and configuration information in separate pieces. The familiar simplicity of a game file took years of experimentation and standardization to build.

Those pieces reflected the cartridge’s structure. CPU instructions and graphics data could be stored separately, and the cartridge’s hardware determined how memory was mapped. An emulator needed both the bytes and enough metadata to reconstruct how they had been connected to Nintendo’s hardware. Copying the contents alone did not describe the whole cartridge.

A file format could then take on a life beyond the emulator that introduced it. Once thousands of dumps existed in a format, other programs needed to read it or offer a way to convert it. One author’s practical solution could end up shaping how a console’s games were archived—and how readily another emulator could use them.

Dumping Hardware Connected Preservation and Controversy

A cartridge reader took the bits stored in a ROM chip and saved them as a file. After that, the same file could go in very different directions. A developer might use it to find out why a game failed in an emulator. A collector might archive a rare cartridge, or a preservation researcher might rescue data from failing media. Someone else might upload it for anyone to download. The copying process brought emulation into legal and cultural disputes that would follow it for decades.

Emulator developers often drew a sharp line between writing software that could run a game and distributing the copyrighted game itself. Much of the public discussion over the next decade would instead define the community by its most controversial uses. Debugging, archiving and unrestricted sharing could all start with the same cartridge reader, but they were different activities.

The reader shown above made that transition from cartridge to data tangible. Once copied, a game’s contents could be measured and analyzed independently of the console. Preserving the physical object and preserving the data inside it were becoming separate jobs.

NES WORLD: The Web Becomes Part of Emulation History

Getting a game into a file solved one problem. Finding useful information about that file, or the software that could run it, was another. The Web was rapidly becoming a place to look. NES WORLD’s own history traces the site back to 1995, when Martin Nielsen was building an online destination for Nintendo information, scans, pirate-console material and other subjects that fascinated collectors.

The surviving screenshot shows NES WORLD through Internet Explorer: a personal website maintained by an enthusiast, finding its audience while that audience was finding the Web. It lacked the analytics, social platforms and content-management systems of a modern media site, but it gave visitors somewhere to start.

Information about emulators had been scattered across FTP directories, mailing lists, BBS messages and Usenet threads. A website could gather it into pages that users could browse and return to. Emulator recommendations, compatible-game lists, utilities, cartridge-format explanations, mirrored technical documents and links to new releases could finally sit together.

NES WORLD’s major emulator coverage would become more visible in 1996 and 1997. Its 1995 beginnings laid the groundwork for that coverage, as users increasingly needed help making sense of a scene that was growing beyond any single program.

For a player, that help could mean learning why a fast emulator would not run a particular cartridge while a slower one would. A good page could explain which cartridge mappers each program supported, how to convert between ROM formats, which graphics settings to use and which games still failed. It might also keep a utility available after its author’s page vanished. Printed manuals had little chance of keeping up with software that changed this quickly.

Those pages now help tell the history, too. Many of the most useful surviving artifacts from the late 1990s are HTML pages, readme files, forum discussions, Usenet posts and archived compatibility lists. An emulator binary can show that a program existed. The surrounding documents help explain what users expected from it and how they understood its limits.

Damaged Cybernetics Was Waiting in the Background

Damaged Cybernetics had roots that reached further back. In an October 1996 interview, Moore described the group as people who liked experimenting with consoles, operating systems and other technologies. He said he had created the name in 1991 while writing small utilities of his own. The group would take a larger role in emulation history in 1996, and especially in 1997.

By the middle of the decade, its interests increasingly overlapped with the growing console underground. Technical references and cartridge copiers sat alongside utilities, save manipulation and homebrew material. These were people exchanging information about parts of the machines that conventional game companies had little interest in documenting publicly.

Damaged Cybernetics and NES WORLD Had Not Yet Joined Forces

NES WORLD and Damaged Cybernetics were still separate in 1995. According to NES WORLD’s own history, the site joined the group around October 1996. That later connection brought together interests that were already developing alongside one another.

A Nintendo fan site could lead a collector to programmers studying memory maps. An emulator page could point to cartridge utilities, with copier documentation and homebrew games nearby. People arriving for different reasons increasingly met online, even when they disagreed about legality, ethics or what to call their hobby.

Information could travel quickly through those connections. A discovery about a register or a cartridge mapper could help other programmers improve their work. Source code, private software and copyrighted games could also spread without permission. The network was good at moving both.

A game that failed to run could give an emulator author the next problem to solve. More cartridge dumps meant more chances to uncover compatibility faults; investigating those faults produced hardware research and documentation that other programmers could use. Websites carried that work to users, users reported more bugs, and authors released another version. Each round gave the next one a head start. In the years immediately after 1995, those connections would make the scene much busier.

A retail box and a personal homepage

The people doing this work reached players in very different ways. Activision owned the rights to the games in its Action Pack and sold the package as a nostalgia product, with Mike Livesay’s low-level emulator engineering inside. Marat Fayzullin carried experience from one portable emulator into another, distributing Virtual GameBoy to a technical Internet audience while keeping it separate from commercial game images. In Japan, Pasofami grew within Famicom enthusiast culture, closely tied to the practical work of extracting data from cartridges.

All three still had to make another machine behave closely enough to the original that its games would run. A familiar picture on the screen was only part of the job.

Across these unrelated systems, programmers were showing that the same approach could work: represent the machine in software and the game as data. Emulation was becoming a reusable method rather than a handful of isolated experiments.

The Legal and Cultural Argument Was Already Following the Technology

There was still a practical catch: an emulator needed something to run. Activision could legally package its own game data. Independent authors could supply emulators without including commercial ROMs—the files containing game data. Online communities increasingly circulated those files independently of both publishers and emulator authors, opening an argument that would run through the next decade.

Authors differed over how close they wanted to stand to game-copying culture. Some openly associated themselves with it; others kept away from ROM sites. Many fell somewhere between, with attitudes shaped by preservation, ownership, technical curiosity and the early Internet’s habits of sharing information.

Public discussion often flattened those differences. Emulation, dumping a cartridge and piracy became interchangeable labels, though they described different acts. As fast NES, SNES and PlayStation emulators drew larger audiences, the tension already visible in 1995 would grow sharper.

More places to find the games

The important change in 1995 was how these developments reinforced one another. Faster computers and portable code brought emulators to more users; cartridge readers supplied games to test, and the Internet carried discoveries and bug reports back to programmers.

The Road to 1996

In 1996, NES emulation would become far more visible to Western PC users. Fayzullin’s iNES would enter the Famicom/NES ecosystem as emulator websites multiplied and compatibility information and ROM-format utilities became increasingly important. NES WORLD would move closer to emulation and eventually spend a short period connected to Damaged Cybernetics.

Damaged Cybernetics also foreshadowed the underground culture that would soon collide with mainstream emulator development. Authors would compete over speed and accuracy, and shared source code would invite both collaboration and conflict. IRC channels and private communities would grow alongside public websites. A developer could become famous under an alias while most users never learned their legal name.

Soon, console emulation would be something ordinary PC users could download, configure and understand, rather than something a dedicated enthusiast had to seek out. Programs such as NESticle would become cultural phenomena in their own right. They would arrive in a world whose programmers, tools and communities were already taking shape by the end of 1995.

Sources and Further Reading

• Mike Livesay — Action Pack technical information preserved from rec.games.video.classic
• Atari 2600 Emulator FAQ — archived Action Pack technical discussion
• MobyGames — Activision’s Atari 2600 Action Pack credits and release information
• Marat Fayzullin — emulator project index
• Marat Fayzullin — official fMSX documentation
• Marat Fayzullin — official Virtual GameBoy history
• Virtual GameBoy documentation
• Marat Fayzullin — October 1995 Virtual GameBoy announcement
• Pan Docs — Game Boy technical documentation
• Official Pasofami website
• Pasofami historical notices and project history
• NES WORLD — history of the site beginning in 1995
• NES WORLD — preserved early emulator coverage
• The Affinity MindRape Interview — Donald Moore on Damaged Cybernetics, 1996
• Zophar’s Domain — historical retrospective on Damaged Cybernetics