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."

Comments

Not a problem at all

[vlm]

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.