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.
Or is this just some guy's blog about how emulators aren't up to par with actual hardware? There's no question being asked here.
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?)
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. It's close, payable most of the time, but it isn't a full 100% accurate reproduction.
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.
No love for snes9x ? I may be behind the times but it was awesome.
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
on a website powered by apache!
on a computer powered by AMD.
on a system created by software 'engineers'
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.
seriously you do, they are great fun and can do things with (to) you..... over time you will stop thinking about such matters as spinning triforce animations....
I had problems with grim fandango that were solved by forcing it to use one core in windows with imagecfg. Or does the problem sit deeper than just the number of cores?
Do you mean something like this?
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
But if you want portability and don't care about accuracy, you go with emulation.
Freedom is drinking a beer in the park when you're supposed to be at work.
Attempting to rely on today's multi-core processors leads to all kinds of timing problems.
No, not at all, unless you're practically trying intentionally to screw it up. I've done a lot of work on emulators, admittedly mostly for DEC and IBM big iron, and the other extreme of emulating embedded microcontrollers, rather than video games. But video games are pretty simple compared to a large virtual mainframe installation.
The way you use multi-cores is the same way you use multi-cpus. One core/cpu does all the "thinking" and the other cores/cpus do ALL the behind the scenes heavy lifting. For example, the cpu emulator process/thread/hardware cpu does NOT handle local file access, it does NOT handle the real machine's "audio interface of the month", it does NOT handle whatever video-graphical-console interface the real machine provides, it does NOT interact with the real machines window manager, it does NOT process the real world machine's network packets. If your "CPU emulator" core/proc is also responding to pings from the real LAN, you're doin it wrong (or at least you need to buy more cores/procs, etc).
If the emulated machine had multiple processors or some peripheral processor, then you can run the FPU or keyboard controller or graphics proc or whatever on a separate real core/processor. Each call involves a tick counter, and each call ends with a loop waiting for the tick counter to hit the correct value before returning "done" status to the main.
Even the main machine needs a tick counter, and some sleepy calls. Crude systems do some arithmetic on the RTC to see how many ticks have been processed vs should have been processed and then sleep till then, maybe every X ticks. Advanced systems have a sleepy routine each and every tick, and a synthetic PID controller that adjusts the sleepy routine rather often. The fanciest systems which are usually too slow for videogames or realtime use "real time" for each instruction, including modeling of the current position of the disk drive arm and the suction level of the tape drive pumps and such.
Someone who's challenged by the concept of atomic transactions is going to be confused by them in emulators, just like they'll be confused by them in database transactions or any other app. Same deal with semaphores, fixing deadlocks, etc. There's nothing "really tricky" about programming emulators vs anything else.
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
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.
"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
Power is measured in watts, not hertz.
Get a hold of a 200mhz Pentium Pro... I played ZSNES on that computer when I was younger as that was my first PC. All of my 8/16bit emulators ran fine. When I upgraded to a SocketA Athlon XP 2500+ years later, I noticed that games ran faster than on my old PC.... so it could be that your PC is just too fast...
Previewing comments are for sissies!
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.
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.
I would say the high latency accessing the HW on a modern PC is a significant problem. Older consoles and home computers had almost zero latency between reading an input device and moving the speaker coil, or lighting the electron gun in the CRT.
Now though there are tens of milliseconds delay between sending infomation to the graphics card and having it displayed by your LCD. Audio can be even worse.
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.
They want to make it look shitty and perform badly, so it can be "faithful".
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.
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.
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.
SNES9x was always my favorite emulator. I thought it was much better than ZSNES
It's been a while, but have you tried dosbox or any other software that "slows" the performance of your processor?
I used it a lot on old ms-dos games to battle speed/timing troubles.
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
MAME recently added this sort of thing in.
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."
Finally! Someone else besides me likes Snes9x more than Zsnes. While it's nowhere near as "accurate" as Bsnes, the sound uses Blaarg's S-SMP/SPC700 core, which has been test side by side to a real Snes. There is no perceptible difference between Blaarg's sound emulator and the real hardware; this is one major advantage over Zsnes. In fact, Zsnes is so popular, people don't notice how games such as Super Mario World or the Final Fantasy series sound like crap compared to Snes9x. The Mario jump-spin, Mario warp pipe and shrink/grow sounds, Square Enix sound effects, overall even tempo of music is perfect in Snes9x and Bsnes. Zsnes 1.51 is five years old and Zsnes 2.0 is currently "being worked on". It truly is the Windows Vista/Internet Explorer of Snes emulators; their overhyped popularity cannot be explained despite their major flaws. I'd be more than happy to make audio.video comparisons between Zsnes 1.51 and Snes9x 1.53 for any skeptic out there.
Star Fox and any SuperFX game runs twice their normal speed on Zsnes
Star Ocean's battles are impossible to control in Zsnes, not to mention random lockups
To sum up: Zsnes' lack of proper Sony SPC700/S-SMP emulation makes my ears bleed as much as Rebecca Black, Rick Astley and Justin Bieber all at once.
Listening to Snes9x's exponentially more accurate SPC700 emulation has been known to cure depression.