Almost floored it worked so easily. But makes sense technical side. Same patch will work on Japan and France. Woot!
Normal ROM has header:
34 = ROM+RAM+SA-1
Canoe specifically wants sram / battery flag:
35 = ROM+RAM+BAT+SA-1
Wow! The issue was with the cartridge header?! I would have never thought of that! I just assumed the issue was with Canoe and its limited selection of preset IDs. You're a genius Sluffy!
I'm going to assume that Nintendo just simply didn't code a bunch of chipset values into Canoe due to such a few amount of games that use them, like 34 in this case is a perfect example.
This also raises an interesting method for trying to get games to run on Canoe I would think. I'm going to go ahead and test this same change on the other known chipset value 34 games.
After testing, they all now work with the above mentioned change (chipset value 34 -> 35). I've also uploaded patch files for each of these games just in case anybody wants them (probably not since they are pretty uninteresting games). The patch files are in .bps format (Floating IPS is a great patcher if you require one), which means that it does not matter if your ROMs are headered or not, although I would suggest that all of your ROMs be unheadered (and renamed to .sfc as well, but I'm just being nitpicky
Saikousoku Shikou Shougi Mahjong
A Shogi (Japanese chess) and Mahjong game.
Shin Shougi Club
Another Shogi game.
Super Bomberman - Panic Bomber W
This game is pretty similar to Dr. Robotnik's Mean Bean Machine or Kirby's Avalanche, except Bomberman themed. No translation unfortunately.
Takemiya Masaki Kudan no Igo Taishou
A Go (board game) game.
I did some testing with other games that did not boot on Canoe as well. I looked at the three Seta chip games to see if I could possibly get them to at least boot.
F1 ROC II: Race of Champions (ST-010), I changed the cartridge header to denote it as a DSP chipset instead of a Seta chipset. The game was able to boot up perfectly fine, I was able to move around and select the different options within the main menu. Although, once you select any option that takes you into a race, the game will freeze right before entering the race. This is obviously to be expected, as the ST-010 chip is most likely used during the actual racing portions of the game (AI functionality). At least I got the game to boot!
Hayazashi Nidan Morita Shougi (ST-011), I applied the same change as F1 ROC II. This game was also able to boot, and I was able to navigate the menus perfectly fine similarly to F1 ROC II. As expected, the game froze right before entering a match.
Hayazashi Nidan Morita Shougi 2 (ST-018), I again applied the same change. This game was actually able to boot, surprisingly. Although you are just met with a screen that says "Transmit Wait", obviously looking for the ST-018 chip.
As expected, Nintendo wasn't willing to code in the Seta chipset BIOSes (not worth it for only three games, three extremely obscure games at that).
I also tried out the three DSP 2/3/4 games. Nothing to note here, exactly as described in the lists. Looks similar to the Seta chipset games, Nintendo probably felt it wasn't worth it for only three games.
Dungeon Master (DSP-2) has graphical issues that appear to be DSP-2 related ("Its primary purpose is to convert Atari ST bitmap image data into the SNES bitplane format. It also provides dynamic scaling capability and transparency effects.").
SD Gundam GX (DSP-3) won't even boot. I'm assuming it requires DSP-3 decompression ("The chip assists with tasks like calculating the next AI move, Shannon-Fano bitstream decompression, and bitplane conversion of graphics.").
Top Gear 3000 (DSP-4) freezes when entering a race. Definitely DSP-4 related ("It primarily assists with drawing the race track, especially during the times that the track branches into multiple paths.").
For Gun Hazard, please try this command line switch
I was actually thinking of playing around with those commands a while ago, but I was a bit busy (i.e. lazy
), so thank you for reminding me!
I tried -exit-on-sram-file-load-error but unfortunately it was the same result with no shutdown from an SRAM error. I'm willing to bet that the game is actually loading SRAMs fine, but for whatever reason is creating a new SRAM on boot-up. It's almost like it doesn't know that the SRAM file is there.
I tried playing around with some of the other commands as well. Unfortunately, I'm not so sure that they have any effect. I played around with --sram-file and with -output-dir as well, but I didn't notice any sort of changes. The SRAM still saved to the same location even though I specified a different directory. I'm assuming it has to do with one of the Bash files that is executed when loading a ROM. I'll copy and paste it here:
if [ ! -f "$fn" ] ; then
while read option ; do
case "$option" in
hue) printf ' --decorative-frame-hue';;
luminosity) printf ' --decorative-frame-luminosity';;
saturation) printf ' --decorative-frame-saturation';;
done < "$fn"
while [ $# -gt 0 ] ; do
case "$1" in
--title-code) title_code="$2"; shift ;;
--load-state-file) options="$options -resume" ;;
--save-data-backing-file) options="$options --sram-file" ;;
--replay-inputs) options="$options -replay-all -replay" ;;
--record-inputs) options="$options -record-next -enable-pad-debug-controls" ;;
case "$2" in
keep-aspect-ratio) options="$options -filter 1 -magfilter 3" ;;
pixel-perfect) options="$options -filter 1 --pixel-perfect" ;;
crt-filter) options="$options -filter 2 -magfilter 1" ;;
case "$2" in
record) options="$options -rollback-mode 1" ;;
replay) options="$options -rollback-mode 2" ;;
options="$options --rollback-ui /usr/share/canoe/rollback-ui"
options="-rollback-snapshot-period 720 $options"
--rollback-output-dir) options="$options -rollback-output-dir $2"; shift ;;
--rollback-input-dir) options="$options -rollback-input-dir $2"; shift ;;
--decorative-frame-path) options="$options --use-decorative-frame $2 $(decorative_options $2)"; shift ;;
if [ -f "$1.gz" ]; then
gunzip -c "$1.gz" > /tmp/ROM.sfrom
*) options="$options $1" ;;
read BUILD_TYPE < /etc/clover/buildtype
case "$BUILD_TYPE" in
devel) log="-log $title_code.log -log-append --debug-menu-settings /var/lib/clover/canoe/debug-menu.json --decorative-frames-path /usr/share/backgrounds" ;;
test) log="-log $title_code.log" ;;
exec canoe-shvc $options $log
Something interesting to note though, I found an issue that displayed the exact same symptoms as Gun Hazard. Although, it was for RetroArch and not Canoe, but the symptoms are eerily similar. Apparently the SRAM was being loaded into the cache folder, but getting wiped before the ROM had finished decompressing. Unfortunately, I tried with Gun Hazard uncompressed, still the same result.
Also, while I was looking at DSP chipset games, I tested out Ace O Nerae! (No-Intro calls it Ace Wo Nerae!, and the translation calls it Aim for the Ace!). Just as the lists claim, the game runs perfectly fine when playing Exhibition, but when attempting to play either Training or Scenario, the game returns a C7 error right before you enter those respective matches. There's an interesting piece of information included within the translation's ReadMe. I'll copy and paste it here:
v1.2 (15 January 2004)
Certain emulators like ZSNES and Snes9x seem to have trouble displaying the
court textures correctly, so until this is fixed by the emulation authors, you'll
have to endure it or concentrate on multiplayer mode which does not have
You mean you have some time to try other things? In this case, among the major games that still need to work correctly, there are four RPGs : Star Ocean, Tales of Phantasia, Seiken Densetsu 3 and Rudra no Hihou.
Star Ocean and Tales of Phantasia are being handled by darkakuma (any news, Robin64?).
Tales of Phantasia is being worked on!? Wow! That's amazing! I always thought Tales of Phantasia would never work on Canoe due to it being ExHiROM and Canoe not accepting ExHi/LoROMs.
And whoa! Once again, I really apologize for the wall of text!