The Need for Emulation
May 5, 2026One of the first experiences I had with emulation occurred when I was a teenager using MS-DOS. I didn’t understand what emulation was at the time, not even conceptually. I was a burgeoning programmer to be sure, using all sorts of wonderful technologies like BASIC, QuickBASIC, C compilers to write simple programs. As a result, my experience was very narrow. I had even written primitive assembly language programs on more limited platforms like the Atari 800 XL. Impressed yet? Despite all of this vast experience, I was very naive about my new found hobby, if you can believe it.
On one fateful day, I was browsing the “hot downloads” on my local BBS and decided to download a curious program called “ZSNES,” which is a software emulator for the Super Nintendo Entertainment System. Once I had that downloaded and unpacked, I ran the main program and began looking through the menus. I did not understand the concept of a ROM file. I did not understand BIOS dumps. I did understand emulation. Did I let that stop me? After a bit of Internet sleuthing, I came across the required files fairly quickly. The Internet was a different place in the 1990’s, and it was trivially easy to find all manner of “unsavory” files. Back then, there was no stigma against ROM dumps or game backups, and lawyers were blessedly ignorant in this area, so things like music and small games were shared freely. Movie sharing needed to wait until technology in general grew up.
Once I had loaded my chosen ROM into the emulator, and it should be noted that I owned this game at the time, I was greeted by an all too familiar “tink” and the “Nintendo Presents” text on the screen. I could not believe what I was seeing, and I do not have the words to elaborate on how this experience altered my perception about how computers really worked. Save states anyone? Game Genies codes couldn’t hold a candle to this product of coding sorcery.
The revelation that I could now play SNES games on my computer was a song that needed to be sung and I was the new village preacher. Well, technically, I had a congregation size of one, maybe two if you included my cat and he didn’t have the same passion on the subject that I did. I could tell. The games looked fantastic on my VGA monitor and sounded great on my stereo (I used an FM transmitter). The experience far surpassed playing on my ho-hum console. As I started poking around the application, I uncovered all manner of technical details around how the SNES worked. It’s funny how I never gave the inner workings of game consoles much thought prior to this moment. I was the kind of teenager who wanted to take everything apart to reveal their secrets, much to the chagrin of my father, who wanted nothing more than for me to put that stereo back together right now and without any missing pieces this time! I had all kinds of interest in how computer games and programs worked, but consoles in my mind, were just different beasts altogether and completely inaccessible to me as a programmer.
This was true from a certain point of view. Console programming was a dark art, unless you had the blessing from the pantheon responsible for distributing development kits and technical manuals, and even if you had those kits, much of the development process was DIY. It was common for programmers with hardware knowledge to create their own interfaces and tools to make development and debugging easier when building games for these platforms, or even possible in some cases. The companies didn’t hold your hand and feed you websites filled with API documentation and pre-configured development machines.
This technical sleuthing into how this emulator worked sent me down a technical spiral that lasted a couple of years. I was changing the microcode in the ROM files to alter a game’s behavior. I was writing tools that dumped cartridge data and helped me piece it all together again. In one project, I wrote some code that dumped the tile-set for the Legend of Zelda: A Link to the Past, and then hacked an editing program called HyruleMagic to export the palettes and the tile maps, so I could color and organize the tiles. I used those colored tiles to build a small, boring Zelda game. I loved it.
Fast forward many years later, and my perspective on the gaming industry has changed significantly. While I have mostly lost that sense of wonder and magic around seeing programs like this for the first time, I can still feel that thrill on rare occasions. I still enjoy writing software, but for different reasons. I also see emulation from a very different angle now than I did on that day. I have never looked at emulation as a way for me to play illicit games. My parents supplied us with enough games, and I can afford to buy any game I want to play now. I also do not seek to collect massive numbers of games in an attempt to collect them all, a digital archive wasting away on a hard drive in my closet.
I see emulation as the only means to preserve technological and entertainment history. The outer shell of a console can be rebuilt, games can be archived, but if the details around the inner workings are not documented in excruciating detail, the technology required to run those games will be lost to time. Emulators serve as a great archive of how the machine worked, even if the software does not replicate the physical electronics, they do replicate the behavior of the system in so far as the logic, data, and processing are concerned.
Hardware eventually dies. Components stop working. The smallest component on a circuit board that has failed can cause the entire system to fail. Many people do not have the skill, time, desire, or the money to repair these machines, so they are resold or passed on, where they are eventually discarded by inheritors as junk. In time, the hardware supply will run out, and if emulation is not available, there would no longer be a way to experience the games of the past. You don’t need to go back very far in time to see this being played out with machines from the 1950s, 60s, and even later. There is a YouTube! channel called “Usagi Electric” whose owner takes the viewer on a journey around how the mechanics and the electronics are serviced from that era. It is not easy. The experts for those machines are retiring and passing on, and they are often key sources of information. Realistically, these machines never work when they enter his shop, and debugging one of those machines is a different problem than interpreting the symptoms. Unfortunately for Usagi Electric, there is precious little documentation available to those trying to resurrect them, even if there was an abundance when the machines were new.
The teams who write emulators are programmers who rarely work alone. It is often a team effort requiring several different kinds of skills. When you undertake a project like this, you need to understand the machine at a fundamental level. The companies behind these devices are not falling over themselves documenting how the machine works. It is exactly the opposite. Secrets abound in this domain and the companies behind this clever bit of engineering have zero incentive to document their hard work. As a result, emulator authors need to take the machines apart and try to build an understanding around how they work so that key systems can be simulated in software.
I need to underscore how difficult this job can be, even when trying to emulate relatively simple systems like the original Nintendo Entertainment System or Nintendo Gameboy. The process can require the knowledge and expertise in areas like hardware, software, and mathematics. Unrolling the functionality so that it can be accurately emulated is a large amount of work and these people are doing it mostly in the dark and for free. Earlier systems tended to be simpler with relatively few custom chips. Programmers could leverage hardware specifications for known chips to understand how they worked, but as the cost for producing custom chips went down, their use went up. Custom chips are rarely documented in a form available to the public, so they must be approached as a black box when trying to reveal their secrets. More sophisticated techniques for reverse engineering systems have been developed over the years, such as x-ray analysis or de-capping chips using chemistry or lasers. This knowledge is neither pervasive nor easily accessible for most hobbyists, and even if you could illuminate the guts of the chip, understanding what you are seeing is a whole different ball game, so they must rely on the results and the talents of others.
It cannot be overstated how unhelpful most companies are in this regard. Practically speaking, they do not want to legally separate the machine that runs the software from the intellectual property (IP) they are trying to protect. The console manufacturer doesn’t really care about the console from a money making perspective, it is primarily a delivery system for the products that do matter. The technical edge that a console has when it is first released, if any, is quickly overtaken by competitors in the market. A successful game franchise, like Mario Bros. for example, is a cash cow that keeps on delivering, year after year, console after console. As a result, lawyers abound in companies with IP to protect.
I understand their position and empathize with it. I do not think people should pirate software. While I enjoy the idea of playing a home-brew Zelda or Mario game, I understand and agree that these creations diminish the brand and could take the property to places they do not want it to go.
I also do not believe that the responsibility for preserving this part of our technological history should be entirely shouldered by the public. The unfortunate reality is that companies are constantly pushed to follow the money, and are incentivized towards building solutions that focus only on supporting the most lucrative software titles. This can mean that many properties get left behind and are no longer promoted or developed. As an example, Nintendo’s catalog of supported games through their virtual console platform continues to diminish after every new console release. What incentive do they have in providing the public access to the full library of games? Without emulation, the games that do not meet the cut are lost. Once a company folds, it becomes even more difficult to surface details about the platforms and the games.
Thus the responsibility for developing a solution to play these games falls to the public, and many emulator authors are actively punished for doing so. On the one hand, I do not think that the authors of a tool should be criminally responsible for building it. If I make high quality hammers and you decide to buy one and then proceed to smite your enemies with it, it’s not my fault simply because I made the hammer. On the other hand, there is a fine line here that is worth debating. While it is true that emulators can run custom software, it is also true that the primary use for such a product is to run commercially released software. Therefore certain companies aggressively defend their IP from these threats, and like the war on drugs, the defenders tend to go after the big fish.
There needs to be a balance, something in-between excessive prosecution and outright piracy. As a culture, things like games, film, art, music, and books are a creative part of the sociological fabric and shape us more than we would like to admit, we should all want to preserve these works so they can be enjoyed by future generations.
Categories: Retro, Software
No Comments »


No Responses to “The Need for Emulation”
Care to comment?