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."
I don't care how many times the triforce spins. Seriously.
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?
I love bsnes. Performance mode only takes about a Pentium 4. It performs perfectly. No crashing or heavy visual glitches. The sound works great. The qt UI was nice, much better than the hacked together UI of zsnes, but I haven't tried the newer phoenix UI. If you have the processing power, there is no reason to put up with zsnes's glitches, crashes, sound problems, or any other quirks any more.
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?)
3GHz for a SNES? Makes you wonder just how accurate MAME actually is.
Then again, when you go as for as photographing a rom chip under a microscope, I guess there's no doubting the level of dedication.
Summation 2
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.
That's not emulation, that's having the actual hardware. You may as well just build a whole snes...
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
If you take an old game that ran on a TV screen and emulate it in fullscreen on a modern PC, you will see every pixel clearly.
You never saw those on the TV. The pixellated Super Mario character was designed with the signal to noise ratio of an old TV in mind. When a modern emulator does not blend these pixels together like old blurry TVs did, the graphics look more blocky than they ever did originally. I can still see this in emulated computer games as recent as monkey island 2, which I originally played with a CRT monitor.
AFAIK, the resolution and post-processing needed to emulate the old screens faithfully is actually a bit demanding.
Do you mean something like this?
It doesnt matter what platform the emulator is running on (pc, ps3, Wii, even the official virtual console titles) or what's being emulated (nes, snes). The timing is off on every single one.
What NES game glitches up in Nintendulator? Or which timing test ROM shows different results in Nintendulator vs. on an NES?
I know some games' graphics appear to have been designed with TV output in mind. Old consoles take shortcuts in generating a composite video signal. These shortcuts produce visible artifacts, and a few games take advantage of these artifacts by placing pixels in odd places to produce richer textures with more apparent colors than the system can produce at once. NES emulators at least have been emulating TVs for years. I almost can't tell the difference between a game running on an NES displayed on my Vizio TV and the same game running in Nestopia on a PC hooked up to the same TV.
preferably with an RGB mod
Unless your game is like Blaster Master for NES and uses the composite artifacts to fake more colors. I'll grant that this was less common on the Super NES than on the Genesis and NES due to the bigger palette of the Super NES.
To play rare or impossible to find titles, just download the ROMs
Which publishers offer such lawful downloads?
"Computers need to be very fast to emulate something slow enough to be accurate."
Yeah, I don't see anything wrong with that theory. It's kind of like how I always drive my Ferrari at 5 miles an hour because it's more accurate than riding a bicycle.
A much better /. car analogy is the "best" most "modern" way to emulate a ford model T, oddly enough involves a very elaborate and expensive CNC machine shop, because you can clone replica parts. If the engine block casting had a 0.0001 warp, the CNC mill can include that "mistake" in the new part. If there was a slag inclusion in the piston, the CNC lathe can take a little divot out to screw up the balance to maintain "prototype" vibration levels. If the prototype way to build something was dumb or dangerous, the robot will do it exactly.
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
Super Mario Bros 3.
We didn't have NES, but that was the only game me and my friends consistently played. Even 20 years later I still can play the original on NES like nothing happened. The emulators are 99.9% there, but in tricky spots or when jump timing counts, they don't work right. Mario slides just a bit too far or jumps a bit too fast.
If you want perfection, use the real games and the actual hardware, preferably with an RGB mod and a CRT display
There's a downside to perfect picture quality. Developers relied on the crappiness of composite video; they used dithering to create transparencies and extra colors, especially on the Mega Drive.
Circumcision is child abuse.
If you want perfection, use the real games and the actual hardware, preferably with an RGB mod and a CRT display
It's possible you didn't read the TFA thoroughly, because the author discusses this point. One of the reasons to strive for perfect emulation is preservation (of the original gaming experience) as the (abundant, for now) hardware becomes scarce. At some point, very few people will have the actual working hardware. What then?
From TFA:
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.
Or a game like Ninja Gaiden on the NES, where your jumps and attacks had to be perfect down to the millisecond... I have used many emulators and the game is completable but you have to compensate for the lag or extra speed depending on the emulator and its a pain.
I think FCE Ultra on the Wii with no filters turned on is pretty close to perfect NES emulation with the Wiimote. Like you say 99.9% but still not perfect.
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!
Just check the Atari ST emulators which are capable of doing overscan. This is so timing dependent that the CPU has to be emulated cycle precise.
Most do it scanline by scanline, only one, AFAIK does the real job: SainT (windows only)
Atari rules... ermm... ruled.
To play rare or impossible to find titles, just download the ROMs
Which publishers offer such lawful downloads?
Have you ever heard of the Wii Virtual Console?
There's a list of publishers that use it somewhere, I'm sure.
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
We'd need to emulate the physical circuitry. That would be expensive CPU-wise, but should be somewhat parallel-able (?) and as CPUs get better, this might become closer to reality.
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
Picture a curve at about 3.5mhz. Now picture approximating that curve digitally, which you can never do exactly as the sample size approaches infinity close to 0.
The closer you get to being accurate (the "graph hole" where sample size is 0) the faster and faster you need to perform these calculations if you wish to do this all in realtime.
Does this make more sense?
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
Mario slides just a bit too far or jumps a bit too fast.
I program NES games as a hobby, and I've never had a substantial problem with the physics in my own games differing between when the game is run on an emulator and on an NES.
I can suggest two different causes for what you observe. It could be failure in muscle memory due to not using an authentic controller. A keyboard will have a completely different feel than a gamepad, and the directional pad on many PC gamepads (even Microsoft's own Xbox 360 controller) makes it too easy to press diagonally when you're trying to press straight. So when I play-test my own NES games on an emulator, I make sure to use an authentic Nintendo 64 or PlayStation controller connected through a USB adapter.
Another problem is lag. Modern multitasking operating systems are optimized for throughput and generality, not latency, and this leads to buffer bloat. It might take several frames between when you press a button and when you hear the result.
Have you ever heard of the Wii Virtual Console?
Grandparent mentioned "rare or impossible to find titles". Let me know when Earthbound makes it to VC.
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.
If you want perfection, use the real games and the actual hardware, preferably with an RGB mod and a CRT display: http://www.chrismcovell.com/gotRGB/index.html
To play rare or impossible to find titles, just download the ROMs and use something like this to play it on the actual hardware: http://krikzz.com/severdrive.html
The problem with both of these issues, and IMO the point behind emulators, is that hardware does not have an infinite life. You're already seeing NES consoles out there with dead PPUs, controllers so worn that they're unusable, hell, I'd wager 90% of the machines out in the wild need their capacitors replaced. I'm picking on the NES, sure, but it's well along the path that all our beloved console stuff will travel down. There were a huge number produced, but that number is certainly not infinite. Eventually there will be no hardware to be had and the only way games for them will continue to exist is if they're virtualized in emulators.
On an aside, while I don't own any, I've heard that those with review and prototype carts out there won't even power them up in fear that they might discover the EEPROMs have degenerated and its contents have disappeared into entropy.
More Twoson than Cupertino
while being X times smaller and using 1/3rd of the power
That's progress, I agree. (For the avoidance of doubt, by "work" I was referring to progress through a computation, not dissipated heat.)
it was designed using the P4 and it does not represent modern technology
Then what set-top boxes do represent modern technology? I was under the impression that products such as Acer Veriton still had Atom CPUs. Or are you in the "set-top PCs don't exist" camp?
and no other functionality was introduced into the i386 architecture
To which specific new functionality introduced between Atom and Core i series do you refer?
http://www.fpgaarcade.com/
More focused on older arcade systems at the moment, but since it's powerful enough to "be" an Amiga computer I figured it's probably powerful enough to be a NES, SNES, TurboGrafx-16, Neo-Geo, etc
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.
Not to spout "RTFA", but the author addressed this exact point. He points to DICE, the Discrete Integrated Circuit Emulator, which simulates classic games on the transistor level (including propagation). So, this is pretty much as accurate as you can possibly get, unless you want to emulate on the atomic level.
How is performance? Well, one of the primary games it emulates (on the physical circuitry level, of course) is Pong. The original. Modern computers aren't quite fast enough to run it at full speed, although it's getting there, and the latest version is reportedly playable on high-end hardware. Pong didn't even have a CPU, so imagine how hard emulating an NES's 6502 in real-time... The author actually mentions this as well, he mentions Visual6502, an emulator that emulates on the transistor level but doesn't bother simulating propagation delay. So it cheats a lot for performance. How fast does it run? They report the Python version runs at 27Hz. To emulate an NES, ignoring the rest of the hardware, the 6502 needs to run at 1790000 Hz. That's quite the gap to bridge. If we assume the Python version is a tenth the speed of a C++ implementation, and then go by a Moore's law doubling of performance every 18 months, it will be about 20 years before a modern computer is fast enough to emulate *JUST* the NES CPU on the transistor level, and even then an incomplete emulation that ignores the propagation delay of electricity.
What does this have to do with the emulation topic at hand?
TFA makes it sound like syching between threads is an open problem.
It's not.
And pipelining / OOO execution has next to nothing to do with synching between two cores, which operate on a much, much coarser level of granularity.
RTFA. You're working on entirely different levels. The amount of 'thinking' involved in emulating a 20 year old video game console is, obviously, below trivial for a modern PC (or graphing calculator, frankly). If we're going to continue with the metaphor, accurately emulating a NES is more a problem of emulating the precise eccentric way in which it thinks. Anyway, there's a perfectly good technical explanation of why it's a problem right behind the link in the summary. It's written by a guy who's been doing this for years. Just go read it.
Driving a Ferarri at about the same speed as a bicycle isn't all that hard. Driving the Ferarri behind a bicycle at *exactly* the same speed such that the front bumper of the Ferarri is always exactly 1mm away from touching the spinning rear wheel of the bicycle, that's a lot harder. Now add a motorcycle behind your Ferarri trying to do the same thing, and a segway behind the motorcycle, and a battle tank behind the segway, and a skateboard behind the battle tank, and you might start to appreciate how hard synchronization can be.
Which is why people who own such carts and refuse to get them dumped (whether to be released publically or not) deserve to have them stolen, dumped (for preservation), and returned. Luckily, there are far less such people than in the past. They don't realize that if they get the media backed up, they can revive their cart when it does succumb to bit rot.
FC Closer
Obviously not, and if you'd bothered to actually read the article, you'd know why, instead of being snarky because "oh look everyone else uses snes9x or zsnes, this guy is a nutter".
SNES9x sucks. ZSNES sucks. Every other SNES emulator sucks, because they don't aim for accuracy. Same reason that C64 emulators like PC64, C64S, etc have gone by the wayside, while emulators like Hoxs64, VICE, and CCS64 are at the top of their game. Or why Nesticle was supplanted by modern emulators like Nestopia or Nintendulator.
When it becomes impossible to develop software for a platform because no emulator is accurate enough to reasonably determine whether or not your software is likely to run on the original hardware, there is a major problem. These types of edge cases are mostly used to push the system further than originally designed. To go back to C64 emulators, sure, older ones like PC64, etc would run 99% of games pretty good. But, you throw advanced demoscene stuff at it, things that work perfectly on real C64s, and the emulators would barf up shit. Even a couple of years ago, someone found out how to display a 9th sprite on a C64 scanline, on the far, far right (see: Krestage 3/Crest). Even the most accurate C64 emulator, Hoxs64, did not support this because until then, the "common sense" was that you just can't put more than 8 sprites on a scanline.
This is where I encourage the development of a demoscene (however small but dedicated) for all of the classic-style systems where the CPU more or less runs in lockstep with the video signal. Demosceners tend to find out how to abuse the hardware registers at just the right time to generate a specific effect, and without cycle accuracy those effects just don't work. I've long felt that demos can be amongst an emulator programmer's best testing tools when comparing behavior to the hardware being emulated. Look at stuff like the old Sid Mania SNES demo from Censor Design, which was one of the first major releases for the SNES that had sound. Even today it emulates best on bsnes (big surprise) and sounds like ass on ZSNES.
FC Closer
very coincidentally, I was having a conversation about Atari 2600 emulation last night, and it was suggested that "perfect" emulation of the early consoles might be impossible due to the change from CRTs to LCD TVs (and monitors).
The culprit in this case is the latency added by digital displays (and PC style video hardware) and packet-based input devices (USB, etc).
On pre NES hardware like the Atari 2600, the games would (at times) be synchronized to the video output signal of the CRT (see for a discussion), and they also had specialized video hardware which often did collision detection between various video elements (sprites, missiles, backgrounds, etc) meaning that results were detected as the frame was outputted, and available to the game code instantly .
This *can* be emulated perfectly by the emulator/ PC CPU
But these games ran their main loops at 60 hz (or 50 for PAL), and many of them required near perfect reflexes and timing.
Once the emulator has completed and rendered a frame of the old console game, how long until the player actually sees the result?
The answer is: It varies.
Will there be a 1/60th second delay before the video card swaps the rendered frame to the front buffer?
And how long will it take for the front buffer to be sent over HDMI/DVI to the LCD Tv set or PC Monitor? another 1/60th of a second?
And how long before the TV or monitor actually displays the frame? Another 1 or 2 60ths of a second? more? (The TV/Monitor takes time to buffer, filter/process and scale the image). You usually don't notice this on TV sets because the audio is buffered and delayed so it stays in sync with the video.
And now that the next frame is finally visible to the player, he/she can sees that they need to react to save their on-screen character, so they press the controller appropriately.
And how long does it take the USB adapter/controller to send to a packet to the PC, and for the PC to process it and make it available to the emulator? Compare that to the original hardware where pushing a button or joystick caused an individual circuit to open/close and whose status was polled immediately and directly by the console CPU. Maybe it's fast enough, maybe it adds another frame of latency.
In the end, with emulators we likely have a longer feedback loop from the emulator to the display to the player to the controller and back to the emulator compared to the original console and CRT displays, and many old games just won't play the same as a result.
We can emulate the game perfectly from the standpoint of the hardware simulation and audio/visual display, but still not get the play experience emulated perfectly because of changes in the feedback loop to the player.
how did we get to set top boxes?
The article is about emulators that run video games that were originally designed to run on specialized computing devices connected to a television. I've been told by CronoCloud and others that most people don't connect a generic PC to a television. Instead, they connect specialized devices to a television, and such devices are commonly called set-top boxes. The closest thing in the PC camp to a set-top box that I'm aware of is an Atom-based home theater PC.
and if you dont know the differences tween an atom and a i7 I am not going to spend my time educating you
A disagreement on burden of proof.
I suggest you google it
I tried atom performance per mhz, atom vs i7 benchmark and atom i7 performance single thread, but nothing on the first page of results of any of the queries answered my question. Because the Atom and i7 are in entirely different market segments, there don't appear to be any pages comparing the two. It took a change in my strategy (Google p4 i7 performance single thread) to pull up this forum thread claiming that the i7 executes roughly twice as many instructions per clock per core as a P4.
besides I said 386 and i7
I fully agree with you that there were numerous upgrades between a 386 and a P4. But earlier I had said the performance per cycle was comparable between a P4 and an Atom, so I was using the P4 and the Atom as a baseline for comparison.
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.
I guess they think a cartridge in a Schrödinger superposition of working and not working is worth more money than a cartridge that has been observed not to work.
Not likely. Unless they were pushing for a certain effect, they would have been designing these games on developer systems which were 1980s computers, complete with component video and progressive scan.
The question is how much do things like this add to the experience, vs. giving me headache from all the flicker. FWIW, I never noticed scanlines with old consoles, but then again I only ever had European TVs.
They don't work with all games though, that's the point.
Also, the SNES has a 3.5 MHz CPU, not 33 MHz.
Mada mada dane.
that is awesome
The Admin and the Engineer
No, the problem is there's no such thing as "perfect" emulation. The same way music from phonographs won't be exactly the same when they're converted to MP3s, by definition emulation will never be the same as the real thing. From differences in how the game is emulated, to using different controllers or different display technology, there is no perfect emulation. It can come close though, and in that respect emulation has succeeded.
Freedom is drinking a beer in the park when you're supposed to be at work.
Yes, I know this and I read the whole site too. But in most cases, the positives outweigh the negatives. Things like color bleeding and soft pictures that obscure the detail in backgrounds are far worse than noticeable dithering.
Freedom is drinking a beer in the park when you're supposed to be at work.
Dude, computer games (and many other types of applications) have dealt with this exactly same problem for decades. It's nothing new, and the solutions aren't new either.
There's no -1 for "I don't get it."