A fellow vintage computer enthusiast recently asked a group of like-minded hobbyists if they use emulation (ie. running a program that simulates a vintage computer, as opposed to using a vintage computer directly) and, if so, what they use emulation for. Having used, owned, programmed on, and contributed to emulators for very many machines over a long period of time, I had a lot to say. What follows is a slightly expanded version of what I replied back to him. For the purpose of this article, I define “emulation” as “interacting with software running in a virtual environment that mimics the physical environment the software was originally designed to run under“. I also define a “work” as the software you are running in said environment, and is not limited to games (although most emulators are indeed used overwhelmingly for gaming).

For the TL;DR crowd: You need both vintage hardware and emulation to properly research something.

I’ve contributed to a few emulators in varying capacities over the last decade, and in that time, some of my emulation colleagues have expressed surprise when I mention that I have a large collection of functional vintage machinery (both personal computing as well as console gaming) hiding in my crawlspace, and that I rotate pieces in and out on a regular basis for both enjoyment and research. This is not a statement against emulation; some emulators are packed with features that make interacting with the original works very easy and flexible (such as DOSBox, MESS, and MAME) while others are dedicated to accuracy to extreme levels (such as bsnes). The state of most emulation scenes today is thriving and most emulators are quite stable and practical to use as a replacement for the real thing.

So if that’s the case, why maintain so many physical machines? It’s because emulation can only go so far. No matter how good the emulation is, you can’t change the fact that you are running a work on a physically different computer than what it was designed for. For most works, this is perfectly acceptable, but there will always be something missing no matter how good the emulator is. In my vintage computing research, I use a mixture of both emulation and real machines so that I can reap the benefits of both. To illustrate this, I’m going to explain the advantages of both emulators and vintage hardware.

Vintage Hardware Advantages

People who never had access to vintage hardware, and always have success running software inside their emulators, sometimes can’t understand what is missing when you emulate, even using one as hyper-accurate as bsnes. Most emualtors handle the obvious (CPU and Video display subsystem) well, because those are required for basic operation; they also handle CPU “speed” and system timing well, as mishandling them would prevent performance-sensitive software from running properly. So what’s missing? Here’s a short list:

• Video display properties: Color temperature, screen curvature, scanlines, response time, phosphor layout, phosphor speed. All of these are important in the best gaming monitor, some more than others. Vintage game graphics were composed with all of these properties in mind, from color choices down to individual pixel placement by the artist. If you are viewing a classic game’s graphics on a progressive display, the end result can be either too bright or too dim, over-saturated or under-saturated — no matter the outcome, it’s definitely not what the artist intended. Thankfully, this is changing thanks to ever-increasing GPU power in the form of plug-in shaders. But as awesome as modern shaders are, they can’t overdrive hardware. Anyone doing serious research on vector arcade games absolutely must see at least one in person to get a feel for just how bright and intense the vectors can be. (I personally recommend the mint-condition Asteroids currently operating at the Galloping Ghost arcade — very bright, currently no burn-in.)
• Interface properties: Input device layout, button placement, tension/stiffness, etc. This is just as important for computer emulation than game console emulation, because computers have input devices specialized for general-purpose computing (keyboards, mice) and not gaming. For example, some games on the PC used F9 and F10 for lateral movement in games, which initially doesn’t make any sense until you look at a vintage 83-key PC keyboard and see that F9/F10 were located at the very lower-left of the keyboard — optimal placement for gaming with the left hand. And younger Mac users may wonder why classic mac games only use a single button until they physically see why. This is most easily fixed by connecting vintage input devices directly to the machine performing the emulation, although such connections can range from a commercial adapter to a homebrew wire-wrapped monstrosity. But it’s worth the effort, so that you can see why Intellivision or Colecovision games require you to quickly navigate menus using the 1, 3, 7, and 9 keys (look at the controllers, you’ll see what I mean).
• I/O properties: Because most emulation research is in the field of gaming, little attention is paid to emulating I/O as it was on the original hardware, such as the speed of the storage subsystem, any noise it made, and so on. (In fact, most emulators attempt to speed up I/O as much as possible so that programs load much faster than they did on the original hardware.) Some emulators make noise, such as WinUAE, but the overwhelming majority do not, and I think that’s a shame. For gaming, I/O isn’t usually a concern, but for any historical research, it can provide a visceral response that would otherwise be missing.

This last one is hard to understand, so I’ll provide a real-world example: When playing the game Wizardry on a real Apple II or IBM PC, it loads from a single floppy disk frequently while the game progresses, to load new graphics, maze data, etc. due to the computer’s memory being smaller than what a floppy disk holds. Wizardry is a role-playing game, which lends itself to repetitive tasks: Enter dungeon, explore new area, fight party of monsters, etc. As you play Wizardry on these systems, you begin to recognize, either consciously or subconsciously the floppy disk access patterns — the “whirr, thunk, buzz” noises coming from the drive — for these repetitive tasks as the game runs. Open a chest, “thunk”; go down a level, “thunk-THUNK whirr thunk”, you get the idea. Now, imagine that your party is wounded and desperately heading to get to the surface to heal, while navigating an unfamiliar dungeon trying to avoid conflicts. You K)ick down a door, and instead of the familiar “whirr thunk” of finding an empty room, or “whirr buzz thunk” of finding a chest, you hear “whirr buzz thunk-thunk BUZZ THUNK THUNK-THUNK-THUNK-THUNK” and realize, with growing horror, that the game is loading a lot more data than usual because it is trying to put a bone-crushing, game-ending party of monsters behind that door. But my example doesn’t end there! Not only is the I/O subsystem contributing to a real feeling of anxiety and dread, but it is also offering you a choice: If you act quickly enough, you can “dive for the drive” and pull the floppy disk out, preventing the game from loading the data it needs to seal your party’s fate. This works because Wizardry only saves your progress at two places: When you die (which in this example is in about two seconds from now), or out of the dungeon, back in town. Ripping the disk out means you unfortunately lose your progress since the last time you saved, but more importantly it cheats death — and in Wizardry, death is (mostly) permanent, even across saved games.

Emulation Advantages

For vintage gaming research, emulation provides many benefits that the original hardware would struggle with, or in some cases, are impossible. My favorite emulation advantages are, in order of importance (to me):

• Instant searching. Software loads quickly while emulated, so you can sample one game a minute, faster if you’re organized and a quick typist. This is great if you’re trying to blow through 50+ games looking for something (a game character, a programmer or graphics artist in the credits, a specific gameplay mechanic, etc.) Handy for answering quick historical questions.
• Interchangeable hardware. For PC emulation, any combination of video and sound standards can be quickly loaded and tested. Trying to do this with vintage hardware is time consuming and very costly (you try buying every single vintage sound card ever made from ebay!) My most common use of this is listening to all of the different ways a composer tried to optimize a game score for a specific hardware device. For example, load a game that uses 8-note polyphony with a MIDI device, and then load it again with the 3-voice Tandy/PCjr audio chip and hear how the musical elements were scaled down to a drastically limited output device. This practice can also lead to some interesting discoveries, such as how Rob Hubbard bit-banged a single SN76496 channel to make it perform like a crude DAC on Tandy machines, leading to some music soundtracks you can only hear properly on that platform.
• Easy video and audio capture. While audio/video capture is not a substitute for the real thing, it is excellent for quickly illustrating gameplay mechanics or concepts to an audience that can’t (or won’t) run emulators. Capturing video or audio from real vintage hardware ranges from “easy and high-quality” to “nearly impossible” (requiring hardware modification to tap the necessary signals for capture).
• Expanded capabilities. Emulation can enhance your experience of a work, which can greatly increase your enjoyment or appreciation of it. My favorite example of this is playing early multiplayer serial/modem/IPX games, or even 2-player game console games, across the internet with another player. In the 1980s, if you wanted to play a console or computer game with another person, you both had to be physically present. In the case of computer hardware, you had to connect computers via a serial cable, a modem connection over phone lines, or some other wacky physical connection such as a MIDI cable. The difficulty of establishing connectivity limited the experience. Nowadays, that situation has completely flipped — connectivity is standardized and widespread across international boundaries. Emulation bridges what the vintage hardware expects with what the real world can provide, and makes it possible for two people to play the same vintage console or computer game as if they were sitting side-by-side.
• Inspection. I absolutely love this. Many top-flight emulators have an embedded debugger that allow you to pause the emulated system, inspect memory and registers, set execution breakpoints/conditions, and more. This is an absolute boon to researchers (and preservationists, who wish to “crack” copy-protected games so that they can survive past the failure of their media). This has answered a great deal of historical questions for me, from why Galaxy Player is the fastest in the world on 8088 (answer: saturated register additions + self-modifying code), to how some vintage games manipulate a 3-D virtual space and calculate rotation and perspective transformations (answer: Just like everyone else, with matrix math and nine MULs, but with a 16.16 fixed-point worldspace and 256 degrees per circle instead of the usual 360).

So there you have it: You need both vintage hardware and emulation software to get a better picture of what you’re researching.

(Note that I didn’t say “to get the full picture”, because it’s impossible to get the “full” picture of a particular work. The “full” picture would conceivably include facets of the work that may be impossible to obtain, such as experience with the social and political direction of the time period in which the work was created, the background of the people who created the work, the business and financial pressures that led to the funding of the work and controlled its motivation and direction, etc.)