Retro Replay Retro Gaming History, Reviews & Emulation
In 1994, a primitive DOS program called MegaDrive got a PC to run Sonic the Hedgehog. It was slow and imperfect, but Sega’s 16-bit console was a daunting machine to reproduce in software. The previous year had helped lay the groundwork: Pasofami pushed developers and users to work out cartridge images, mapper information and repeatable dumping methods, while Marat Fayzullin began fMSX with portability built into its architecture. An emulated machine could become reusable software rather than a trick that worked on one computer. Now programmers were trying that approach on consoles still sitting under millions of televisions.
The Sega Genesis/Mega Drive and Nintendo’s Super Famicom/Super Nintendo still had active game libraries, recognizable mascots and a large place in the games business. Sega was selling Sonic games; Nintendo was still expanding the SNES library. By the end of 1994, both companies were also looking toward a new generation that included the Saturn and Sony PlayStation. Emulator programmers were trying to catch up with hardware whose commercial life was far from over.
On the Nintendo side, VSMC — Virtual Super Magicom emerged as the earliest widely documented public SNES emulator, with a preserved beta dated September 1, 1994. Meanwhile, game copies were already travelling through modem-connected bulletin boards and being played with physical copier hardware. That traffic brought a different part of the scene into federal court in Sega Enterprises Ltd. v. MAPHIA, a case concerning unauthorized game copies.
MegaDrive and VSMC faced the problem of making a computer behave like a console. The people distributing copyrighted game images faced a separate problem, one that Sega v. MAPHIA brought into focus as the scene grew. A game file could circulate before a software emulator was ready to play it.
The 16-Bit Wall Was Higher Than It Looked
For a player moving from an NES to a Genesis or Super Nintendo, the upgrade was easy to see and hear: more colors, better sound, faster action and the advertised promise of “16-bit” power. For a programmer, it meant far more machinery to reproduce. The Famicom, Game Boy and early MSX targets were comparatively simpler. Both major 16-bit consoles combined multiple processors and custom chips, and getting each part right was only part of the job. They also had to work together at the right time.
The Genesis/Mega Drive’s main processor was a Motorola 68000 running at roughly 7.6 MHz. As Rodrigo Copetti’s technical analysis of the Mega Drive architecture explains, a Z80 served as a secondary processor, while a custom video system handled graphics. Sound involved two more pieces of hardware: Yamaha’s YM2612 FM synthesizer and a Texas Instruments SN76489 PSG. Getting the 68000 to execute a game’s code did not, by itself, give the player the picture and sound they knew from the console.
Nintendo presented a different tangle. The SNES used a Ricoh 5A22 based on the WDC 65C816, a 16-bit extension of the 6502 family, surrounded by custom graphics, DMA, interrupt and audio behavior. Copetti’s account of the Super Nintendo architecture describes sophisticated background modes, multiple graphics layers and the famous Mode 7 affine-transform system. Even when an emulator executed CPU instructions correctly, the screen could come out wrong or the game could run at the wrong speed. A missed interrupt or an unreproduced timing detail could stop it altogether.
Even the cartridge could add more work. Nintendo and third parties put extra processors or specialized hardware inside some games, so an emulator’s target could change when the player loaded another cartridge. Super FX, SA-1, DSP and other enhancement hardware would give later emulator authors plenty to wrestle with. In 1994, getting the base console to do something convincing was already a considerable achievement.
MegaDrive: A PC Tries to Become Sega’s 16-Bit Console
The earliest known software emulator for Sega’s 16-bit console is generally remembered as MegaDrive or MegaDrive Emulator. Its name was straightforward; tracing its development is less so. Far less documentation survives than for later projects, leaving contemporary and near-contemporary records to be pieced together with retrospective histories.
The influential EmuFAQ timeline dates MegaDrive to 1994 and credits The Careless Gamer, calling it the first working Genesis/Mega Drive emulator developed by and for the emerging emulation scene. A later history of Genesis emulators identifies the main programmer as Steve Riddle, using the handle The Careless Gamer or ]TcG[, and names Baalzamon, Berzerker and Stegg as secondary contributors. The personal name rests on that retrospective account rather than a strong surviving 1994 primary source; the handle is much better established.
The Careless Gamer Enters the Story
The Careless Gamer, commonly abbreviated ]TcG[, is credited by early emulation histories with the 1994 DOS program MegaDrive, the first known working software emulator for Sega’s Genesis/Mega Drive. Later retrospective sources identify the principal programmer as Steve Riddle, but the surviving contemporary record is sparse enough that Retro Replay preserves the handle as the safest canonical identity.
Sonic the Hedgehog ran on MegaDrive, but speed was hardly its strong suit. Zophar’s Domain later preserved the project with a blunt assessment: it could play Sonic “very slowly,” without sound and with many glitches, and could do little else. It was a long way from the Genesis emulators that would arrive a few years later. Still, in 1994, recognizable commercial game code was running on a software recreation of Sega’s console. There was finally something on the screen to improve.
Development did not get much further. A retrospective project history identifies version 0.5 Version 2, released in July, as the last confirmed 1994 build and says a hard-drive failure destroyed the source code, ending the project. Zophar’s archive also records a hard-drive crash as the reason it was discontinued. The details of the loss remain difficult to reconstruct. This was before hosted source control, distributed repositories and ubiquitous online mirrors could offer a hobby programmer protection from one dead drive.
Sonic gets onto a PC
Getting Sonic to run at all required several parts of the Genesis to cooperate. The 68000 processor had to execute the game’s code accurately enough to handle its logic and memory access. The VDP, the console’s graphics hardware, had to turn tiles and sprites into a recognizable picture. Controls had to respond, cartridge addressing had to work, and interrupts and timing had to keep the game advancing instead of bringing it to a halt. A glitchy platform game still depended on a surprising amount of machinery behaving itself.
Sound added another set of jobs. The Genesis combined the YM2612’s six-channel FM synthesis with the SN76489 PSG, while a Z80 processor commonly handled sound-related work. Copetti’s technical breakdown notes that the YM2612 connected through the Z80 side of the system. Reproducing that arrangement meant emulating another processor and multiple audio devices alongside the 68000 and graphics hardware. MegaDrive remained silent, following a common pattern in early emulation: first get the game running and visible, then tackle audio and refine the timing.
MegaDrive also came from a different setting than many of the earlier projects in this series. Alongside commercial developers, private engineering experiments and tools built for particular computers, there was now a growing community treating emulation as a hobby of its own. MegaDrive is remembered explicitly as an emuscene project, made by and for that community. The EmuFAQ used it as the point after which its timeline could assume that “emulator” meant a true software implementation unless otherwise specified.
The release survives better than its origin story
MegaDrive is the earliest working Genesis/Mega Drive software emulator documented in the public emulation tradition. That leaves room for earlier private experiments, abandoned programs or internal development tools that never entered the surviving record.
September 1994: Virtual Super Magicom Arrives
If MegaDrive represented the first crack in Sega’s 16-bit wall, Virtual Super Magicom attacked Nintendo’s. The project is usually abbreviated VSMC. SnesLab describes it as the first publicly released SNES emulator and attributes it to Chris George, “The Brain”. More importantly, a surviving Zophar’s Domain archive preserves Virtual Super MagiCom 0.70 Beta Pre-Release 1 with a release date of September 1, 1994. Years later, Zophar called it the emulator that “really began SNES emulation.”
Chris George Enters the Story
Chris George, better known in the emulator scene as The Brain, programmed VSMC — Virtual Super Magicom — and became one of the earliest recognizable SNES emulator authors. Later VSMC documentation identifies him directly as “The Brain,” while surviving emulator histories associate the project with Damaged Cybernetics.
As with The Careless Gamer, Retro Replay has not located a verified photograph of George that can be confidently tied to the emulator author, so the standard No Known Photo placeholder is used rather than attaching somebody else’s face to his name. The surviving software and documentation are considerably better preserved than the man behind them.
The September beta gave users very little to play. A modern academic history of SNES afterlives describes the initial DOS version as running only a small selection of homebrew demonstrations. Commercial titles came gradually in later versions, and the much more capable builds documented a couple of years later should not be mistaken for the 1994 release. George had a publicly circulating program that reproduced enough of the SNES to build on, but the Super Nintendo library was still well out of reach.
The SNES Was a Timing Problem Disguised as a Game Console
Getting VSMC to run was one thing. Getting a game to move at a decent pace demanded a much faster PC. Later VSMC documentation lists an i286 with 575 KB of conventional memory, VGA and DOS 4.01 or later as the minimum, but suggests a 486DX-66 for decent playability. For 100 percent SNES speed, it calls a Pentium-class P5-120 the “optimal” machine. These requirements describe builds after the 1994 beta, showing how much work George still faced—and how much computing power that work consumed.
Even a fast processor benchmark could give false hope. The same VSMC documentation records George’s report that his CPU emulation on a 486DX2-66 ran faster than the real SNES CPU. Add the rest of the console, though, and performance fell sharply. NMI and IRQ interrupts, which prompt the processor to respond to events, had to happen at the right times, along with input/output operations and screen refresh. George’s best-case estimate put that 486 at about half real SNES speed; a P5-120 could reach or exceed full speed. The processor could win its race while the game still crawled.
Nintendo’s hardware gave George plenty to coordinate. The Ricoh 5A22 changed its clock behavior depending on which part of the system it accessed. DMA transferred data without ordinary CPU loops. The picture processing unit, or PPU, combined background layers, sprites and complex display modes; Mode 7 used dedicated hardware for affine transformations, such as rotating and scaling a background. Sound ran in its own subsystem. Games expected these pieces to act in roughly the same order and at roughly the same time as they did inside a real SNES.
A broken sprite or a game that refused to run could therefore mean much more than a missing bit of polish. Each newly compatible game could expose an unimplemented register, a timing assumption, an obscure memory-map detail or a graphics behavior George had not yet discovered. Getting another game working was also a way to learn what the machine actually did.
Why Was It Called Virtual Super Magicom?
The files VSMC tried to run came from a world that already had its own hardware. Before PCs could convincingly emulate the SNES, game copiers let users copy cartridge contents to floppy disks and load those images back into a real console. One influential device was the Super Magicom MS-3201, released by Front Fareast Industrial in 1992 according to ConsoleMods’ hardware history. VSMC’s name pointed straight to that earlier machine.
The copier read a cartridge into memory and wrote its contents to floppy disk. Later, it could load that saved image for the SNES hardware to run. Game files were thus already in circulation before general-purpose PCs were fast enough to emulate the console. The familiar .SMC extension on many historical SNES ROM images comes directly from this copier culture.
Virtual Super Magicom took that workflow onto the PC. A physical Super Magicom loaded an SMC image into a real SNES; George’s program attempted to make the computer stand in for the console. Along with the game dumps, software emulation inherited the copier world’s filenames, extensions, conversion utilities and vocabulary.
SMC Files Were Already an Ecosystem
Later VSMC documentation assumes the reader already has SMC-format files and explains how to make other images work. For VSMC’s purposes, .SFC files were structurally equivalent and could often simply be renamed. Raw or interleaved images could be processed with utilities such as CTOOL or uCON. Even saved progress could make the journey: the manual discusses SRAM files produced by copier hardware and notes that many were already compatible with VSMC.
This carried the file-format story seen with Pasofami in 1993 a step further. A game’s data could now travel from a physical cartridge through a copier and floppy disk to a software emulator. Conversion utilities bridged the different assumptions each device or program made about headers and data layout. As images circulated through BBSs and the Internet, the emulator scene inherited a massive library of files, often separated from the cartridges they had come from. Moving the data was becoming easier. The legal trouble surrounding its distribution was already underway.
March 1994: Sega v. MAPHIA Draws a Line Around ROM Distribution
Months before VSMC’s preserved September beta, the United States District Court for the Northern District of California issued its March 28, 1994 findings in Sega Enterprises Ltd. v. MAPHIA, granting a preliminary injunction. The order concerned MAPHIA, a San Francisco bulletin-board system operated by Chad Sherman, also identified in the record as “Brujjo Digital.” The court described a public BBS with roughly 400 users who uploaded and downloaded files by modem.
The dispute concerned unauthorized copies of Sega’s copyrighted game programs uploaded to and downloaded from MAPHIA, along with business activity involving console copier hardware. The court record described the BBS as actively encouraging the copying and distribution of Sega games, with download privileges tied to payments, barter and sales of copier devices. The March order did not declare emulator software illegal. It addressed the copying and distribution practices at this BBS.
Put a Genesis cartridge into a Super Magic Drive and you could copy its contents to floppy disk. Later, the device could load that game from floppy into RAM and run it without the cartridge. The court’s description of the copier hardware lays out a process close to what software emulators were beginning to attempt on PCs. A dumped game image could feed a copier, a preservation utility or an emulator. None of those uses, by itself, established whether the copy had been lawfully obtained or distributed.
MAPHIA had gone well beyond someone making a backup of a cartridge at home. The court record describes unauthorized copies of Sega-developed and Sega-licensed games, including software that had not yet been released. The later case record counted 12 Sega-developed games, 10 licensed games and six prerelease or beta versions on the system. The dispute concerned an organized distribution operation.
The BBS World Made ROMs Travel Faster Than Hardware
Getting those files meant dialing a telephone number. In 1994, a bulletin-board system was usually a computer connected to one or more phone lines through modems. Users called that machine directly, logged in and transferred files. Even early broadband would later make those transfer speeds look painfully slow.
Cartridge games nevertheless travelled quite well through this world. Their programs were small compared with later CD-ROM games. Once dumped to a file, a game could be compressed, copied to floppy disk, traded locally or left uploading overnight. The cartridge stayed on the desk; its contents could cross town over a phone line.
The MAPHIA opinion explicitly describes this process: users uploaded and downloaded complete Sega programs, and a single upload could then be copied by an unlimited number of users. It also documented the commercial connection between access to games and sales of console backup units.
Emulator authors would spend decades trying to keep their code separate from the games loaded into it. The two are different works: a program that recreates hardware behavior can be written independently, while a ROM image normally contains copyrighted game code and assets. Using them together does not give them the same legal provenance.
Emulator Authors Were Already Trying to Separate Themselves From ROM Piracy
Later VSMC documentation shows Chris George’s frustration with requests for commercial games. In a section called “Commercial Games, Piracy and ROM Images,” he complained that people kept asking him to send games despite repeated warnings. He refused to supply commercial ROM images, instead pointing cartridge owners toward backup units, conversion tools and a home-built dumping system called CartDisk.
George’s position put responsibility for the loaded software on the user: he supplied the emulated machine. The maturing emulator scene increasingly tried to hold that boundary, but the communities around it were tangled together. Emulator websites, ROM sites, BBSs, cracking groups and hardware-copier communities overlapped heavily. Many users had little interest in a distinction that carried technical and legal weight, and would eventually surface in court.
The tools themselves served several purposes. A cartridge dumper could preserve a fragile or rare game, or make an unauthorized copy for distribution. A ROM converter could repair an archival image or prepare pirated files. An emulator could test homebrew software, help document hardware behavior and keep a game accessible after its original machines failed. It could also run a commercial ROM downloaded without permission. What a tool could do did not settle where its data had come from.
Copier hardware, BBS networks and the first 16-bit emulators were now meeting around the same files. Copiers had freed the game data from its cartridge. Modems let that data travel beyond the people who could trade a disk in person. With VSMC and MegaDrive, programmers were beginning to make it run without the original console as well.
A cartridge game could theoretically pass through the whole chain: dumped by a copier, uploaded over a modem, downloaded onto a PC and run by an emulator. In 1994, every promise in that sequence came with a wait or a catch. The chain was slow and unreliable, and the emulators could run only a tiny portion of the consoles’ libraries. MegaDrive could barely run Sonic; early VSMC handled only limited material. Neither could replace the real hardware, but the basic route from cartridge to PC was there for developers to improve.
Why Early 16-Bit Emulation Was So Slow
Raw PC clock speed told only part of the story. The computer had to translate or interpret every console CPU instruction, map memory accesses and draw sprites and backgrounds in software—work the console’s graphics hardware handled in parallel. It also had to coordinate interrupts and scanline timing, keeping events in step as the picture was drawn. A 1994 PC had limited speed to spare, and its operating environment was never designed to behave like a Genesis or SNES.
Authors bought speed by leaving things out. Early emulators skipped sound, refreshed the screen less often, implemented only common graphics modes or assumed particular ROM layouts. A game might work because it happened to use the hardware features the author had already implemented; another might fail as soon as it asked for something else. Compatibility lists helped players choose what to try, but they also showed which parts of the console the emulator could reproduce.
The public release we can trace
SnesLab calls VSMC the first publicly released SNES emulator. A recent academic study of SNES software afterlives puts it more narrowly: VSMC likely has the strongest claim to the first widespread release. Neither distinction made it the best, most compatible or longest-lived emulator.
Once VSMC was out in public, George kept changing it through rapid versions, performance experiments and shareware restrictions. By 1997, archived listings described a $35 registration price and a deliberately crippled shareware display. Later documentation also records periods when George said he was not accepting money at all. The registration model changed over time; the restrictions described in 1997 were not one fixed policy stretching back to the 1994 release.
MegaDrive’s Lost Source and VSMC’s Surviving Documentation
VSMC left plenty to examine: old binaries, preserved documentation, compatibility information and archived web references detailed enough to trace how the project developed. MegaDrive survives mostly through later emulator archives, timelines and scattered recollections. Its source code is reported to have been lost in a hard-drive crash. If that account is accurate, the loss took away the easiest way for later programmers to inspect The Careless Gamer’s implementation. Other codebases carried the scene forward without a complete source-code lineage from MegaDrive.
That uneven survival can skew the picture. A project with thousands of files, source snapshots and forum posts is easier to study and may look more influential simply because so much remains visible. A breakthrough whose files vanished before the web fully matured can dwindle to a footnote. MegaDrive’s thin surviving record leaves less to examine, but that alone cannot tell us how much it mattered to the people working on emulation at the time.
The Next Generation Was Arriving While the Old One Was Being Emulated
While those programmers were trying to make 16-bit games run on PCs, new consoles were reaching shops. Sega launched the Saturn in Japan on November 22, 1994; Sony launched the original PlayStation there on December 3. The Genesis and SNES generation was still commercially alive, but the hardware race was already moving into polygonal 32-bit systems. Hobby programmers were only beginning to reproduce the previous generation.
New consoles would keep arriving faster than emulator authors could fully understand the old ones. PCs, however, were getting faster too. Later VSMC documentation considered a Pentium-class machine capable of full-speed SNES emulation, and that class of PC would soon become ordinary enthusiast hardware. A game that crawled in 1994 could become practical to play a few years later, even though the console being imitated had not changed.
A foothold in the sixteen-bit generation
By the end of 1994, software emulation had reached current-generation 16-bit consoles, even if playing their games this way still meant putting up with severe limitations. ROM files could move between hardware copiers and software emulators, while courts were beginning to confront mass game copying over networks. The programs were primitive, but the surrounding world of files, hardware and online exchange was taking shape.
The Road to 1995: Portable Emulators Become Public Products
In 1995, more of that work would reach the public. Marat Fayzullin’s fMSX, begun in 1993, would move into much more visible public releases, and Virtual GameBoy would bring his portable emulator architecture to Nintendo’s handheld. Pasofami would enter the Windows-era chronology that Andou later remembered as its public debut. Dedicated emulation sites and online communities would also become easier to identify and preserve.
With more projects came more choices. Authors were moving beyond proving that emulation could work to tackling compatibility, speed, sound, interfaces, portability and accuracy across a growing range of machines. Once two or three emulators supported the same console, players could compare them: which ran their games, which sounded right, and which moved at a tolerable pace. Emulator development was becoming a race.
Part of: The Complete History of Video Game Emulation
People introduced in this chapter: The Careless Gamer · Chris George
Browse biographies: People in the History of Video Game Emulation
Sources and Further Reading
- The EmuFAQ — emulation timeline, including MegaDrive and Sega v. MAPHIA
- Zophar’s Domain — preserved MegaDrive emulator listing
- History of Videogame Emulators — retrospective MegaDrive development history
- SnesLab — VSMC / Virtual Super Magicom
- Zophar’s Domain archive — VSMC 0.70 Beta Pre-Release 1 dated September 1, 1994
- Preserved VSMC documentation — system requirements, timing, SMC files and ROM policy
- Afterlives of the SNES/SFC — academic discussion of early SNES emulation and VSMC
- ConsoleMods — Super Magicom and SNES floppy copier history
- Rodrigo Copetti — Mega Drive / Genesis architecture
- Rodrigo Copetti — Super Nintendo / Super Famicom architecture
- Sega Enterprises Ltd. v. MAPHIA — March 28, 1994 preliminary-injunction opinion
- Justia — Sega Enterprises Ltd. v. MAPHIA, 857 F. Supp. 679 (N.D. Cal. 1994)