Closed rablador closed 3 years ago
@rablador does it load in LSDPatch? https://github.com/jkotlinski/lsdpatch/releases i'm not entirely sure that it checks for the SRAM init bytes so you might be able to access it with that. if that doesn't work, try the old LSDManager https://github.com/jkotlinski/lsdmanager/releases/
@rablador also if you can add the sav to a zip file and attach here, we may be able to take a look (edit: including your LSDj rom in the zip may also be a good idea)
It loads in LSDPatch, but I cannot export anything. With LSDManager I can export, but the end result is not importable back again. Save attached!
it looks like what you've got here is what's in the working memory only. this should be possible to export although LSDManager will not let you access it. i'll try manually setting the sav bytes to see if we can at least get a working memory export
i've got the .lsdsng here, and it's valid. (EMPTY). 0.WM.lsdsng.zip but i'm trying to figure out what specifically is disabling the "load/save" menu so i reached out to the LSDJ developer to confirm. i'll attach the .lsdsng here in the meantime, but be aware that importing it into a sav will disable the LSDJ load/save menu.
i'm going to try to concatenate the beginning of this sav to the end of a valid sav and see if that works
@rablador ok! it worked with the latest LSDPatch if i opened a new sav and then imported the .lsdsng file. here's a working sav lsdj-fixtest.sav.zip
Wow, thanks a lot! :D
Hah, happy this all worked out, @rablador!
@urbster1 Have you hear back from Johan about the problem?
Maybe it's an idea for liblsdj to do something along these lines:
ERROR: the SRAM initialization bytes aren't set to 'jk' Do you want to load the sav anyway (no guarantees given it works)? y/n
Upon further I noticed that some parts were a little garbled, like some instruments sounding off. But the bulk was there!
@stijnfrishert I would welcome an option such as the one you propose. :)
@urbster1 Have you hear back from Johan about the problem?
basically he just said that the sav is pretty messed up! i checked to make sure the 'rb
' bytes were in place and they were, so i'm still not sure what exactly the problem was.
Maybe it's an idea for liblsdj to do something along these lines:
ERROR: the SRAM initialization bytes aren't set to 'jk' Do you want to load the sav anyway (no guarantees given it works)? y/n
i think this probably makes sense.
Well, 'rb' is put in the songs to check if they're ok and initialized 'jk' is put in the save to check if it's ok and initialized
So their case the save itself was probably corrupt, but the song wasn't or something?
Well, 'rb' is put in the songs to check if they're ok and initialized 'jk' is put in the save to check if it's ok and initialized
ah ok. which bytes should be jk
? i only saw the rb
bytes listed in the sav format documentation
0x813E and 0x813F
https://littlesounddj.fandom.com/wiki/File_Management_Structure
ah, thanks!
On Fri, Nov 27, 2020 at 9:53 AM Stijn Frishert notifications@github.com wrote:
0x813E and 0x813F
https://littlesounddj.fandom.com/wiki/File_Management_Structure
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/stijnfrishert/libLSDJ/issues/93#issuecomment-734872190, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABLMCWLLCNPJ5LW44W5I6WDSR64P7ANCNFSM4UAEI52Q .
This is sort of a request, sort of a question and sort of a cry for help. I have a save file that doesn't seem healthy when used outside an emulator or game boy. It runs and loads well, but in the project screen of LSDJ the option to save/load is gone. Also, using eg. libLSDJ to extract song data does not work. Specifically:
ERROR: the SRAM initialization bytes aren't set to 'jk'
Could libLSDJ try to help fixing small structural errors or such? Or maybe it's too risky even as an experimental feature?