This is a tool for creating .sfrom format files from normal .smc/.sfc game ROMs, for use with the SNES Classic emulator (canoe).

This program aims to make .sfrom's as close to 100% accurate as possible, both in terms of byte values/locations and supporting PCM audio/SDA graphics.

Nintendo's canoe emulator is very picky compared to most typical emulators. It requires very specific versions of ROMs, and unique game specific settings that need to be set when the .sfrom is created. So below is a list of ".cnp" patches, a unique patch format created specifically for sfrom Tool. These patches do more than .ips patches in that they also support patching in PCM/SDA data to the .sfrom, and provide the settings for the .sfrom in addition to patching the game ROM.

A sfrom is an official Nintendo created SNES game ROM file format introduced with the SNES Classic. It's heavily based off a format used for the WiiU SNES Virtual Console. From what I can tell a .sfrom is basically the 5th version of that WiiU format. Unlike a normal SNES ROM, a sfrom contains predetermined settings for the playback of the game, along with (optional) external audio and (optional) decompressed graphics tile data.

No. hakchi2's sfrom creation code was poorly made with a very early, flawed, incomplete understanding of the sfrom format. It was only made to work "good enough". Week #1 I investigated the sfrom format and found flaws and limitations with hakchi2s implementation, and when I brought it up with the dev I was utterly ignored. So I made this program. The accuracy of sfroms created with my tool provide a quality, and level of confidence that no issues should be encountered that are caused by a poorly made sfrom.

With my program, bytes in the headers are set correctly and are in their proper locations. You can also change more of the header values than just Preset IDs and the SuperFX Byte. My program supports using the sfrom format to its fullest design by allowing you to create sfroms with PCM/SDA data. Rather then the same small number of a database of Preset IDs in hakchi2, I actually put in effort to compile a database of IDs 6-8x larger. Beyond Preset IDs, my database also contains the exact settings Nintendo chose for every known officially compatible ROM. Finally, I created a custom patch format for my program to allow you to create properly compatible sfroms that are almost 100% byte-for-byte matches to what an officially Nintendo produced sfrom would look like.

It's a 2 byte long indexing value that's uniquely assigned by Nintendo to each VC/CC game. It resides in the games sfrom header. Each Preset ID is associated with an exact "game + region + version" number. Using anything other then it's intended "game + region + version" with an ID is like trying to place a wrong piece into a puzzle. It might sort of fit/work, but there will likely be some problem. Each Preset ID is believed to tell canoe to use certain code/features specifically meant for the intended game, while often disabling what it doesn't need.

Yes. But it's luck if it will work at all or with minor issues. There's a catch all Preset ID (0x0000), that while it fails to load code that games might specifically need, it doesn't load code meant for a specific game that would disrupts other games. Many games are playable with that ID. Some games can use ID's belonging to another with minimal issues. It's kind of my hope to find what ID's work best with such games. I started cataloging the known games just so people would have a basis to try just that. There are however certain games that may never work, due to lack of special chip emulation, SRAM limits, unimplemented feature support, etc. Nintendo made official ROM hacks for many of the games on the list to bypass having to properly code such stuff.

The TL;DR would probably be "not much". This has had to be figured out from reverse engineering logic and the history of the SNES VC ROM formats. But the entire reason PCM audio seems to exist is because during the original Wii VC development Nintendo decided they wanted to extract the SPC/BRR audio from the all the VC ROMs, and convert it to PCM audio. Likely either due to it being helpful for the deticated audio procressing hardware to play it and free up the load from the main CPU. Or possibly due to a licencing issues since the original SPC700 audio processing hardware in the SNES console was developed by now rival Sony. They never intended for it to be something like MSU-1, providing higher quality/better sounding audio. That said, since they keep on using it, it's possible that it has a slight performance boost in some situations on some games. But I'm mostly providing the PCM audio patches, just because they exist, are supported, and are an official element to the sfrom format. I put in the work to make sure that the PCM audio patches were completely optional, having to restore normal audio to many versions of games that were never released without PCM audio, and in doing so I had the data to make the PCM audio patches available with no extra effort, so I did.

VC - Canoe often, but not always, expects and requires ROM's that were only available on a Virtual Console. Sometimes its a minor hack, sometimes its a V1.1+ that was never released on cartridge. These patches transform a normal proper dump into one of these Virtual Console ROMs.

PCM - Canoe supports .sfroms that contain the audio data extracted from the ROM and stored externally in a PCM format. Such ROMs were hacked with pointers replacing the original audio. So PCM .cnp patches both patch the game ROM with such pointers and provide the PCM audio for the .sfrom. This PCM audio stuff seems to mostly just be carry over from the Wii VC where presumably it was done to either bypass proper SPC700 emulation, offload audio to dedicated audio processing hardware, or both. After the Wii it only seems to have been used due to laziness, only with games already released with such audio. Games first released on a VC/CC after the Wii generally do not have it.

SDA - This seems mainly unique to S-DD1 games. Rather than properly supporting decrypting S-DD1 graphics, the tile data for the graphics is stored un-encrypted in a .sda file. And like PCM audio, the game ROM is hacked with pointers replacing all S-DD1 graphics calls.

Canoe Fix - Generally used with games that were never released on a Virtual Console, this type of patch typically changes something in the game ROM that otherwise prevents the game from working. This is much like VC patches, except they are non-official fan made fixes.

Product ID - This is a 8 character string that's derived from the Virtual Console the SNES Game was released on. Each release was given a Product ID that was generally used for setting folder paths for the installed VC game and it's saves. "WUP"=WiiU, and "KTR"=3DS as seen in those consoles SNES VC files. "WUP" being present in the SNES Classics official stock sfroms is because the sfrom format was based off the WiiU VC. Due to this consistency, I use "RVL"=Wii for games then were never officially assigned Product IDs on the Wii/3DS, but had Preset ID's reserved. It makes the most sense. For SNES games not released on any VC I'd use use a modified version of their original cartridge Product ID.

Volume - This was used on the VC to set the base volume for the emulator when it plays the ROM. It seems unused with canoe in favor of the --volume command line param.

FPS - This corresponds to the frame rate that a game was meant to run at. Officially 60 for NTSC games, and 50 for PAL games. No known other values were used. This however does not seem to effect games on the SNES Classic, as setting PAL games to 50 still has them run fast.

Max Input - This controls how many controllers are actively checked by canoe for valid input. You could have 2 controllers hooked up, but if the value is set to 1, then the 2nd controller is ignored.

ROM Map - This is believed to be intended as an override to force the emulator to detect a ROM as a Lo/HiROM instead of figuring it out for itself. While this byte wasn't present in early WiiU VC releases, proving the emulator code doesn't need it, it has been present in later released, and seems to be required for the SNESC.

Super FX - This is believed to be a byte that was intended for all special chips, the byte being reserved in early WiiU VC releases when special chip games started being added. But this went unused until the SNES Classic for whatever reason. Likely that the Preset ID did well enough at enabling emulation of such special hardware. I believe it's now used for SuperFX games as a base clock speed of the emulated Super FX chip, similar to the Volume byte. It's only known valid values are 0x00 and 0x0C.

Unknown1 - As the name suggests, the purpose of this value is unknown. But it appear to be a 4 byte value (probably an Integer) that is always set to 0x00000001 except for 7 known cases where it is set to 0x00000000. In early versions of the sfrom format this was always set to 0. In 3DS VC files, the byte is set to 3 and sometimes 2. I have no valid theories as to its purpose atm.

Unknown2 - As the name suggests, the purpose of this value is unknown. It is always set to 0x00000001. In early versions of the sfrom format this was always set to 0.

SDA - When researching the various VC's, the original Wii VC SFA2 included files with an ".sda" extension.The contents of this file are exactly the same as the data at the end of the WiiU VC/3DS VC versions of the same games. So I adopted that extension to keep my tool consistant.

PCM/VAR - Like SDA, the original Wii VC files contain .pcm and .var files that are 100% matches for the content seen in the WiiU/3DS VC files.

WUP/KTR/RVL, etc - These are official 3 character abbreviations of the systems production code name that are used in Product IDs.

-JXXY - The other half of the Product ID's, the first J means "SNES", as opposed to any other console on the VC. The XX is the 2 character ID that's unique to that game. The Y is the region character, generally E (US), J (Japan), and P (Europe). D (Gemany), and F (France) were also used on the VC's. I chose to use the product ID formats as the naming convention for these patches, as to me it made the most sense.

VC - Virtual Console.

CC - Classic Console (I.E. SNES Classic, NES Classic, etc)

Patches:

Place these patches in the "patches" folder, and they will be detected/use when you select the appropriate game.All-in-one packages coming later, as soon as updates slow down...