More sd2snes save state issues on Chrono Trigger

[FoxLisk]

please let me know if there's a better place to discuss this

Here's a 5 minute (sorry) highlight with some bugs in it: https://www.twitch.tv/videos/1799243278

• at the beginning i'm in a savestate where, after i win an encounter, my characters are just stuck; the fight doesn't end properly.
• at 2:25 I load an earlier save state to try to correct it. this has messed up graphics on the overworld
• after proceeding back through, i still couldn't finish the fight properly - presumably whatever got 'stuck' was already stuck in the earlier save state; i was hoping some more context might be useful

and here's a clip where i load the wrong savestate, then swap slots and load the one i meant to, and get very corrupted graphics until another savestate reload: https://clips.twitch.tv/ObeseOddPicklesANELE-uInFO10VmWlGQn8r

full vod can be found here if it's helpful (and i can highlight it for preservation if that's helpful, too) https://www.twitch.tv/videos/1798514926

[Romain80200]

Hello, Do you try the fixe in this topic? https://github.com/mrehkopf/sd2snes/issues/216

[FoxLisk]

yes, I am using the patched firmware linked in that issue.

[redacted173]

savestate slots look like they may have several races which allow you to load or save state when the saved state isn't ready. This can cause random corruption. But I'm not really an expert on how slots work. Do you think this occurs if you start from a known, good point in the game and use save states without using slots? Maybe turn them off in the sd2snes menu just to be safe.

I don't have much time to look at this right now. Maybe ikari has time. It's very hard to debug it without something like the following:

• a fast, simple, and repeatable way to reproduce from the beginning of the game
• a fast, simple, and repeatable way to reproduce from a game save (.srm). Attach the srm to the bug report

You could also try attaching the one of the save states (.state) that is bad, but that may not be enough to debug it.

[FoxLisk]

savestate slots look like they may have several races which allow you to load or save state when the saved state isn't ready.

That's good to know, but I doubt I'm triggering it - I'm not like slamming save over and over, or reloading saves instantly or anything.

a fast, simple, and repeatable way to reproduce from a game save (.srm). Attach the srm to the bug report

I can't literally attach an .srm file to a github issue but you can find it here: https://www.foxlisk.com/public/ct.srm

I assume you have access to a Chrono Trigger rom.

I also recorded a video showing the steps I took to reproduce. https://www.youtube.com/watch?v=YWj1hTJy390

I don't have a repro case for the can't-finish-combat error I reported above. I will let you know if I come up with one.

[redacted173]

Thanks. I took a quick look - maybe in another 1-2 weeks I can look more closely. The freeze is probably audio related. Try adding the following to the end of sd2snes/savestate_fixes.yml:

788C: 001E84,2140 # Chrono Trigger (US)

My guess is the graphics corruption is a race with savestate slots. I don't see a feedback mechanism for the SNES code to know that the savestate has been fully loaded into PSRAM before state is loaded. The M3 can be anywhere in its code and it can take some time before it gets to doing that which includes reading the file from SD. If the slot hasn't changed then it doesn't matter since the contents are the same, but if it is changed then you get part of the new slot state and part of the old slot. Would be good for someone else to confirm I'm not reading it wrong, though.

[FoxLisk]

Thanks, I'll try this! Let me know if you have any updates, or if I can provide anything else useful to the investigation 🙏

[redacted173]

Try the attached firmware and menu files by copying them into your SD card's sd2snes/ directory over the 1.11.0 files of the same name. The fix requires both type of files. System Information should list the version as 1.11.1slot.

This change sets the highest bit in the slot byte when changing slot to prevent a load or save from happening while the MCU is still restoring it. After the restore is complete the MCU clears the bit. To be complete it probably needs to set the bit on a save, too. I believe Ikari said he was going to rewrite the savestate code in a future version so hopefully he can put in a proper fix.

If you need to attach things in the future, try zipping them first. Github should accept that.

sd2snes_slotfix_try1.zip

[FoxLisk]

Well, I didn't see any graphical corruption today, so i think this worked, thank you!