Slashdot Mirror
A Quest For the Perfect SNES Emulator
An anonymous reader sends this excerpt from the Opposable Thumbs blog:
"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. ... 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. ... The primary demands of an emulator are the amount of times per second one processor must synchronize with another. An emulator is an inherently serial process. Attempting to rely on today's multi-core processors leads to all kinds of timing problems. Take the analogy of an assembly line: one person unloads the boxes, another person scans them, another opens them, another starts putting the item together, etc. Synchronization is the equivalent of stalling out and clearing the entire assembly line, then starting over on a new product. It's an incredible hit to throughput. It completely negates the benefits of pipelining and out-of-order execution. The more you have to synchronize, the faster your assembly line has to move to keep up."
Isn't the chipsets used just about out of patent, and thus allowing perfect emulation by including a copy of the chips used on a USB device?
Haha, yes. I can't wait for the new wave of emulators that make you blow on your hard drives before your roms will work.
I played a lot of SNES games when I was a kid. Then I played those games when I was older in an emulator (it's easier than dusting off the console).
Any difference is pretty much minor detail. Your memory won't really tell you stuff you see in a modern emulator is wrong, because most people doesn't memorize the amount of time a triforce takes to spin around, and probably doesn't care as long as it shows OK.
I think you only need emulation that faithful when you are actually writing software for the SNES using an emulator. (Hey, it happened for the NES, why not?)
I must have been using ZSNES for over a decade now, possibly even longer. Snes9x was pretty good, too. I never had much of an issue with either emulator, as far as I was concerned, it played the games and it played them just fine. The odd glitch, maybe, but nothing that put me off completing a whole bunch of games I played as a kid, or missed out on.
However, I do agree with the author of bsnes that "just fine" isn't really acceptable when you want to preserve the computer you're emulating, not just play some games. I believe MAME takes a similar approach, aiming for accuracy rather than speed (Which is why it runs mostly in software and not hardware, hence 3D games like Tekken run very slowly) as MAME is primarily about preserving the games and not just playing them.
Computing power isn't really an issue, computers will only get faster and faster over time. The computers in use 10 years ago would be eclipsed by even a mid-ranged smartphone today. In 10 years from now, when there's even fewer working SNESes out there, it's good to know that the code will be portable to whatever machines we have at the time and that it'll run games as they're intended. It's not unthinkable that someone might unearth a previously unknown SNES game cartridge only to not be able to find a SNES to play it on. bsnes may well be the only emulator capable of playing it, for one reason or another.
+1 IDisagreeSoHeMustBeATrollOrAnAstroturferOrAShill
3GHz is a measure of frequency, not power. Words mean things, use them correctly.
You seem to be missing the point. The triforce spinning was probably a bad example, since it's not that important. The problems with inaccurate emulators range from annoying visual glitches, to crashes, to actually making a game unbeatable. Star Ocean, for example, will sometimes crash in zsnes, but I haven't experienced that in bsnes. The battles run at double speed, much like the triforce in LTTP. Playing Yoshi's Island in zsnes, any level with those giant fuzzballs will tick every time you move. It's nauseating to get through. In zsnes, Super Mario RPG battles will sometimes de-sync to the point that the music and animations will continue, but your input will no longer work and you have to reset the game.
In Speedy Gonzales - Los Gatos Bandidos, if you're playing with zsnes, you can't even beat the game, because it doesn't emulate everything necessary to do so. In Sink or Swim, the room fills with water, and you need to swim above it. But because of timing and speed issues, the room fills up much too fast and you will drown instantly.
You can read about some of these issues, and many more, here: http://byuu.org/bsnes/accuracy
It's been done for the gameboy. There was also an article series about how it might work featured on slashdot a while back.
Well, there is a difference. Here's a ZSNES emulation of the LTTP intro, which you can compare with the Speed Demos Archive run. SDA don't actually accept emulator runs, so the video there is from an actual SNES.
Now, the TAS videos run doesn't display the same problem, but that was probably run from Snes9x, not ZSNES(technically from a custom Snes9x build supporting re-recording). So the issue is not the processing power required but simply the fact that the Snes9x and ZSNES developers focused on different features.
Overall, it can be seen from all three videos that in general, a good emulator can emulate the underlying hardware with extremely high fidelity for the vast majority of games and gameplay.
Fidelity isn't a burning issue in modern 8 or 16 bit emulation. Emulators are now literally concerned with advanced features like recording, "rewinding", and video and audio filters that actually improve the games graphics and sound beyond what the hardware was capable of. The only outstanding feature I personally feel is missing from most emulators is cross platform support.
May the Maths Be with you!
The real question is: When will we have a JavaScript emulator ?
It's called the Opera browser. It's runs JavaScript but it's not quite the real thing.
But how much time do you seriously spend in the GUI of the emulator? As long as it plays the game, I would be happy running it from the command line.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
Do you mean something like this?
MAME isn't accurate, it's just badly coded. Accuracy is an excuse the current developers use because they're not actually very good programmers, and many of the performance issues just boil down to poorly implemented core features.
To get a like-for-like comparison, MESS is a side-project of MAME using the MAME code to emulate consoles. It has to rank as one of the worst in terms of both performance AND compatibility. It's actually slower than BSNES and has a compatibility rate worse than ZSNES of 10 years ago.
The MESS emulation of the SNES is using code from MAME because MAME emulated the SNES for the Nintendo Super System arcade system. This demonstrates how MAME is a prime example of an emulator where the developers have adopted a 'good enough is good enough' mentality. Once the software they want to run works the developers consider it consider it 'good enough'
With arcade platforms that approach holds up in 99% of cases, each platform usually has only a small number of games running on it, and most users don't have the prior knowledge of the titles to analyse them with extreme scrutiny. When their code is taken and used to emulate systems like the SNES where details are important, it fails. It fails in a similar way when it comes to Playstation, Jaguar, Sega, Amiga and the majority of others too. All you read about Tekken 3 being slow in MAME because the emulator is focused on accuracy holds no weight when you look at the actual accuracy and compatibility rate of the Playstation emulation provided by MAME via the MESS project.
BSNES is slow because Byuu has masterfully crafted an accurate emulator which emulates the SNES at a level indistinguishable from the real hardware, comparisons with MAME which is just the fruit of shoddy programming, ill-designed subsystems and a poorly conceived development vision are disrespectful.
I say this as somebody who has submitted code to MAME to fix issues found in MESS and has observed some of the horrors and inexplicably gross hacks and inefficient functions to be found in the MAME code while they continue to claim 'accuracy' as the reason for performance woes.
Fidelity isn't a burning issue in modern 8 or 16 bit emulation.
Fidelity is the only thing that matters. Compare any emulator besides Nestopia or bsnes to the real thing. It's not there yet.
Emulators are now literally concerned with advanced features like recording, "rewinding", and video and audio filters that actually improve the games graphics and sound beyond what the hardware was capable of.
They really shouldn't be. Recording can be done by external apps. Rewinding, meh, that's just cheating. And video and audio filters never look or sound as good as the real thing.
The only outstanding feature I personally feel is missing from most emulators is cross platform support.
I can think of more emulators with cross platform support than emulators without. In almost every case the best emulator for a platform is open source and cross platform. The only exception I can think of is SSF.
Personally, I think emulators are very important. And accuracy is especially important. But while the hardware is still here and in working condition, I play everything I can on real systems. With the help of mod chips or flash carts as needed. It's superior in every way to emulation.
Give me Classic Slashdot or give me death!
Some guy? Byuu is the author of the finest emulator yet created. He's not asking a question because he knows the answer. He's speaking from his own expertise.
Give me Classic Slashdot or give me death!
The real question is: When will we have a JavaScript emulator ?
It's called the Opera browser. It's runs JavaScript but it's not quite the real thing.
Internet Explorer's JScript would be a better example.
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
over zsnes. the sound dev for zsnes if i remember correctly is also the head dev for bsnes. both now require oss4.0 on linux for sound, he infact refuses to code zsnes to the specs and documentation on zsnes on purpose to push people to oss4(as in he calls the devices directly rather then through alsa-lib so library can do sound mixing on non hardware sound mixing cards for example). This is a no go for me due to what the company behind oss and oss4 did. years ago oss was the only sound system for linux, what people in the foss movement and people running linux in particular did not know was the company behind oss was just using them for free code debugging and feature improvement. Once the code matured to something that they could sell they closed off any more code improvements to the foss crowed and started selling their work. this royally pissed off a lot of people, enough that alsa was made so linux would always have a sound system that can't be yanked out from under them like that.
years later the same company comes out with oss4, promising they won't do what they did before. the past experience plus the fact that some of the code in oss4 uses stuff that the kernel devs have now decided does not belong in the kernel as it could allow a single program to hard lock the machine. prevents it from being allowed in and not get the tainted kernel status which means your bug reports will be ignored. because of this the oss4 people like the one who makes bsnes and codes the sound system for zsnes cry 'i'm being prosecuted for using a Superior system!' alsa isn't perfect but it's better then the alternative that can and will get yanked out from under people once they deem it so after pulling the same trick again.
so in short if oss4 is required for 'accuracy' i will take inaccurate but functional any day.
The Super NES CPU could run at two different speeds: 2.7 MHz and 3.6 MHz. The slower speed was for accessing RAM, as well as for accessing ROM while in slow mode. Flipping a bit would put the CPU into "fast ROM mode" where it could access ROM at the full 3.6 MHz speed. (A couple registers related to the controllers take even longer to access.) In addition, some emulators don't properly count the cycles that an instruction takes in all contexts. This would cause an emulated CPU to finish a method in fewer cycles than the actual CPU uses.
Of course, the Pentium-M is much less performant clock-for-clock than a modern Sandy Bridge i7
By how much? After many blind alleys on Google, sandy bridge "pentium M" benchmark eventually brought me to this comparison. I chose Intel Core i7 2657M, Intel Core Duo T2250 (representative of Pentium M microarchitecture), and Intel Atom D525, all dual core and all at roughly the same 1.6-1.8 GHz clock. Performance for the i7 appears twice that of the Core Duo, which in turn is twice that of the Atom.