Some MSU-1 titles freezing on Super NT/FxPak Pro

[timepilot]

I am using an FxPak Pro with a SuperNT.  A couple of MSU-1 titles have been freezing.  Star Ocean doesn't make it very far before freezing, and Street Fighter Alpha 2 sometimes makes it one or two rounds in before freezing.  Oddly, the MSU-1 PCM audio continues to play while gameplay completely freezes.  These are the current Conn MSU-1 versions.  For Star Ocean, this is Conn's v8 from June 2020.

 

The same MSU-1 titles work fine on bsnes.

 

Is anyone experiencing this same problem?  

[Tanooki]

Something to point out here, those are the 2 SDD1 games using that big decompression chip, and the only 2 SDD1 games too.  Maybe it's a related glitch between the pair, or they're so on the edge on being resource hogs it just balances on the edge before bombing out.

[timepilot]

1 hour ago, Tanooki said:

Something to point out here, those are the 2 SDD1 games using that big decompression chip, and the only 2 SDD1 games too.  Maybe it's a related glitch between the pair, or they're so on the edge on being resource hogs it just balances on the edge before bombing out.

Okay.  I can live with that, as long as it's not a canary in the coalmine for the entire FxPak Pro failing.

 

Do you think that will impact the non- MSU-1 versions of those same games, just as much as it impacted the MSU-1 versions of those games?  In other words, the problem is in the game itself and not in the MSU-1 expansions?

[Tanooki]

I've not heard of any MSU1 problems, so what you said was news to me, so I doubt it.

 

I remember something about the MSU1 though, it's a bit of a space eater due to the requirements to get that special custom chipset software to go, and the FPGA only has so much room.  It's why certain things either don't work at all like those STT chips for those lame Shougi games on the Pro of the FXPak, or why you need the pro to handle stuff like the SA1 and FX while using save states due to the constraints.  While SD2SNES/FXPak standard and the Pro basically can run everything the same at a basic level, there are exceptions.  When you get into combining features like MSU1, Save States, etc along with a more demanding chip you run into an either or not AND situation.  You either buy the more advanced cart OR use the chipsets but without the fluff.

[timepilot]

3 minutes ago, Tanooki said:

I've not heard of any MSU1 problems, so what you said was news to me, so I doubt it.

 

I remember something about the MSU1 though, it's a bit of a space eater due to the requirements to get that special custom chipset software to go, and the FPGA only has so much room.  It's why certain things either don't work at all like those STT chips for those lame Shougi games on the Pro of the FXPak, or why you need the pro to handle stuff like the SA1 and FX while using save states due to the constraints.  While SD2SNES/FXPak standard and the Pro basically can run everything the same at a basic level, there are exceptions.  When you get into combining features like MSU1, Save States, etc along with a more demanding chip you run into an either or not AND situation.  You either buy the more advanced cart OR use the chipsets but without the fluff.

Just to clarify, I am using the more advanced cart.  The cart that I am using is the FxPak Pro, which is the most current, and the most advanced, SNES flash cart available from Krikzz.

 

Does that change your analysis?

[Tanooki]

I know you are, that's why I was thinking maybe it's a glitch with the SDD1 handling because it's just the only SDD1 games that exist, and the only 2 giving you trouble.

 

I just was trying to say that both styles of cart are capable of it, just the lower end one like mine can't do both like MSU *and* save states, etc because of the smaller space/older FPGA it uses.  Yours can handle more, so if you're having problems, it could be a coding error.

[timepilot]

3 minutes ago, Tanooki said:

I know you are, that's why I was thinking maybe it's a glitch with the SDD1 handling because it's just the only SDD1 games that exist, and the only 2 giving you trouble.

 

I just was trying to say that both styles of cart are capable of it, just the lower end one like mine can't do both like MSU *and* save states, etc because of the smaller space/older FPGA it uses.  Yours can handle more, so if you're having problems, it could be a coding error.

I have not used a save state (at all, actually, and certainly not while playing Star Ocean).  That said, I am using the 2021 firmware that would permit save states.  Is it perhaps possible that whatever the cart has to do in order to make save states available while running the game is interfering with the proper functioning of the SDD1?  If so, is there a way for me to disable the save state functionality altogether (without reverting to an earlier firmware, because I do love the full-scale SGB2 compatibility with Alleyway!)?  I don't really even need the save state functionality; this game has in-game saving anyway.

 

When I have time, I will also test it with the plain (well, plain but translated) Star Ocean, in order to see whether it plays fine without the MSU-1.

[Tanooki]

That's entirely possible sure.  I never did add the 2021 firmware, still using the unofficial collaborative setup that got a bit of a tweak/update to the actual sd2snes/fxpak pro website as official beta software so there could be changes.  Maybe some glitch got introduced.

 

I don't think you can do what you said, but you could roll back the firmware maybe?  I'd look into that either way as a test, see if it dies using that, then you have your answer.

[timepilot]

1 hour ago, Tanooki said:

That's entirely possible sure.  I never did add the 2021 firmware, still using the unofficial collaborative setup that got a bit of a tweak/update to the actual sd2snes/fxpak pro website as official beta software so there could be changes.  Maybe some glitch got introduced.

 

I don't think you can do what you said, but you could roll back the firmware maybe?  I'd look into that either way as a test, see if it dies using that, then you have your answer.

I just tried the non- MSU-1 version of Star Ocean, and it locked up when it was showing the first cinematic pan of the starting town.  So it looks like the problem is probably not in the MSU-1 component.

 

I will try rolling back the firmware and let you know how it goes.

[timepilot]

5 hours ago, timepilot said:

I just tried the non- MSU-1 version of Star Ocean, and it locked up when it was showing the first cinematic pan of the starting town.  So it looks like the problem is probably not in the MSU-1 component.

 

I will try rolling back the firmware and let you know how it goes.

I tried using the most recent stock Krikzz firmware, and so far no problems with either Street Fighter Alpha 2 or Star Ocean. So it looks like the SGB2 firmware introduced incompatibilities with the SDD1.  I'll have to switch firmware when I want to play SFA2 or Star Ocean.

 

I don't suppose that there's any way to switch firmware from the internal menu?

[Tanooki]

I think you meant to quote back to me, but no you can't do that without re-copying your choice of firmware onto the SD card.

[timepilot]

10 minutes ago, Tanooki said:

I think you meant to quote back to me, but no you can't do that without re-copying your choice of firmware onto the SD card.

It occurs to me that I could just use a tiny, cheap MicroSD card, put only the SDD1 games on it, and switch it in when I want to play those games.  I may just do that.  Not a big problem, now that I know how to deal with it.

 

As always, thank you for all of your help and expertise.

[Tanooki]

It's all good, and you're right, SD media especially out of date very small ones are super cheap.  Enough to stuff a few finicky titles on one, power down, the use the usual would be a good way for a basic effort free work around.

[Atariboy]

If by chance you're not particularly interested in Street Fighter Alpha 2 but do want Star Ocean readily available, you could always apply the decompression patch for it to turn it into a regular SNES rom that doesn't use an enhancement chip (It just used the S-DD1 to decompress data).

 

https://www.romhacking.net/hacks/614/

 

It loads a little slowly upon booting up, but works perfectly on the Super Nt's jailbreak (Which doesn't support the S-DD1).

[Tanooki]

Whoa that's nice, didn't know someone pulled that little piece of work off.  I'm wondering just how much size the assets eat up now.  I have the original workaround set of files from like 10 years ago when it ran off a zip fully of junk before the SDD1 was cracked.  It's not an easy thing to come by, took a bit of work when I realized I lost it a few years back.

[Punisher5.0]

38 minutes ago, Tanooki said:

Whoa that's nice, didn't know someone pulled that little piece of work off.  I'm wondering just how much size the assets eat up now.  I have the original workaround set of files from like 10 years ago when it ran off a zip fully of junk before the SDD1 was cracked.  It's not an easy thing to come by, took a bit of work when I realized I lost it a few years back.

12MB

 

I was hoping for a Street Fighter Alpha 2 conversion but didnt have one on that site.

[Tanooki]

That's up there, much like the fairly big Tales of Phantasia with its insane opening fully sung sequence to start the game, let alone all the called out attack cries.  Shame SFA2 got the stick, it's a great fighting game, tops on the SNES despite what some trolls will say.  I imagine if it were decompressed right that and fired up through MSU it could get rid of that 4sec load time on it pulling those audio samples.

[Atariboy]

I assume Street Fighter Alpha 2 used the S-DD1 in a different way than Star Ocean did. The trick only is possible if it's simply being used to store the rom in a compressed state. 

 

Edit: That theory doesn't seem accurate. I still assume if it was possible that it would've been done by now, but I don't have any more educated guesses to venture on why it's a different situation here. 

Edited June 1, 2022 by Atariboy

[Tanooki]

It's an oddball, and I've seen that video from him before too.  I usually don't trust too many people on youtube as they're attention seeking blowhards who can talk more than they know, but that guy works in the industry and has for a long time, he knows his stuff and if he doesn't, when you're on the inside you can float calls and emails and get answers the media and public won't.  I'd really love to know as I think it would be fantastic if that would run without the chip much like the file package I have did for emulators a decade ago.

 

The package I have decompresses to 5.1MB, and it's in 2 files a tiny idx(index?) 33,792 in size, and then the massive DAT(data) file sdd1gfx.dat which is 5,080,882 in size.  It's all graphics data.  The dumper notes aren't all that interesting, not much useful, other than pointing out the data is larger than what the SNES could handle on the stock chips as it was over 4MB in data, so this stuff was crushed and stuffed into the SDD1 setup.  This bypass with the index allowed zsnes/s9x in the day to bypass the chip and use the information directly.