Take XboX 360 for example. It shares nothing more than a name tag with the original Xbox console. This makes the modern Xbox 360 system not backwards compatible with it’s predecessor, which can be disappointed for early adapters that invested in the original console and games just to find out that they cant run them when they upgrade to the 360.

To address this, Microsoft created and Xbox emulator for the Xbox 360 platform, making possible for the seamless integration and running the old games under the new hardware. Sony on the other hand uses the actual physical components of it’s original Play Station to make playing games for it possible on the latest Play Station 3 console. However, some versions of the 60GB Sony Play Station for the US market lack original Play Station 2 CPU, but have the original graphic subsystem. So in order to make PS2 titles executable under the Play Station 3, Sony uses partial emulation to replace the missing CPU, achieving something of a hardware and software emulation mix. Finally, the engineers of Sony perfected the emulation process, making PS3 capable of running PS2 titles on pure software emulation, thus removing the need for dedicated PS2 hardware in the PlayStation3 and reducing the manufacturing costs considerably

Another way of this type of emulation is even used by big game development studios. They often use software emulation techniques to reissue more popular older game titles and exploit their popularity further by making them run on modern consoles. A good example of this approach is the Final Fantasy series, and it’s developer, Square Enix. They recently re-released this popular series on modern day consoles such are Game Boy Advance, Nintendo DS and Sony Play Station Portable. Another developer who did this was Sega, who created bundle pack of their popular titles from the Sonic the Hedgehog franchise.

But most popular commercial emulation package has to be Nintendo’s own emulator called the Virtual Console. Virtual Console comes preinstalled on their latest generation entertainment system, the Nintendo Wii, and it successful emulates Nintendo’s most popular titles from classic consoles such are the original Nintendo Entertainment System, it’s successor, the Super Nintendo Entertainment System, Nintendo 64, but also consoles from their main competitors Sega – Sega Master System and Sega Genesis (called Sega Mega Drive outside United States). Nintendo’s Virtual Console also successful emulates games from NeoGeo, Amiga’s Commodore64, early PC’s and various arcade games as well. Nintendo also used emulation for the various Game Boy Advance (GBA) re-releases of popular Nintendo Entertainment System games in their famous Classic NES series. This clearly shows that emulation technology is not something reserved for hackers and home users – large game studios and developers often use it themselves.

That’s not a typo: if you want absolutely mathematically perfect emulation, you need hardware that’s not even invented yet. And it’s not the fault of DICE – it’s in fact a highly optimized program, and it’s using all instruction sets of modern CPU’s very well. The problem is rather in the fact that simulating every transistor instruction from the hardware Pong was created to run on is an incredibly daunting task that requires massive processing power. But since the knowledge needed to emulate games at this level is already there, all that’s left is for the hardware to catch up, so we can be optimistic – it’s only a matter of time before common, every day processors of the future will be able to produce 100% accurate emulation. This will make those hard core classic game enthusiasts happy.

Obviously, using the same approach that DICE emulator uses when attempting to emulate a bit more modern computer systems poses some issues. Let’s take Visual6502 as an example. This CPU was used by such popular systems like Nintendo and C64, some early Amiga home computers and others. Using an approach like previously described DSP extraction makes high-level of simulation for this processor possible, and the emulation code that was produced this way has been known to run in C and JavaScript. The fact remains that computers are just not fast enough to run emulated hardware by using this approach, no matter how accurate it might be.

Although in the perfect world, every emulator would support every last bug and quirk and emulate them all down to the smallest function of the least significant transistor chip, in the real world this just isn’t going to happen. That’s why most emulators aim for the sweet spot of over 90% accurate emulation. This makes most games run good enough most of the time, but has an added and practical benefit of being possible to run on almost all hardware. The perfect low level emulation is still a pipe dream. It’s safe to assume that the processing power of computers will not increase enough to make emulating fairly old consoles, like Nintendo 64 on low level possible for the foreseeable future. Even emulating older hardware than Nintendo 64, for example SNES at this level is not likely.

Its often the case that these additional processors are so detached from the main processing unit that it’s actually possible to implement them using hardware emulation, or high-level emulation to be exacts. This isn’t the case just for the co-processors used in the Super Nintendo. The case is similar when it comest to Nintendo 64 video code emulation, and some other areas as well.

It’s important not to think about this in terms of individual hardware instructions. You need to look at the big picture, and focus on trying to replicate behaviors of entire subsystems together. By employing this approach, it’s possible to emulate specific behaviors and operations with no overhead at all. But this approach also has it’s drawbacks, the main one being that by working this way, it’s difficult to retain the timing information that is required to properly execute specific individual instructions. But what’s worst is that the emulation is still far from perfect, since minor flaws and bugs that make each system unique will be lost in the translation.

That was the high-level emulation approach, or HLE. The low-level approach to emulation OS to treat those co-processors just like you would treat the main processing unit, and to execute every instruction every time. This results in the accurate replication of the timings, and the games emulated this way don’t run faster than they were intended to. But this puts much more strain on the hardware that’s running the emulator. When using low-level emulation, a game like Super Mario Kart will run almost a third slower than a game like Super Mario World, just because the former uses co-processors in it’s original iteration. When emulating through a high-level approach, both games run just as smoothly.

This obviously shows that low-level emulation is an intensive process, and it’s no wonder that most commercial and free emulators today use high-level emulation to make things run smoothly across a variety of modern hardware.

Back in the nineties, personal computers became powerful enough to make attempting to recreate the behavior of some entertainment consoles technically realistic and entirely feasible. The first console emulators appeared in this period. The emulators of that time were often incomplete, buggy and unpredictable, but this is understandable, considering that most of them were non-commercial and almost amateurish attempts at hardware emulation. Another reason why those early attempts were mostly failures was that it was rare for console manufacturers to publish technical specifications for their consoles, forcing would be emulator developers to reverse engineer the consoles on their own. Most common platform that was emulated at that time, and the one for which the most advanced emulators were developed early on was Nintendo – specifically the Nintendo Entertainment System, the Super Nintendo Entertainment System, and the all popular Game Boy.

Some of the early popular emulators of that era were Virtual Game Boy, iNes, Pasofami and Super Pasofami, and VSMC – all for various Nintendo’s consoles. There were even attempts to recreate the behavior of Nintendo’s Entertainment System on then modern Sega Mega Drive, making this the earliest known attempt to recreate the behavior of one console on another, or cross-console emulation.

The sudden spike in the popularity of console emulation on PC’s made playing games that were exclusive to the Japanese market and hence never released in the United States due to Nintendo’s copy write policies possible for a huge community of gamers. The rapid rise in interest in emulation also helped grow communities dedicated to ROM home brewing, hacking and fan translation. The release of projects such are fan made translations of popular Japanese language only titles made games that would never see playing time outside of Japan into huge hits, and some of those projects are in use even today.

Unfortunately, copy write laws and licensing issues are still the main issues that plague the emulation community. Under the US legislation, in order to posses and use a dumped copy of a BIOS, you need to legally obtain the original machine that the BIOS was developed for. For a lot of platforms, this is no longer possible, but several emulators are able to run without the actual BIOS file, by simulating the function of the BIOS itself.

The simple answer to this is: Accurate emulation teaches us things that we might not yet know about popular software. Let’s take an example. Everybody knows the Legend of Zelda – along with Mario Bros, it’s one of the oldest and most popular games that were ever created on any classic platform. Everybody who ever played Zelda for any period of time remembers the spinning tri-force animation sequence from the game opening. Now, take that snippet of animation and compare the way it looks and runs on any two different modern emulators. In this example, lets take two that everyone is familiar with: ZSNES and bsnes.

When you run Legend of Zelda on ZSNES, you’ll notice that the animation in question runs way to fast to be considered accurate. The tri-forces will spin way to fast on ZSNES because the ZSNES emulated CPU is running at almost 50% more speed than the processor in the original Super Nintendo Entertainment System. This may look like small details, but just imagine trying to avoid and dodge projectiles that some boss is shooting at your game character. Everyone knows that was made to be as hard as possible, and you really don’t want them to run almost 50% faster.

Dozens of games developed for older computers suffer from weird little quirks. It’s often the case that the correct way of emulation that is supposed to be closer to the original will actually produce a result that looks and feels wrong. Take Super Bonk for an example. it’s demo desynchronizes, causing the player to get stuck close to a wall on most real systems. Star Fox suffers from serious slowdowns throughout all the levels of the game. No one actually wants games to act this way, but those are actually the correct results. Trying to emulate just what we consider good and getting rid of the more difficult aspects of classic computer titles would be like trying to round up the number Pi down to two decimals.

The advantages of treating vintage games as a bases that can be improved on with modern knowledge and means are obvious. If you are going down this path, you can make Nintendo 64 games that run at high definition 1080p upscaling and have high-resolution textures, and also enable anti-aliasing while you are at it. The games emulated this way will look better than the original, and while there’s nothing wrong in trying to use all the advantages of modern hardware, it’s something of a missed point. To “improve” games classic games in this way will make the possibility of accurate, correct emulation that more difficult, if not impossible, and most users like classic games exactly for their quirks and that retro look anyway.