Un-Official Links

This is a private page for pre-release builds and un-official links. Please do not directly link to this! If you must guide someone here, do so by the official release page.

To report bugs, notify me with a @DarkAkuma on Discord, or a reply to the most recent SFROM Tool release post.

Release Platform Download
SFROM Tool - v1.1.3.1 Windows Download
SFROM Tool - v1.1.3.1 Mac Download
SFROM Tool - v1.1.3.1 Linux Download
ChangeLog (since v1.1.3.0):

Windows:

  • New Undo/Redo patch generation from the command line.
  • Drag and Drop support for .sfc/smc, .sfrom and .cnp.
  • Support for zipped ROMs.
  • Minor fix to recalculate romMapOverride after patching, for non-cnp database generations. (05/22/2019)
  • Fix for VAR data start location when no VAR data is used. (05/22/2019)
  • Fixed SDA data being lost when editing a .sfrom. Really? No one found this issue until now? It was bad, and easily findable... (05/27/2019)
  • You can now select, open, and save .sfroms that are .7z compressed. (05/27/2019)
  • Fixed a bug where non-VC/PCM/SDA/SRCF type patches from .cnps would always get applied, regardless if they were checked or not. (05/28/2019)
  • Probably other minor changes I'm forgetting...

Mac/Linux Notes:
  • Linux build is completely untested.
  • Mac build is tested, but not thoroughly.
  • New Undo/Redo patch generation from the command line.
  • Zipped ROMs are supported now.
  • No Drag and Drop support now, or in the near future. (Avalonia limitation)
  • 7Zipped .sfrom support is not in the cards. (No suitable 7z library to replace SevenZipSharp)
  • The UI is a close recreation of the Windows build, which may look odd to some.
  • Due to the limits of Avalonia (the UI library used), some things look/work differently. Like:
    • Character length and type limits in the Text Fields of the Advanced Window.
    • The main window text.
    • The patch select list.

Release Platform Download
hakchi2 NPE Windows Download
Description:

This is a fork of the main branch version 2.21f of hakchi2.
The purpose of this fork is to be a version of hakchi2 that I can in good concious recommend to people, and be confident that they wont have to deal with certain issues.
  • Generation of .sfrom's is completely removed from this fork. This is mostly due to the bad default Preset ID assignment, but avoiding the bad headers is a plus!
  • The Ctrl+Alt+E "SNES Preset ID" window is also removed, as it caused corruption issues with GOOD .sfroms.
  • I removed a lot of the shameless/stupid BS.
    • Paypal link.
    • Donate begging popup.
    • Pointless self promotion in .desktop Copyright. (zero reason for this BS, when making something fairly close to the known official copyright lines was easily doable with the code that already existed.)
  • I tweaked how the .desktop file is filled out in general. This is about the closest thing I'll do for "improvements".
    • A properly generated copyright.
    • Fixed the SaveCount value to now be properly set when selecting a .sfrom. (I guess hakchi2 normally only does this with .sfc/.smc's? Dumb...)
  • There's a popup error, if a user manages to still select a .smc/.sfc, that clearly states that SFROM Tool is needed to generate .sfroms.
  • The snescarts.xml database is now used with .sfroms... assuming the game ROM inside the .sfrom is an unaltered match for what the CRC is in the snescarts.xml.
  • Made a minor change to how the snescarts.xml is processed, for an upcoming improvement. Should be no visible difference for now...

Obviously, SFROM Tool is completely required to generate and edit .sfroms with this. You simply import them via "add more games" options as you always should have, and select them for editing manually.
There are no plans to "improve", expand this build, or integrate it with SFROM Tool in any way. If you want such things, use CE or wait for SFROM Tools successor.

The over all plan for this fork currently is not for it to be something that's maintained, improved, or polished by me. While it is targeted towards canoe purists, I personally don't aim to optimize it as such. I just wanted to spend the least amount of time possible fixing some brain-dead easy issues so I had a basic build I was comfortable recommending to people. That said, I'm not against accepting commits for further enhancements as long as they follow these simple intentions.
  • A change that pertains directly to canoe usage. I'm not going to remove support for modding the SNESC for other BS. But outside of critical bug fixes, this build doesn't care.
  • Low foot-print. The on console installation is as close to possible as a stock, non-modded console. To borrow a phrase I use for SFROM Tool, "as if Nintendo did it themselves".
  • Doesn't complicate things for new users any further, or makes them easier.

For now this is just for private testing. A Github repository has been made but not updated yet.

Game Region Download
Super Mario All-Stars E-NTSC VC / PCM
Super Mario All-Stars J-NTSC VC / PCM
Super Mario All-Stars E-PAL VC / PCM
Dragon Quest I&II J-NTSC VC / PCM
Dragon Quest III J-NTSC VC / PCM
Super Mario All-Stars & Dragon Quest Patches:

The reason these are not part of my official .cnp set is because no official Preset ID is known yet. They just use 0x0000 which is not a real Preset ID Nintendo ever intended to be used.
The reasons these exist, but lack a Preset ID is because the game was released on the Wii in a Disc, but with standard VC patching. Regardless of Disc or VC, Wii did not use Preset IDs yet.
That said, I do feel that official Preset IDs are/may be reserved thanks to 3DS and Switch list rips/leaks, but the ID's cant be found and verified yet. I can't even make a decent educated guess like I did for most Wii VC games as these don't follow the same Product ID standard.
For those curious, and willing to do a bit of testing, these are my guesses for SMAS and why:
  • 0x10E7+0x10E8: This guess would ignore the PAL version, and E7 would be US, and E8 would be J. These IDs are clearly reserved for something that didn't make it to the VC, so maybe this?
  • 0x1119-0x111C: While 4 IDs total, I find the gap of 4 verified IDs here odd. 4 games appear to have been reserved during development and skipped over when it camp to reserving "Metal Slader Glory: Director's Cut" and "Marvelous". 3 could be this game, and the other something else. Perhaps a SMAS Korean version?
  • 0x1124-0x1126: These guessed IDs are only because examining the asm suggested these 3 IDs were related, as is often the case with the same game in different regions. But my understanding of the asm and what appear to be Preset IDs is inconsistent.
  • 0x113F-0x1142: Same as 0x1119-0x111C.
  • 0x1147-0x114A: Same as 0x113F-0x1142.
The higher on the list, the more likely I'd think.
If they have clear issues with an ID, that can be ruled out.
I don't know of any bugs with this and the 0x0000 ID, but if any are found and those bugs are not present with one of these IDs, thats evdence towards it.
Ultimately, we will probably find out once the game is released on the Switch.

For Dragon Quest, I have no guesses.

Release Platform Download
sfrom2sfc v1.0 Windows Download
kachikachi sav2sram v1.0 Windows Download
sfrom2sfc:

sfrom2sfc is a simple console tool I quickly made and only posted on reddit.
It's purpose is to extract the game ROM for a .sfrom. But along with that it also extracts .pcm/.var/.sda data if present.
This was generally wanted for the purpose of legally getting the ROM's from your SNESCs stock official .sfroms.
Keep in mind, most official .sfrom's use PCM audio and this does not reinsert that audio back into the ROM as BRR. So most games will sound awful.
I'm working on a PCM<->BRR audio conversion tool, but until that's done you should find and use a python script called snesrestore.py.

kachikachi sav2sram:

kachikachi sav2sram is another simple tool I quickly whipped up.
It's based on the SNES sram conversion code I used in SFROM Tool, but does the same for the NES Classic/kachikachi instead.
It converts .sav files from traditional emulators, to .sram to be used on the NES Classic.
And of course it can convert the other way as well. Meaning it can do .sram to .sav.
I don't know if it will be an issue with some games, but kachikachi .sram's are always 32KB, while a .sav for the same game may be lower with traditional emulators. This tool can't know to shrink a .sram when converting to .sav, so it doesn't try.