In cases like this, we would have to get more selective with our tests and try to determine exactly when flags might change, when results might overflow, and so forth. If the CPU had 32-bit x 32-bit multiplications, it wouldn’t be practical to test all combinations of inputs before the heat death of the universe (with current technology, at least). Testing every possible value would generate 4 billion results, which is starting to push what is practical to test in a reasonable amount of time. Now let's say the CPU had 16-bit x 16-bit multiplications. Then we could modify our emulators so, when running the same test, we produce exactly the same tables at the same times. Let's start by taking a look at the components that make up the SNES:īy analyzing these tables, we could determine exactly how and when the CPU results were set certain ways. If you're still intrigued, read on for a deep dive into the background of the problem and my proposed solutions. No stone was left unturned, no area left unfinished. I want this final piece solved so that I can feel confident in my retirement that the SNES has been faithfully and completely preserved through emulation.

I'm getting older, and I won't be around forever. I can tell you why this is important to me: it's my life's work, and I don't want to have to say I came this close to finishing without getting the last piece of it right. As with any goal in life, the closer we get to perfection, the smaller the returns. If you're not interested in the pursuit of one hundred percent faithful emulation perfection for its own sake, I am not going to be able to convince you of the need for improving SNES PPU emulation further. The remaining issues are relatively small ones, in the grand scheme of things. We mostly know how the PPUs work, but we have to make guesses for some functionality that result in less than total perfection.

The sole exception is the PPUs (picture processing units), which are used to generate the video frames sent to your screen. Today, we enjoy cycle-level accuracy for nearly every component of the SNES. So that's it, right? Kudos on a job well done, thanks for all the fish? Well. Dynamic rate control for perfect audio-video synchronization.Low-level emulation of all SNES coprocessors.Some amazing things have come out of SNES emulation recently, including: SNES emulation has gotten so precise that I've even taken to splitting my emulator into two versions: higan, which focuses on absolute accuracy and hardware documentation and bsnes, which focuses on performance, features, and ease of use. Barring unusual peripherals that are resistant to emulation (such as a light-sensor based golf club, an exercise bike, or a dial-up modem used to place real-money bets on live horse races in Japan), every officially licensed SNES title is fully playable, and no game is known to have any glaring issues.

Today, SNES emulation is in a very good place. But first, let me recap how far we've come. Getting that final bit of emulation accuracy will require a community effort that I hope some of you can help with. We are now at a point where that goal is in sight, but there we face one last challenge: accurate cycle timing of the SNES video processors.

Further Reading Accuracy takes power: one man’s 3GHz quest to build a perfect SNES emulatorAs the lead coder of bsnes, I've been attempting to perfect Super Nintendo emulation for the past 15 years.

Bsnes emulator near