[beta regression] MSU-1 games freeze for ~1 second when switching audio tracks

[bkoropoff]

This does not occur on 1.10.3. I recall seeing this on an unofficial firmware, so I think it came in with the SGB support, but I'm not 100% certain.

[mrehkopf]

Could you name a specific game/hack for me to test? I've added a feature where MSU games can have their SRAM auto-saved when the game is known to be waiting on the MSU busy flag anyway (e.g. on track change). It will check SRAM content and save the SRM file to card but should never take a whole second to do that...

[bkoropoff]

I saw it on the Gradius III SA-1/MSU-1 merged patch from here. I'll try to grab a video capture.

[bkoropoff]

Here's a comparison. It's the same setup, just swapping firmware versions.

Stable (1.10.3) behavior

https://user-images.githubusercontent.com/2101303/127419713-a171a9cb-1b92-4e0b-9264-9ab2816a5f2f.mp4

Beta behavior

https://user-images.githubusercontent.com/2101303/127419744-94519f0e-b8cf-4cc5-96fd-524d6b7adf2f.mp4

[bkoropoff]

@mrehkopf let me know if you need more details

[bkoropoff]

I tried some other MSU-1 hacks. Hacks with both MSU-1 and SA-1 demonstrate the freezing, but MSU-1 hacks with no expansion chip seem fine.

[mrehkopf]

I see. Yes, it is probably due to the new firmware being able to save SRAM during track changes. As an SA-1 hack, it 1) probably uses a lot of SRAM (to replicate WRAM for use with the SA-1), and 2) changes SRAM content a lot since it is now being used as active working area by the SA-1 and not just for saved games.

Therefore it takes the firmware quite a bit of time to calculate the checksum on the whole SRAM area and write it back to SD Card.

That said, MSU-1 hacks should never lock up when waiting for the busy flag after an audio or data request. MSU-1 wasn't designed with a requirement for fast random access media in mind but even something like CDDA media where seeking to a new audio track could take a lot of time. I can add an option to disable the SRAM handling feature for MSU-1 but ultimately the author of the MSU-1 hack should implement a proper asynchronous wait for the MSU audio busy flag ;)

[bkoropoff]

Yeah, I suspected the hack was depending on implementation behavior. An option would be helpful since most hacks were tested against emulators and prior SD2SNES firmware, all of which have nearly instantaneous switching in all circumstances.

It would be interesting if there were a way for the hack to specify that only a portion of SRAM really needs to be saved, perhaps squeezed into the internal ROM header somewhere. That's beyond the scope of working around this problem, though.

[Nashismo]

Yeah, I suspected the hack was depending on implementation behavior. An option would be helpful since most hacks were tested against emulators and prior SD2SNES firmware, all of which have nearly instantaneous switching in all circumstances.

It would be interesting if there were a way for the hack to specify that only a portion of SRAM really needs to be saved, perhaps squeezed into the internal ROM header somewhere. That's beyond the scope of working around this problem, though.

I can confirm that the stutter does not exist for me on a SD2NES on v1.11.0b1 firmware. This using Gradius 3 MSU-1 version (No SA1).

I am wondering though bkoropoff, are you using FXPAKPRO? Because a normal SD2SNES is not able to use both MSU-1 and SA1 at the same time, at least according to Krikkz forum.

[codemann8]

This still occurs in v1.11.0, doesn't occur in 1.10.3. The game I test this on, LTTP Rando. Here is my initial report: https://sd2snes.de/blog/archives/1157#comment-992382 There is a linked video example there of it occurring.

Edit: I just realized this issue was for a game freeze, not MSU-1 audio buzzing, shall I open another GitHub issue for it?

[mrehkopf]

Apparently this (buzzing on track change) happens when a game requests a track change without stopping playback first. The firmware does stop playback implicitly when changing the track but the new opportunistic SRAM check took place before stopping playback 🙄 resulting in the FPGA repeating the same buffer over and over.

[mrehkopf]

224