SRAM not always saving.

shentino · Post by **shentino** » Fri May 06, 2011 12:45 pm

Game: Super Mario RPG

In an effort to get snes9x and zsnes to cooperate through SRAM sharing, I've been enjoying the superior quality of snes9x's sound emulation while switching to the superior emulation management of zsnes when I come across a particularly difficult part of the game.

And here lies the problem.

I recently loaded zsnes up with an SRAM left by 9x, and it loads just fine, but nothing carries back to 9x after I'm done with the SRAM in zs.

Further inspection reveals that for some reason zsnes isn't saving the SRAM. I went to a save point, saved, and waited 8 seconds or so, but timestamp of the SRAM file indicates no change. It's like the SRAM isn't being written to disk.

I do have the 5-second live save enabled.

Since this was an experimental procedure, I also used Super Mario World purely under zs. Nothing weird happened there, and it saved 5 seconds after writing as expected.

I really want to be able to port state back and forth between the two.

What's going on here? Did 9x somehow booger up the SRAM to where zs can't handle it? sram from 9x to zs works as expected.

I'm not sure if it's a bug or not but SRAM saving for one game and not for another is just weird.

Post by **badinsults** » Fri May 06, 2011 1:56 pm

Are you sure that zsnes is set up to read/write the SRAM file where you have the SNES9x saves set up?

shentino · Post by **shentino** » Fri May 06, 2011 3:17 pm

Sorta.

I actually have 9x configured to save to zs's folder. Same results as your method I presume.

Also, both srm's are in zs's folder.

The SMRPG one doesn't save on change, but the SMW one does. They're both in the same folder, the only difference between them is that the SMRPG one was originally created by 9x.

I'm going to update once I see if virgin zs SRAM from SMRPG shows the same behavior.

EDIT:

Ok, I just did the virgin zs test with SMRPG. Even without 9x in the picture it still failed to write SRAM to disk.

So 9x probably isn't messing anything up.

EDIT 2:

Just ran another experiment, and I was able to do a out and back from 9x to zs and back to 9x with an SRAM for SMW. The common factor seems to be zs's handling of SMRPG's SRAM.

I've checked the config in both cases, they are the same. At least zs can READ SRAM from 9x.

paulguy · Post by **paulguy** » Fri May 06, 2011 4:40 pm

Dumb question, but are they both running at the same time?

Also, doesn't zsnes have known problems with super mario RPG? Also, by management, do you mean the existence of rewinds? Does snes9x not have rewinds?

Post by **odditude** » Fri May 06, 2011 5:13 pm

what os/version? what are the fully qualified paths to both ZSNES and the save directory?

shentino · Post by **shentino** » Fri May 06, 2011 5:19 pm

I'm unaware of any SRAM specific problems with SMRPG. There was some SA-1 something or other that's on the dead horse list, but SRAM failing to write to disk doesn't ring a bell as a known bug.

I was indeed running them both at the same time just for shits and giggles, but the problem persisted when I ran them serially.

As an aside, a way to explicitly write SRAM on command would come in handy.

Linux Mint 9
/usr/bin/zsnes
/home/shentino/.zsnes

I have also confirmed that the saved games are indeed being written to SRAM, as deleting the SRAM causes the saves to go poof. Still at a loss for why the modified SRAM isn't being written to disk as directed.

Deathlike2 · Post by **Deathlike2** » Fri May 06, 2011 5:44 pm

Make sure that ZSNES points to the correct directory by editing ~/.zsnes/zsnesl.cfg

Case sensitivity can screw things up.

shentino · Post by **shentino** » Fri May 06, 2011 5:56 pm

I double checked and it's the correct folder. Currently the paths are all empty so I'm assuming it's defaulting to .zsnes.

I should note that it's still READING the SRAM file just fine. It's writing it back to disk that seems to be troublesome for SMRPG.

I should mention that SRAM for SMW is being handled just fine, so it's most likely not a path related problem

shentino · Post by **shentino** » Sat May 07, 2011 11:59 am

Oh, to answer an earlier question.

By management I do indeed mean zs's features of rewinding and changing speed. Timing those superjumps enough to get the Super Suit is a lot easier in slow mo.

Anyway, I double and triple checked everything. All the paths are correct and everything is working as expected with Super Mario World. Loading SRAM works for SMRPG, but for some reason it isn't getting saved to disk when it changes. And I have confirmed that Snes9x isn't interfering, since it behaves this way even if I start everything with a virgin cold boot without any state at all.

If this isn't a known issue should it be moved to the bug board?

Post by **grinvader** » Sat May 07, 2011 1:29 pm

shentino wrote:I'm unaware of any SRAM specific problems with SMRPG. There was some SA-1 something or other that's on the dead horse list, but SRAM failing to write to disk doesn't ring a bell as a known bug.

Maybe you shouldn't bother, you know

because it is.

shentino · Post by **shentino** » Sat May 07, 2011 2:19 pm

So does playing an SA-1 game count as a breach of warranty for ALL bugs? It didn't seem like something that would specifically affect SRAM.

I'll give 1.42 a try. If that fixes the SRAM save failure then I'll consider it a dead horse bug I never should have posted in the first place.

Unfortunately I'm having problems compiling 1.42.

File permissions have also been triple-checked.

paulguy · Post by **paulguy** » Sat May 07, 2011 6:18 pm

Do you really need to rewind that badly? Snes9x has the rest of the functionality you need. If the game has known problems with this particular emulator, then why would you want to bother with the risk of glitches or hangs or losing your saves/progress? A turn based game like Super Mario RPG would be better with specific saved states anyway.

kode54 · Post by **kode54** » Sun May 08, 2011 12:47 am

He reported in #zsnes that for some reason, the speed control keys do nothing for him. Just as I told him to try resetting the keys, or setting them to something else, he peered out and never came back.

shentino · Post by **shentino** » Sun May 08, 2011 5:29 am

I X'ed out of IRC because I got very sleepy.

Anyway I've been over every menu item back and forth and the only things related to speed do nothing to the emulation.

I've also tried raw compilation of 1.42 and 1.51, neither of which I can get to compile on my system for some reason.

I've decided to forgo all solutions except waiting for the SRAM saving bug to get picked up during the sa-1 rewrite for 2.0.

Post by **grinvader** » Sun May 08, 2011 10:36 am

... don't hold your breath.

shentino · Post by **shentino** » Sun May 08, 2011 1:12 pm

I just thought of a potential workaround.

Can I do a bit of file surgery to extract an srm file from a zst file?

If so, does anyone know the appropriate file offset in the zst where the embedded srm is?

Rashidi · Post by **Rashidi** » Mon May 09, 2011 3:55 am

shentino wrote:I just thought of a potential workaround.

Can I do a bit of file surgery to extract an srm file from a zst file?

If so, does anyone know the appropriate file offset in the zst where the embedded srm is?

iirc, the 1.42 zst doesn't contain the srm,
which cause trouble for games like Treasure Hunter G,
but you can abuse it for games like E.V.O

Edit:
i'm curious about chmod result from .srm made by snes9x vs .srm made by zsnes ...

ZSNES board

SRAM not always saving.

SRAM not always saving.

Re: SRAM not always saving.

Re: SRAM not always saving.

Re: SRAM not always saving.

Re: SRAM not always saving.

Re: SRAM not always saving.

Re: SRAM not always saving.

Re: SRAM not always saving.

Re: SRAM not always saving.

Re: SRAM not always saving.

Re: SRAM not always saving.

Re: SRAM not always saving.

Re: SRAM not always saving.

Re: SRAM not always saving.

Re: SRAM not always saving.

Re: SRAM not always saving.

Re: SRAM not always saving.