State of SNES Emulation - 2010

SNES emulation has been around for approximately 15 years, and over time there have been many great emulators. How do things shape up in 2010? By: Evan G Last updated: September 16, 2010

Opening statement

There are about 20-25 SNES emulators that have been developed over the years, though only a few ever got to the point where they could be considered usable for general gaming. For many years, SNES9x and ZSNES competed for the crown of the best SNES emulator, though in 2010 there are several other options that might be considered for the enthusiast. I guess you could say that this article is a followup to this old thread by Matthew Kendora in which he violently left the scene. Shortly afterwards, at first reiterating the issues, byuu decided to start developing BSNES, which intended to fill the void of an accuracy focused emulator. Much research has solved a lot of the problems stated in Matthew Kendora and byuu's analysis of SNES emulation in 2004.

In my article, I bring forth the experience as a pure end user. I have only a fragmented knowledge of how the SNES works, but because of this website, I am inclined to use several emulators for different purposes. I also think that it would be beneficial for other end users to have a proper overview of SNES emulation. As with the two articles written in 2004, I expect some of what I say to be controversial, and I state that everything here is strictly my opinion.

Another reason I am writing this is as a response to the journal article by Guttenbrunner et al. (2010) about preserving hardware and software from non-supported older systems in a digital format. The article focused on SNES emulation, and I feel they did a poor job researching available emulators (leaving out BSNES, for example), and using arbitrary standards for determining "accuracy". Notwithstanding my distaste for "open source" journals, I feel that a proper peer review by experts in the field would have revealed the errors in this article. I don't claim that my article is an exhaustive look at the accuracy of emulators, nor the state of digital preservation, but I hope that my efforts on SNES Central go further in preservation efforts than their attempts.

For a reference, this is the base specs of my computer that I used for my tests:

My computer specs, a HP Pavilion laptop, the specs which you can see on HP's website. I'm running the 64-bit version of Ubuntu.

For all emulators, I used Super Mario World as a test game, because it was the most widely distributed game during the reign of the console. I tried to get an action screenshot for each emulator, to try and illustrate the speed that it was running. The following emulators were used in the main tests: BSNES 0.68, SNES9x 1.52, ZSNES 1.51 and MESS 0.169.

BSNES

Byuu's BSNES is an emulator under heavy active development, which is both a good and bad thing. Probably the main issue is that downloading a new version of BSNES makes you feel much like a beta tester. And sure enough, many BSNES releases are bug fixes that probably would be found if there was any semblance of a testing phase. That being said, there is no doubt that BSNES is an impressive emulator that is very close to simulating the original hardware. My three year old laptop is pushed to the max with BSNES, and I certainly could not get full speed (60 FPS) with the default settings (using the performance core). Despite adding options for the level of accuracy, without going through the settings, you are not going to get full speed in Linux with a computer like mine. Once I switched on the OpenGL video mode, performance was a lot better. That isn't to say that I consistently got full speed, as the FPS fluctuated between about 55 and 60 FPS. One issue to note when setting up BSNES is that the settings require a program reset to be applied. A warning message would be a helpful future addition.

As for options, the thing I liked best was the debugger. It is a bit ambiguous on terminology, but it does what I need it for (finding when certain memory addresses are accessed). There are three compatibility modes, though it is unlikely that anyone except people with a high end computers will be able to take advantage of the "accuracy" and "compatibility" modes. There are a variety of filter methods, though I'll admit that I prefer the regular "square pixel with smooth video output" mode, which gives you a nice clear image. BSNES saves the last folder you were in, though it does not have a convenient listing of the last few ROM images loaded. BSNES also has Super Game Boy support, and emulates many games that no other SNES emulator can handle. There really are only three rather obscure games (with special coprocessors/DSPs) that BSNES cannot play.

Perhaps the most interesting twist of the BSNES project are various extensions that really don't have much to do with emulation itself. For example, the MSU-1 is a feature that allows you to make a SNES game that is up to 4 GB in size. Though certainly it is intriguing to think what could be done with a SNES game of that size, it is highly unlikely that any hardware implementation will be made to actually make this useable on a real SNES. If the goal of BSNES is to stay true to SNES hardware, it seems like an unusual thing to implement in the emulator. Aside from a handful of exceptions released late in the life of the Super Famicom (none in other regions), all SNES games are 32 Mb (4 MB) and lower in size, and the theoretical maximum for a SNES cart is just over 100 Mb. To exceed that is to make a game that is not a SNES game, but a BSNES game. Byuu's stated intention is to get people interested in making SNES games, however considering that even with MSU-1, you must program the game in pure assembly, there are likely to be few who will ever use this platform.

Another thing is the SNES Preservation Project. The goal of it is to redump every SNES game and make scans of the labels, PCBs, boxes and manuals. Anyone who has been following my work on SNES Central knows that I have been working on this very thing for many years. Such a project is unlikely to be completed in the spare time of a single person, though byuu has made it clear that he does not seek collaborators, essentially saying the efforts of others are not "good enough". Part of the motivation for this project is that there is no recording of the PCB types for many games (though my PCB archive numbers into the hundreds at the moment). However, all the information that the PCB tells you is stored in the internal header of SNES games (this was required by Nintendo, see chapter 2 of the official SNES Development Manual). Most other emulators will read the header information to determine the mapping of the loaded ROM image, and as of now, BSNES is no exception. I know that there are exceptions to this rule, but how is having an external list of PCB types any different than some internal recognition of a particular game that strays from the header standard? In both cases, one has to make a determination of how the game works. I also think that byuu significantly underestimates the amount of time to actually do such a preservation project to a high quality. To tidy up a US SNES cart label properly (like this) takes me approximately an hour, and that is only if there are no significant defects on the label.

In addition, most SNES games have already been correctly dumped. In my sampling of approximately 350 SFC and SNES carts that I personally dumped, I found two games that were considered incorrect by NSRT (a popular ROM image auditor), one of which was discovered before me, the other by Fitzroy previously. For most popular games, they have been dumped by various people many times to confirm their authenticity. Such a verification project would have made more sense ten years ago before groups like the NSRT team and No Intro came about. I think efforts instead should be focused on acquiring and dumping one of a kind prototypes and unreleased games that are on EPROMs, which have a much shorter shelf life than commercial games with MASKROMs.

In summary, BSNES is an excellent SNES emulator, and is a program that should be nearly finished. Anything added in the future is likely to be completely superficial. For example, the accuracy mode with dot based rendering will require a high end computing environment. This begs the question, if that level of accuracy is required, why not spend the money on a flash cart and play the game on a real system? Certainly, that is the choice I have made, and it provides me with 100% accuracy without any worry about computing system requirements. I also think that adoption of BSNES as the emulator of choice would be greatly improved if the author was a bit more diplomatic.

BSNES with my system monitor running. BSNES consistently uses at least 80% of a single CPU, and really pushes my computer hard. (click here for larger version)

SNES9x

Long thought to be dormant, a team led by zones made considerable strides to improve SNES9x, and released version 1.52 earlier this year. I've been told that a new version is upcoming as I write. It is wonderful to see this classic emulator still being worked on, and the GTK interface programmed by BearOso is elegant. Significant upgrades include a new sound core made by blargg (similar to the one that is in BSNES), the creation of a new savestate architecture and improved support of various coprocessor and DSP add-ons.

Like BSNES, running SNES9x 1.52 is not seamless out of the box. The graphics are choppy and the sound does not keep up on my computer. At first, I mitigated this to a certain degree by turning of "synchronize with sound" option. However, once I turned on the OpenGL rendering, SNES9x ran as smooth as butter, with no frame dropping or skipping.

As an end user, SNES9x offers pretty much anything you could want. It has a speed advantage over BSNES, allowing it to be played on somewhat older hardware. As you can see from my system monitor test, it uses less processing power, and does not come close to maxing out my computer. The sound is very close to a real SNES (if you listen to older versions of the emulator, you could hear defects in sound effects in games like Final Fantasy VI). There are a variety of scaling and filtering options, and though I haven't tried it, Netplay support. Unlike BSNES, it also has a list of recently played games for ease of navigation. There is less sacrificing of accuracy in 1.52 than previous releases, so I imagine it might have problems running in full speed on much older computers, though it is not as severe as BSNES.

SNES9x with my system monitor running. SNES9x consistently uses on average about 50-60% of a single CPU. (click here for larger version)

ZSNES

Next in my list is ZSNES. Really, if you look at the last release date (January 2007), ZSNES shows its age, but it remains the most well known and popular SNES emulator. Originally conceived to be playable on computers from the late 90s, ZSNES still remains an option for older hardware. Though development is still active, some issues in the core of the emulator have led to a delay in a new release.

From a user perspective, ZSNES is an easy to use emulator, and should not require any optimization to get games running at full speed. On the Linux side, I had to play around with the sound settings to get it to sync up properly (basically by forcing it to use SDL sound). I won't go into too much detail on features, as I'm sure most people reading this article will have used ZSNES at least once. Though some complain about the interface, the file load dialogue retrieves file names far quicker than any GUI API in Linux. I also have to say that it still has the best laid out options menu system of any SNES emulator. The emulation is not perfect, though, and I can't really recommend it over SNES9x 1.52, which has superior sound quality.

ZSNES with my system monitor running. ZSNES has low system requirements, and does not push my computer much at all. (click here for larger version)

MESS

MESS, or the Multiple Emulator Super System has a stated goal of being the equivalent of MAME for console emulation (and is in fact built upon the MAME architecture). MESS attempts to be as accurate as possible, requiring images of chips on the SNES to work. However, I think that requiring something like the DSP3 image goes a bit far, considering it is used in one game (the emulator refuses to start without the image file). The one file that is required for all games is the SPC700 image, which is required to initialize the sound processor. In making this article, I found out that every other SNES emulator actually includes the image file within the binary (even BSNES), something that might be considered illegal. MESS is also a command-line application (though there are some frontends that I did not try) and has a very rigid file structure that does not allow you to run the binary from a standard $PATH location like /usr/bin without changes to the setup. Like with SNES9x and BSNES, in order to get full speed I had to set it up to run with OpenGL.

When trying to get MESS to work, I remarked that it "sounds like they are trying their best to discourage people from using it". think it is very true. MESS is not geared towards a general end user such as myself, but as an accurate emulation archive of various machines that happen to play games. In that regards, MESS is not the best SNES emulator, and though Super Mario World seems to work fine, I ran into glitches playing other games. I've heard that MESS intends to incorporate parts of BSNES into it, but at that point you might as well just use BSNES.

screenshot taken of MESS

The "Battle Blaze" test

Battle Blaze is a game that requires careful and accurate timing, otherwise the introductory scene will glitch. I think this serves as a good test to see how accurate an emulator is. Assuming BSNES is accurate, it features a darker colour scheme than the other emulators, and it is indeed the only emulator of the four tested that does not glitch in this scene. MESS follows behind BSNES is accurately displaying this intro, with only the "Battle Blaze" title glitching (moving rapidly from side to side). SNES9x also has the title moving rapidly from side to side, and also has line glitches through the flames. ZSNES is the worst of the four, with the flame effect not working properly at all, instead staying static and shaking from side to side. Unfortunately, I don't have a proper power adaptor to try it out on a real SNES for comparison.

Battle Blaze in BSNES 0.68	Battle Blaze in SNES9x 1.52

Battle Blaze in ZSNES 1.51	Battle Blaze in MESS 0.169

Super Sleuth

Another emulator that I thought I should mention is Super Sleuth. Developed by Overload, it was an attempt to create an accurate emulator, though it hasn't seen an update in two years. The emulator runs about three times too fast, with no obvious way to mitigate it (at least in my test with Windows Vista). There doesn't appear to be any sound as well, which would also turn off a general user. It was the only other emulator to pass the Battle Blaze test, though. It is Windows only, but it did work in WINE.

Super Sleuth in action

SNESGT

SNESGT is a SNES emulator written by Japanese programmers, Gigo and Hii. There is an English port, and plays most games glitch free. It hasn't been updated since 2007, so it probably has been abandoned. I've heard it has the best Satellaview emulation of any SNES emulator, though I have not tested this. It certainly is less known than SNES9x and ZSNES, but it holds its own in quality. I tested the emulator in Windows Vista, but it did not work in WINE.

SNESGT in action

JSNES

JSNES is a Java emulator first released about a year and a half ago by spiller. It is not a very full featured emulator (note the alpha state), but it does have graphics working fairly well, and sound is working (if glitchy). One thing I liked about JSNES is that in the preview window, it will actually load the SNES game and play it while you are browsing. Though this certainly isn't going to compete with the main three emulators, it is a nice example of what a hobbyist can do.

JSNES in action

Closing remarks

In 2010, SNES emulation is better than ever, with BSNES approaching near perfection, and SNES9x providing a highly compatible emulator for the general user. In fact, the time to declare perfection of SNES emulation may be approaching. Small increments may be possible (i.e. dot based rendering), but considering the tradeoff in computing power, it might be better to literally design new SNES compatible hardware (especially considering that the patents on SNES hardware are starting to run out). With near perfect accuracy in achieved in some emulators, it is not to say that no one should pursue programming an emulator, as it can be a rewarding hobby (see spiller's Java SNES emulator). With documentation improving, it actually is becoming easier for anyone to write their own emulator. There will always be various niches that need to be filled, such as tool assisted speedruns that go beyond simply emulating games. However, I think that care should be taken not to extend emulators too much, or programs and hacks might be developed that can only work on emulators, and not a real system. And if accuracy is key, then that policy should be followed.

Ultimately, everyone should remember that the SNES is a gaming machine, and that games are meant to be played. And similarly, using an emulator should be a means to experience the greatness of Nintendo's 16-bit machine! I personally use SNES9x 1.52 for general usage, but I don't think you can go wrong with other emulators mentioned in this article.

Bibliography

• The International Journal of Digital Curation, Guttenbrunner, M., Becker, C. and Rauber, A., 2010. Keeping the game alive: evaluating strategies for the preservation of console video games, Publication date: June 2010, Volume: 1, Pages: 64-90