How can it take 3GHz to emulate a Super Nintendo? The man behind a major SNES …

Share this story

Emulators for playing older games are immensely popular online, with regular arguments breaking out over which emulator is best for which game. Today we present another point of view from a gentleman who has created the Super Nintendo emulator bsnes. He wants to share his thoughts on the most important part of the emulation experience: accuracy.

It doesn't take much raw power to play Nintendo or SNES games on a modern PC; emulators could do it in the 1990s with a mere 25MHz of processing power. But emulating those old consoles accurately—well, that's another challenge entirely; accurate emulators may need up to 3GHz of power to faithfully recreate aging tech. In this piece we'll take a look at why accuracy is so important for emulators and why it's so hard to achieve.

Put simply, accuracy is the measure of how well emulation software mimics the original hardware. Apparent compatibility is the most obvious measure of accuracy—will an old game run on my new emulator?—but such a narrow view can paper over many small problems. In truth, most software runs with great tolerance to timing issues and appears to be functioning normally even if timing is off by as much as 20 percent.

So the question becomes: if we can achieve basic compatibility, why care about improving accuracy further when such improvement comes at a great cost in speed? Two reasons: performance and preservation.

First, performance. Let's take the case of Speedy Gonzales. This is an SNES platformer with no save functionality, and it's roughly 2-3 hours long. At first glance, it appears to run fine in any emulator. Yet once you reach stage 6-1, you can quickly spot the difference between an accurate emulator and a fast one: there is a switch, required to complete the level, where the game will deadlock if a rare hardware edge case is not emulated. One can imagine the frustration of instantly losing three hours of progress and being met with an unbeatable game. Unless the software does everything in the exact same way the hardware used to, the game remains broken.

Or consider Air Strike Patrol, where a shadow is drawn under your aircraft. This is done using mid-scanline raster effects, which are extraordinarily resource intensive to emulate. But without the raster effects, your aircraft's shadow will not show up, as you see in the screenshot below. It's easy to overlook, especially if you do not know that it is supposed to be there. But once you actually see it, you realize that it's quite helpful. Your aircraft has the ability to drop bombs, and this shadow acts as a sort of targeting system to determine where they will land.—something that's slightly more difficult without this seemingly minor effect.

The second issue is preservation. Take a look at Nintendo's Game & Watch hardware. These devices debuted in 1980, and by now most of the 43 million produced have failed due to age or have been destroyed. Although they are still relatively obtainable, their scarcity will only increase, as no additional units will ever be produced. This same problem extends to any hardware: once it's gone, it's gone for good. At that point, emulators are the only way to experience those old games, so they should be capable of doing so accurately.

But this accuracy comes at a serious cost. Making an emulator twice as accurate will make it roughly twice as slow; double that accuracy again and you're now four times slower. At the same time, the rewards for this accuracy diminish quickly, as most games look and feel "playable" at modest levels of emulator accuracy. (Most emulators target a "sweet spot" of around 95 percent compatibility with optimal performance.)

There's nothing wrong with less accurate but speedy emulators, and such code can run on lower-powered hardware like cell phones and handheld gaming devices. These emulators are also more suited for use on laptops where battery life is a concern. But there's something to be said for chasing accuracy, too, and it's what I've attempted to do in my own work. Here's why it matters to me.

Doing it in software

Back in the late '90s, Nesticle was easily the NES emulator of choice, with system requirements of roughly 25MHz. This performance came at a significant cost: game images were hacked to run on this emulator specifically. Fan-made translations and hacks relied on emulation quirks that rendered games unplayable on both real hardware and on other emulators, creating a sort of lock-in effect that took a long while to break. At the time, people didn't care about how the games originally looked and played in general, they just cared about how they looked and played in this arbitrary and artificial environment.

These days, the most dominant emulators are Nestopia and Nintendulator, requiring 800MHz and 1.6GHz, respectively, to attain full speed. The need for speed isn't because the emulators aren't well optimized: it's because they are a far more faithful recreation of the original NES hardware in software.

Now compare these to the older N64 emulator, UltraHLE, whose system requirements were a meager 350MHz Pentium II system. To the casual observer, it can be quite perplexing to see Mario 64 requiring less processing power than the original Mario Bros.

My experience in emulation is in the SNES field, working on the bsnes emulator. I adored the ideal behind Nestopia, and wanted to recreate this level of accuracy for the Super Nintendo. As it turns out, the same level of dedication to accuracy pushed requirements up into the 2-3GHz range, depending on the title.

TimeCop, on two very different emulators

Nestopia caught on because its system requirements were paltry for its time, but I have no doubt that releasing it in 1997 would have been disastrous. Since my emulator ultimately required a computing system with more power than half the market, I've seen first-hand the effect of high system specs and the backlash it causes. It's easier to blame the program than to admit your computer isn't powerful enough, but the reality is that faking an entire gaming console in software is an intensive process.

Why accuracy matters

So if an emulator appears to run all games correctly, why should we then improve upon it? The simple answer is because it improves the things we don't yet know about. This is particularly prominent in less popular software.

As an example, compare the spinning triforce animation from the opening to Legend of Zelda on the ZSNES and bsnes emulators. On the former, the triforces will complete their rotations far too soon as a result of the CPU running well over 40 percent faster than a real SNES. These are little details, but if you have an eye for accuracy, they can be maddening.

I've encountered dozens of titles with obscure quirks. Sometimes the correct, more accurate emulation actually produces a "wrong" result. Super Bonk's attract mode demo actually desynchronizes, causing Bonk to get stuck near a wall on most real systems. And Starfox suffers from significant slowdown issues throughout the game. These are certainly not desirable attributes, but they are correct nonetheless. We wouldn't round pi down to 3 simply because irrational numbers are inconvenient, right?

I don't deny the advantages of treating classic games as something that can be improved upon: N64 emulators employ stunning high-resolution texture packs and 1080p upscaling, while SNES emulators often provide 2x anti-aliasing for Mode7 graphics and cubic-spline interpolation for audio samples. Such emulated games look and sound better. While there is nothing wrong with this, it is contrary to the goal of writing a hardware-accurate emulator. These improvement techniques typically make it more difficult even to allow for the option of accurate emulation, in fact.

Another major area where accuracy is a benefit is in fan-created works from translators, ROM hackers, and homebrew developers. Few of them have access to run code on real hardware, so they will often develop their software using emulators. Unfortunately, speed-oriented emulators will often ignore hardware limitations. This is never a problem for a commercially developed game: upon required testing on real hardware, the bug would quickly be discovered and fixed. But if you can only test on a specific emulator, such bugs tend to persist.

I can name a few examples. The fan translations for Dragon Quest 1&2, Dual Orb 2, Sailor Moon: Another Story and Ys 4 all suffered invisible text issues as a result of writing to video RAM while the video processor had it locked out for rendering the screen. Only half of these titles have subsequently been fixed.

We've known about this hardware limitation since 1997, which consists of a one-line code fix, but the most popular emulator still does not support this behavior. As a result, translations made solely for this emulator continue to cause problems and lock-in. Who would want to use a more accurate emulator that couldn't run a large number of their favorite fan translations?

It doesn't stop there, though. The original hardware had a delay upon asking the math unit for multiplication and division results. Again, any commercial game ever released would respect those delays, but fan hacks led to a Zelda translation's music cutting out and to the Super Mario World chain-chomp patch going haywire.

Or an emulator might ignore the fact that the sound processor writes echo samples into shared RAM. Not a problem until you wind up with hacks that use wildly unrealistic echo buffer sizes, which in turn end up overwriting the entire audio program in memory, crashing and burning in spectacular fashion. This one issue single-handedly renders dozens of Super Mario World fan-made levels unplayable.

I found out that in ZSNES, battles actually run at about 50-100% faster than they should. Considering battles in SO are real-time, tactics are thrown out the window because you don't have enough time to react.

It's actually how i discovered bSNES, when someone recommended I try it instead. I've been using it since.

Always room for improvement in emulators but tbh the most important thing is that game is able to be played. A game that is not able to be played is useless and is wasting space on your drive. ZSNES and BSNES have both done great jobs considering.

I've been thinking for years of emulation like DICE uses (transistor level emulation), but I had no idea it would be that computationally expensive. It must be similar to software that Intel or AMD would use to test and debug CPUs before putting them into production.

Also, I loved the idea of scanning the physical chips and emulating them that way, it's even closer to virtual hardware! You'd almost think that all you'd need was the scan, no custom code at all, plug different processor scans in and out since all you'd really need code for was following the flow of electrons. Very exciting!

I agree that we need to emulate these old systems as close as possible for history's sake, but with the huge push towards emus on iOS/Android (as Exelius pointed out) I think it's going to be a tough road...

Quote:

Take the case of DICE, the digital integrated circuit emulator. Here is an emulator that works at the transistor level for absolutely perfect recreation of the very first video games ever created.

Bah -- come back to me when you're emulating at the atomic level, and then you'll have "perfect" emulation

When we're talking 3GHz, what does that actually mean? Do improvements to CPUs (a 3GHz P4 core doesn't match a 3GHz i7 core) matter at all, or would building CPUs geared towards emulation help? Could it be easily threaded and some of the upcoming 8+ core chips make incredibly light work of emulation?

Heh, I remember playing spy hunter 2 on an old 300mhz Pentium 2 computer, and it was either scaling it too fast or too slow. I played it on the too fast mode. Then, I actually liked it better that way since the normal pace wasn't as fun.

Remember too when was it Win98 was the last OS to have Solitaire run so fast it was done with the jumping cards in like 1 second, since it was originally designed in the old 12mhz days?

I'll have to try bsnes, as it seems no emulator does Super Mario RPG as I remembered it on the SNES. And unless my memory is wrong, even the port to the Wii seems ever so slightly off with the door open and close sound FX (I know about the changes in the static e effects and such).

I would have loved even more technical detail.. maybe some assembly code snippets or something.

I think people are missing the point of the article in complaining about the need to play these on iOS/Android, etc.. the value of these games is not necessarily to play them it's to preserve them, and the author recognizes the preservation is important. You can't place portability above preservation.. both are important but portability is useless without preservation.

with companies re-releasing games i am surprised the emulation market hasn't dried up.

Mostly because they have not re-released the whole library. They have barely scratched the surface added to the fact some games probably won't ever be ported *Mother 3 comes to mind, the best we can do is the fan translation*.

"And Starfox suffers from significant slowdown issues throughout the game. These are certainly not desirable attributes, but they are correct nonetheless. We wouldn't round pi down to 3 simply because irrational numbers are inconvenient, right?"

When we're talking 3GHz, what does that actually mean? Do improvements to CPUs (a 3GHz P4 core doesn't match a 3GHz i7 core) matter at all, or would building CPUs geared towards emulation help? Could it be easily threaded and some of the upcoming 8+ core chips make incredibly light work of emulation?

Given the image that shows multiple cores at a high percentage of usage, I'm assuming that it is already threaded. I have a feeling that the different processors that are being emulated each get their own thread (or more than one). Threading requires synchronization, so I bet that this is the synchronization that he is talking about. The difficulty comes down to how tightly the threads needs to be synchronized, and the article makes it clear that it must be exacting. But, I'm not an emulator developer and haven't worked on anything so low-level and complex, so I could be mistaken.

This was a fascinating article from a technical point of view, and also gives a good perspective on why emulation is important, and striving for accuracy in the emulation as well.

I found BSNES when I was looking for a better emulator to play Super Mario RPG. There were issues with using the "newer" version of ZSNES (the older version of which I had used for many years) so I had to keep the older one around. Keeping old software around is very unsettling... so when I found this I gave it a try and I have never looked back. It is very accurate and very fast. This comes into play with things like the Super Jump / Ultra-jump requirements for Mario's final armor, and whether or not the Equip menu would freeze when changing equipment, which could be quite frustrating even with a Save State feature.

So Byuu, you have my support and I have recommended BSNES to anyone looking for an emulator.

This reminds me of the work that was done in MAME, the arcade emulator. A lot of very smart people spent a great deal of time reverse engineering the hardware to preserve it. I was involed in the project for a couple years in the early 2000s and I was amazed at the diversity of talent it took to make the project sucessful. Fun times.

This reminds me of the work that was done in MAME, the arcade emulator. A lot of very smart people spent a great deal of time reverse engineering the hardware to preserve it. I was involed in the project for a couple years in the early 2000s and I was amazed at the diversity of talent it took to make the project sucessful. Fun times.

I could have sworn that MAME was sharing or planning on using the libsnes core(which is the core to BSNES). So, it comes to no surprise that you would be reminded of MAME.

"And Starfox suffers from significant slowdown issues throughout the game. These are certainly not desirable attributes, but they are correct nonetheless. We wouldn't round pi down to 3 simply because irrational numbers are inconvenient, right?"

I stopped reading right here.

Why? It would be rewriting history to change that. Imperfection is a part of everything, and it's part of the experience.

It's hard to empathize with this guy because his goals are so foreign to my way of thinking. I think of old games as being valuable property that should be preserved. I don't think of outdated hardware in the same way.

A console emulator should preserve the experience of the game, which is much more easily done by modifying a game's execution to get it to run accurately. I see very little reason to reverse-engineer and preserve the multiple quirks of an old hardware design. I'm sure Nintendo keeps a HDL file somewhere for posterity if you're worried about that.

"And Starfox suffers from significant slowdown issues throughout the game. These are certainly not desirable attributes, but they are correct nonetheless. We wouldn't round pi down to 3 simply because irrational numbers are inconvenient, right?"

Actually we do round pi down because irrational numbers are 'inconvenient'. However I did not stop reading because of a bad analogy... good article. I've been using ZSNES almost forever now, but I will likely give BSNES a spin in the near future.

I'm torn. I totally respect the effort and the output, and the article is interesting... but it's video games. Not nearly as important as the "life-or-death" tone of the article seems to imply.

That's not to denigrate the actual work that goes into something like this, but get a little perspective. Your entertainment desires aren't exactly the stuff of history no matter how much you love SNES roms.

I'm torn. I totally respect the effort and the output, and the article is interesting... but it's video games. Not nearly as important as the "life-or-death" tone of the article seems to imply.

That's not to denigrate the actual work that goes into something like this, but get a little perspective. Your entertainment desires aren't exactly the stuff of history no matter how much you love SNES roms.

People said largely the same thing about the work of Vincent van Gogh while he was still alive. The presence of his works in the world's most famous museums (and four of them on my own living room wall) would suggest that none of us is equipped to know exactly what will and will not become "the stuff of history."