BSNES has a somewhat different purpose to most emulators; it focuses on accuracy over performance. To that end, it does not include any game specific hacks, or idle-loop skipping optimizations commonly found in other emulators. To add to the fun, it uses a cycle accurate hardware emulation. The net result of all this is the highest system requirements of any software I've released to date; those without a G5 class machine need not apply. If you meet the requirements, however, this is the most accurate SNES emulation available on the Mac platform.

===



Unlike traditional emulators, bsnes strives to implement things in the most logical manner, rather than the most popular. Sometimes these changes prove a bit difficult, due to a dearth of information and tools on these changes. This guide will walk you through the concept and how to use either game folders or traditional files with bsnes.
Concept

Video games are more than just a ROM image. A typical game played in an emulator can contain one or more ROMs, save RAM, a real-time clock setting, save states, cheat codes, board mapping information, screenshots, debugging information, etc.

Traditionally, emulators handle this by using the basename of the ROM image (for "Starfox.sfc", the basename would be "Starfox"), plus a unique extension.

This of course gets very sloppy. In an attempt to organize, the next step was to have a list of paths to store each file type. I believe this was a huge mistake. It is inconsistent with just about every other concept in the PC world. To me, files should be grouped by game. Let's take a look at this in practice.


Would you group your images, music or movies by their file extension? When you install multiple PC games, do you expect all of their executables to go in one folder, all of their image resources to go into another, etc ... all jumbled up? Then why would you want your emulated games treated this way?

Some will say that one should have Starfox.zip that contains all of these files. But again, where else does that apply? Do you have a ZIP archive of all songs from a music CD to play them? Archives are a distribution medium to work around browsers' inability to download folders with server-side compression. For anything but emulated games, it is normal to extract these files after download. The OS handles collections of files better than any archival format could: it does this with a concept called folders. So why not take advantage of that, and make accessing the contents as easy as possible? And even if disk space for 2MB files becomes a concern, modern operating systems have compression built right in.

Just because something is more popular doesn't mean it is the best way to do things. We should always take the time to consider how things are done, and to change our ways if a more logical method is found.

Those from an OS X background are already using this concept, even if they are not aware of it. Applications in OS X are, in actuality, folders. The OS hides the .app extension, shows a nice icon, and lets you double-click them to start the application.
Benefit #1: easy sharing

Let's say you wanted to move a game to another device to continue playing it. With file grouping, you would have to go through multiple folders and pull out each file. With game grouping, you'd simply copy the game folder once.
Benefit #2: easy renaming

Say you wanted to be more specific, and rename "Mario.sfc" to "Super Mario World.sfc". With file grouping, you would have to rename every file. With game grouping, you would only have to rename the single folder.
Benefit #3: easy identification

It may not be immediately obvious what mario.cht is, but cheats.xml is pretty clearly a cheats file. You further know it is in XML format, meaning you can edit this file in a text editor if you so choose. Since the game folder has the game name in it, the file name is free to describe what the file actually is, and the extension is now free to describe what type of file it is. program.rom is a read-only memory image of the program. save.rwm is a read-write memory image of the game's save RAM.
Benefit #4: easy path configuration

With games in their own folders, the emulator no longer has to provide five or more path selections for each file type. They all go in the same place. No configuration is necessary out of the box.
Multi-system emulators

Five or so paths doesn't seem too odious. But bear in mind that bsnes is a multi-system emulator. So one would need five or more paths per emulated system, lest the user want to store games for unrelated systems in the same folder.
Alternate philosophy

You don't have to think of game folders as being the games themselves. For instance, BS-X Satellaview games are actually writable. The BS-X BIOS, in order to be emulated correctly, has to be able to write to them. Now you probably don't want your only pristene copy of BS Zelda to be modified, or deletable.

So instead, consider game folders to just have one additional save item in them: the program ROM. With these images averaging 2MB, it's hardly a big deal with today's 2TB+ hard drives.

Keep your game images as the archival set, and let bsnes play the game folders generated from them. Consider a game image to game folder conversion as a game installation from the install media.
purify configuration

Whether you want to use game files or game folders, you will want to get acquainted with purify. It's a tool that makes game folders that bsnes can play.

The first thing you want to do is choose your emulator. Point it at the path where the bsnes executable is located.

The output path defaults to your home folder. You can go with this, or you can change it to point somewhere else if you prefer. When purify converts a game image, this is where the game folder goes.
Working with game folders

So you like the idea of game folders, or are willing to give them a try? Great!

purify can be used to convert a folder of game images into a collection of game folders. It will not remove the game images, it instead makes copies of them.

Use the convert games option and select a folder full of game images, and purify will turn them all into game folders. If you navigate to the output directory with bsnes, you can now play your games directly from the GUI.
Optional Step

kaijuu is a Windows shell extension that allows you to simulate the way OS X handles application folders. That is to say, if you install the kaijuu extension, you can associate game folders with bsnes.

Now you can double-click a folder and open it in bsnes. Or you can right-click the folder and explore it. You've probably seen similar behavior when inserting a CD or DVD in Windows.
Working with game images

Not sold on game folders? Then use purify's play game option instead. In this mode, you can choose a game file, and purify will make a game folder copy and begin playing it. Even better, purify supports incorrect extensions (like SMC), copier headers, compressed archives, and so on and so forth!

Don't want to use the purify GUI to launch bsnes? Again, you're in luck! You can associate either bsnes or purify with your ROM images, so that when you double-click them, purify will convert them and open up bsnes for you automatically.

Best of all, you can do this every time. Your saves will be copied over on the first game folder conversion, and kept intact on every subsequent run. So you can treat the game image as the game itself, and not even concern yourself with the existence of game folders. In much the same way that you don't concern yourself now with the existence of save RAM files or cheat code files. They just work behind the scenes.

The only limitation at this time is that the bsnes GUI does not have a file browser. So you will have to close the emulator and load another game. I'm currently working through ideas on how to address this, so please be patient. 

===

kaijuu is a Windows context menu shell extension. The context menu is the list you see when you right-click on a file or folder. kaijuu allows you to add your own custom actions to this menu.

Think of opening an unknown file type: Windows will ask you to associate a program with the file type. From there forward, double-clicking the file will open the file with that program.

kaijuu is a far more powerful version of this same concept. With kaijuu, you can assign as many rules as you want. You can apply the same rule to multiple file patterns. You can have more complex pattern matching for names. You can apply rules to folders. You can specify rules about how to handle single-file versus multi-file selection. You can send custom command-line parameters to the program. You can have rules on a per-user basis. And you can do all of this from an easy-to-use GUI.

kaijuu is compatible with Windows XP and above.

===

bsnes :: Legacy Formats

bsnes is a personal project. I do not release it publicly for the sake of popularity. Rather, it is released as a research platform, in the hopes of advancing SNES emulation as a whole.

As such, there is no incentive for me to target popular legacy formats that are in wide use. Further, I am strongly opposed to the idea of sticking with inferior file formats simply because they came first. I prefer instead to focus on technical merits and choose the most logical options possible. It is not a matter of the complexity involved in supporting these old formats, it is that I feel a philosophical hypocrisy in eschewing these formats while implicitly endorsing their continued existence by supporting them.

On this page, I will explain my rationale for not supporting various legacy formats. I do not ask you to agree with me on any of these, merely to respect my choices. As bsnes is an open source emulator, you are of course free to make any modifications that you like, and even to distribute those modification.

I truly believe that many people tend to be very head-strong about these sorts of issues, so I ask that you please read this with an open mind, and let logic win out over passion and tradition.
File extensions

bsnes will only load SNES cartridges ending in the ".sfc" extension, BS-X flash cartridges ending in the ".bs" extension, Sufami Turbo cartridges ending in the ".st" extension, and Game Boy (Color) cartridges ending in either the ".gb" or ".gbc" extension.

The most popular SNES extension is ".smc", and this tends to be used for not only SNES cartridges, but also for BS-X flash cartridges and Sufami Turbo cartridges as well.

The reason ".smc" is the dominant extension is due to the origins of SNES software backups. The first mainstream devices to allow this were Chinese-based copiers, devices that would plug between the SNES and the cartridge, and copy games onto floppy disks. One of the first such devices was the Super Magicom. ".smc" is an abbreviation for this device.

Rather ironically, the Super Magicom was a rather niche copier, quickly supplanted by the Super Wildcard, Game Doctor and Super UFO copiers, which were much more popular. But following the initial images, other dumpers and even copiers chose to support this first extension.

But it is by no means the only extension. Here is a list of some of the most common extensions, as well as what they stand for ... this list is by no means exhaustive:

LIST

Believe it or not, all of these extensions are still in public use. To me, this is ridiculous. An extension should indicate what it represents. bsnes is not a Super Magicom emulator, it is a Super Famicom (SNES outside of Japan) emulator.

There is of course the pragmatic approach of simply supporting all of these extensions. However, I feel this introduces unfortunate downsides. First, consider how operating systems such as Windows handle file-assignment. It is based on extension. So if you want to set up your SNES images to open in your favorite SNES emulator, you must assign each of the above extensions to point to your emulator of choice. Now what happens if you decide to change emulators? You have to do it all over again.

This further complicates my emulator in particular: I have special support to load folders that end in a specific extension as though it were a complete cartridge with all associated files (ROM, RAM, memory mapping data, etc.) inisde of it. What would be a simple wildcard search becomes a rather complex list-based search instead.

And then there are the false positives. SNES emulators do not exist in a vacuum, and it is not inconceivable that other programs share these extensions. The more extensions we attempt to claim, the more likely we are to match false positives. Most notorious for this is the ".bin" extension, which is used almost universally.

Lastly, there is my choice to use ".bs" for BS-X flash cartridges, and ".st" for Sufami Turbo cartridges. By using separate extensions for separate files, my custom cartridge-type loading dialogs make more sense. When selecting a base SNES cartridge, you would not want to see your BS-X flash cartridges; and when selecting a BS-X flash cartridge to connect to a base cartridge, you would not want to see your actual SNES cartridges.

===

Copier headers

The old copier devices I mentioned earlier had a tendency to be rather lazy. Rather than perform two seek+read commands to determine the memory mapping mode from the internal cartridge information stored in every SNES image, copiers instead chose to store a 512-byte header at the top of every image to specify this information instead. That specific size was chosen at it is the exact size of one floppy disk data sector.

These copier headers are of no use to emulators. In fact, they only get in the way. They cause checksums to fail, they require custom loading code to strip the data from them, they complicate detection of the legitimate internal cartridge headers, and they cause patching issues.

Perhaps even more ironically, they aren't even of use to copiers themselves. You see, copiers are extremely obscure. These days, flash cartridges that can store headerless images on CF/SD cards are far more accessible and common. There are no manufacturers still making SNES copiers, and very few people still even have them. Copiers are slow, bulky, and cheap. They break very easily, designed with shoddy parts like EEPROM chips for BIOSes that don't even have tape over the UV windows.

Further consider all of the different types of copiers I have mentioned above. Their headers are, for the most part, incompatible with one another. And even the file extensions do not help anymore. As most everyone renames SNES image extensions freely, especially to ".smc", one cannot even tell which, if any, type of header is on any given SNES image.

And as if all of that wasn't enough, nearly half of the games in the SNES library are too big to fit on a single floppy disk anyway, meaning that the images need to first be split, and headered for this operation, before they can be used.

So to cater to at best 0.01% of potential SNES image users, with a perhaps one in a hundred chance of getting an image with a compatible header in the first place, we continue to keep copier headers around to this day.

===


Compressed archives

I remember my first hard drive. It had 200MB of storage, and it was very expensive. The early '90s were something. But we are in the 21st century now, and we are talking about a 20-40% compression savings on files that are at best 4MB in size, on $99 hard drives with 2TB worth of storage space.

And there are only ~2,000 unique SNES games. Doing the math, we see that it costs, at best, ten cents to store a complete SNES image set. So why do we still use compression? Is it bandwidth? The days of 28K dial-up are long past, but even then, it is not so unreasonable to distribute a collection of games in an archive, and require extraction first. As you would for literally any other file type in the world (images, movies, songs, etc.)

But why not support compression anyway? Well, many reasons. First, writing decompression code is hard. Very hard. We pretty much have to rely on third-party libraries, and these libraries are often larger than our entire emulators. zlib is something like 200-300KB of source code, which is about four times the size of my entire Game Boy emulator. And that's just for ZIP alone. People also want 7-zip, RAR, JMA, Gzip, etc support as well.

And then there are the licenses. Each of these decompression libraries impose restrictions on us emulator authors in order to use them. If I were to add RAR support, no Linux distribution would touch my emulator, because of their ridiculous licensing policies. Using JMA without a license exception would require an emulator author to release all of their source code, and allow others to sell their work for money. Not so great for non-commercial projects.

All of this code adds up, significantly slowing down compilation times. It may not seem like much, an extra minute or two every compile. But consider that I have compiled bsnes at least 20,000+ times now, and that really starts to add up after a while. Time is valuable.

All of that code also bloats executables. Programs take longer to start up, programs are larger as a result of all of these DLLs, and so on. And then there are the shared libraries. Every Linux distro expects you to use their shared libraries or they will throw a fit. But Windows doesn't have shared decompression libraries, making everything that much more complicated.

And then trying to load these images. Having to decompress a game first adds to the time it takes to start playing. A good second or so for each game you load, wasted, on file decompression. Get into 7-zip solid archives and things can get really crazy. The popular "Super Mario World.7z" bundle has nearly one thousand images inside of it. Loading a single game from this archive takes a good 5-15 seconds, depending on CPU power, and a monstrous 1GB of RAM to do so. Solid archives require you to decompress all data before it, so you pretty much have to extract and cache 1,000 games in memory, just to play one. Ridiculous.

I also mentioned the issue of false-positive matches based on generic file extensions, and trying to associate images directly to SNES emulators. This becomes two orders of magnitude worse when using popular archive extensions.

Perhaps worst of all is just how meaningless this all is. Even if, for some reason, you have a legitimate need for compression ... modern operating systems have compression support built-in! Take Windows and NTFS for instance. Simply right-click on a folder, choose properties, choose advanced, and tick "compress folder and subfolders to save space." and hit okay. The operating system will compress all of the data for you, and decompress it completely transparently to individual programs and users.

Doesn't that sound more rational? Have the OS integrate a common operation, rather than having every last software program support every last popular compression format of the month.

===

IPS patches

IPS was a format used to distribute patches for Amiga applications. It is a very old, inferior format, with many limitations. IPS patches cannot be applied to images larger than 16MB, they lack checksum information to verify that you are applying to the correct file, or to verify that the patch was applied successfully to a given file.

When combined with the issue of copier headers, this has become a very annoying issue for SNES ROM hackers and fan translators. What happens when you present people with two choices? Some choose one, some choose another. And since even the SNES hackers cannot agree on whether to make their IPS patches against headered or unheadered images; let alone end users and ROM verification tool authors; IPS patches have, at best, a 50/50 chance of actually applying successfully to a given game. Throw in various game revisions, quite popular on the SNES, and your odds of success go down even more. And since you can't verify successful application, the only way to tell is to see if the game starts, or if you get a black screen upon load.

Once this is determined, the user is now tasked with figuring out what is wrong. It is not exactly common knowledge how to add or delete 512 bytes of data from the top of a binary file, so most users give up in frustration.


===


Over the course of the last few months, I’ve shown readers how they can individually emulate NES and SNES games using their desktop or laptop. If ZSNES and Nestopia don’t do the trick for you, I’m pleased to reveal that just recently I’ve come across what some may consider to be the emulator of all emulators - BSNES.

Traditionally, video game emulation on the computer means you’ll need to individually download the console (the emulator) and the games (the ROMs). BSNES strives to create a bridge between some of our favorite classic Nintendo consoles and make the emulation process much easier.

Not only does BSNES succeed in creating this all-in-one emulator, but BSNES takes an approach far different from the rest. The emulator focuses on truly emulating the actual experience that one would get from playing on the console. There are no extra measures taken to create forms of compatibility that may exist in other emulators, and the code is very clean. That being said, the minimum system requirements for BSNES are a little higher.

BSNES is an emulator with support for 8 consoles:

The website includes binaries for both 32 and 64-bit Windows systems, and is open source to the Windows, OS X, and Linux platforms. The BSNES has been cited as being 100% compatibile with every SNES game ever released, and I’ve yet to run into any issues emulating games for the NES or Game Boy Advance.

The BSNES system requirements, as listed on their website, are as follows:

    Intel Core 2 Duo or AMD Phenom processor.
    Video card that supports Direct3D 9.0 or OpenGL 2.0.
    Linux port: hardware-accelerated video driver with OpenGL or X-Video support.

The interface is extremely clean and straightforward. To load a ROM, you’ll simply click into the Load menu and select which console you’re wanting to emulate. For Nintendo consoles, BSNES uses the traditional Japanese name (Famicon).

From there, it’s very simple. Just navigate to the folder where your ROMs are located and load the ROM of your choice.

Your game should load, just as beautiful and authentic as you’ve ever seen it.

As mentioned earlier, BSNES is all about a true emulation experiencing and preserving the old. BSNES includes different video filters and shaders by default. Remember having that crappy TV that always turned fuzzy and had scanlines? Even that can be emulated with BSNES.

BSNES includes most every feature of every other major emulator that you know of. You can completely tweak your video and audio settings, your input (with support of gamepads), driver usage, and more.

BSNES even has a Cheat Editor and State Manager, features that other SNES emulators will often leave out.

If you were a Nintendo kid like I was, this emulator is a dream to you. BSNES has a permanent spot on my desktop! If you’re interested in knowing how you can go about finding ROMs, check one of my previous emulation articles (like this one), as they explain. The BSNES, and any classic gaming preservation project, is something to truly appreciate. Let me know what you think of it in the comments.