I did some more testing with Front Mission - Gun Hazard and Kirby's Dream Land 3. I think I've figured out "the what" in regards to the SRAM issues, although I have no clue on "the why".
Front Mission - Gun HazardFor this game, I did quite a bit of testing, trying all kinds of different methods and comparing them with other games. I'm fairly confident that what's occurring here is that the SRAM file is being "reset" every time the game boots up. What I mean by this is that the SRAM file, doesn't matter what it contains, will always be changed into a "fresh" (empty saves) SRAM file. Every method that I've attempted always ended up with this same result, no matter what.
I believe that the game is in-fact loading the SRAM, the issue is that the SRAM is always an empty SRAM. It should be noted that this SRAM revert/wipe/whatever-you-want-to-call-it always occurs on game boot-up. This means that when you play the game, save to SRAM, and then shut down the game, that SRAM file is still your recently created save file up until you boot the game up again, at which point it will become an empty SRAM again.
Most games on Canoe follow a fairly simple protocol when it comes to SRAM files. The SRAM file will have its SHA-1 hash value calculated, appended onto the end of the SRAM file, and an accompanying hash file will be created containing the aforementioned SHA-1 hash value. The process Canoe executes in order to load an SRAM file, or at least the process that I personally believe Canoe executes, is by calculating the SHA-1 value of the SRAM file (which it appends to the end) and then comparing the SHA-1 that it just appended to the value contained within the hash file. If the resulting SHA-1 value of the SRAM file does not match the SHA-1 value contained within the hash file, Canoe will wipe that SRAM into a new and empty SRAM file.
For most games, as long as you include correct, and matching, SHA-1 values to the SRAM and hash files, Canoe will load the SRAM with no issues. I say most because there are a few exceptions, particularly Super Mario RPG and Yoshi's Island. Both of these games' SRAM files contain a hash value that does not match the calculated SHA-1 value of the SRAM file. It is currently unknown how exactly Canoe is calculating these particular hash values, and due to this, it is currently impossible to import your own SRAM files for these particular games.
I am in no way saying that this is what is causing the SRAM issue with Front Mission - Gun Hazard though! Canoe automatically calculates the SHA-1 value and appends it to the end of the SRAM as well as within the hash file, which means they are more than likely the correct values. Having said that, I'm willing to bet that the comparison check for the hash values occurs on game boot-up. I only wanted to mention all of this because I felt that it was important to note, due to similar symptoms.
Anyways, apologies for the tangent! I'm quite confident in saying that Gun Hazard actually loads the SRAM as it normally should. The issue is just that the SRAM file is an empty SRAM, which makes it appear as if the SRAM is not loading. The only question is "the why" aspect of it. What occurs during boot-up that causes the SRAM to clear and become an empty SRAM?
TLDR:
- Gun Hazard actually does load SRAM properly.
- SRAM gets wiped during boot-up of the game, which gives the impression that the SRAM isn't loading.
- The question is
why is this occurring.
- Does the game do/check for something during boot up?
- Is this an incorrect hash value situation? (Unlikely due to Canoe calculating the hash value itself)
Kirby's Dream Land 3Alright, I did a bunch of testing on this game in order to figure out exactly what the issue is with the SRAM, as well as the difference in-game between Preset IDs 10A2 and 10A4.
First, I'll talk about Kirby 3 with Preset ID 10A2. The SRAM is not enabled with this preset ID, period. For all games that have SRAM, the SRAM file is created upon game boot-up. I booted up Kirby 3, started a new file, and played a couple of stages. I then used FTP to navigate into the Saves directory, and sure enough, there were zero files present in Kirby 3's folder (similar to Super Castlevania IV's folder, Street Fighter II Turbo's folder, etc.).
Interesting to note though, I imported my own Kirby 3 SRAM/hash files into the aforementioned Saves directory, and then booted up Kirby 3. The game loaded the SRAM and I was able to load my save file, but since SRAM is not enabled with this preset ID, the game never wrote/saved to the SRAM file. Just something interesting and kind of funny to note.
Next, I'll talk about Kirby 3 with Preset ID 10A4. I have been able to trigger the game saving to SRAM with 100% reproduction, at least for the small sample size that I tested. The issue with Kirby 3 is that there is no manual "Save" option. Saves are done automatically, and it's the game that controls when to save. For some reason, Kirby 3's "Save to SRAM" mechanism doesn't trigger when it's supposed to, which is after the completion of each stage (I'm assuming, I don't play too much Kirby 3). It should be noted that I have not tested Kirby 3 with other Preset IDs.
Now for the testing methods that I employed. I tested using two separate methods for trying to trigger the SRAM save. The first method was the standard method. I completed a stage, and then after the completion of said stage, I would press the Reset switch on the Classic to return to the main menu, and then I would restart Kirby 3. I tested this method ten times, and in all ten of those times, the SRAM did not save. In five of those instances, I pressed the Reset switch after beginning the next stage to see if that made any difference. The goal was to try and trigger the "Save to SRAM" mechanism.
The second testing method that I attempted included one extra step. After completing a stage, I would soft-reset the game with the "L-Trigger + R-Trigger + Select + Start" button combination. After soft-resetting the game, I would press the Reset switch, and then restart Kirby 3. I tested this method twenty times, and in all twenty of those times, the SRAM saved correctly! I completed 15 stages on my Save Slot 1 file, and then began a new file on Save Slot 2, completing 5 stages on that save file. It should be noted that restarting Kirby 3 can occur very soon after soft-resetting (I was restarting Kirby 3 even before the Nintendo logo fully appeared).
I also used both these testing methods on Kirby 3 with Preset ID 10A2. I attempted both methods ten times each, but the results were what was expected. All twenty times, the SRAM did not save.
It would appear that soft-resetting causes the SRAM save mechanism to trigger. I'm not exactly sure what aspect of soft-resetting is causing it to fire though. I'm also not too sure why Kirby 3's SRAM save does not trigger when it's, I'm assuming, supposed to.
TLDR:
- Preset ID "10A2" disables the SRAM entirely.
- Preset ID "10A4" enables SRAM, but the SRAM save mechanism must be triggered.
- Soft-resetting the game triggered the SRAM save 100% of the time (20 times out of 20).
- The question is
why the SRAM save does not trigger when it's supposed to (I'm assuming after the completion of a stage).
- What is it about soft-resetting that triggers the SRAM save?
Canoe seems to get confused with crate sprites off the left side of screen (-1,-10,-15) and treats it as right side (+255, +246, +241). They're just 16x16 sprite tiles, so strange it does this. I thought other games have some large sprites that go offscreen (left side) just fine...
I remember someone running some tests for me with Uniracers because it has that same dumb problem, and results conflict with Nosferatu.
That's very unusual gremlin we're chasing around.
Yeah, the vast majority of games don't seem to run into this issue. And with the huge abundance of platformers for the system, I wonder what makes these games so different.
What are the conflicting results with Uniracers and Nosferatu? I thought the "leaving left side of screen and appearing on right side" bug was most likely too much of a hassle to fix. I think I remember it still being in Uniracers because of that.
And wow! So many patches already! Sluffy, you're like Oprah, "You get a patch! And you get a patch! Everybody gets a patch!!!" Seriously, especially with the amount of requests that you get, you're amazing!
Topic: Snes emulators (Canoe, Snes9x) -- game problems and fixes (Read 934261 times)