SDLoader v0.12: run binaries from SD Card and backup/restore saves

[Murzik]

So far i've tested with the 0.BIN only, but i'm surprised it didn't work, since the IP.BIN i extracted from the ISO should point to 0x06010000, right?
Atlas uses IP.BIN files for that reason, to ensure the 0.BIN gets loaded at the right location.
I'll see if using the standalone code works, but i doubt it, since it will be loaded at 0x06010000 instead of 0x06004000, except if i modify the IP.BIN i get from the ISO.

Just tried to build sdloader test iso image with ip.bin from Atlas Creator source distrib, thats is configured for 0x06004000. It succesfully boots sdloader.bin. And, if patched to 0x06010000 - it boots sdloader.iso's 0.bin. Cant say anything about multiboot, as never used it, but using ip from Atlas distrib works fine for making bootable sdloader image.

Speaking of SPI mode, maybe it's something like:

It's hard to tell anything without seeing actual spi communication, but, according to that amount of data we have on this bug - its sounds like a good guess. I may provide build with increased delays in spi mode request call. But you need to decide - if this try worth a blank cd?

*UPDATE*
If you will get working Atlas multiboot cd, that loads sdloader binaries, i may provide you more than one sdloader test build (with various delays and optimizations off/on), so you will .. er.. waste your blank cd more effectively

 

[xhul]

Just tried to build sdloader test iso image with ip.bin from Atlas Creator source distrib, thats is configured for 0x06004000. It succesfully boots sdloader.bin. And, if patched to 0x06010000 - it boots sdloader.iso's 0.bin. Cant say anything about multiboot, as never used it, but using ip from Atlas distrib works fine for making bootable sdloader image.

If you will get working Atlas multiboot cd, that loads sdloader binaries, i may provide you more than one sdloader test build (with various delays and optimizations off/on), so you will .. er.. waste your blank cd more effectively

On emulator at least, the Atlas IP.BIN + 0.381 SDLOADER.BIN combo worked like a charm!
That means i can pretty much test a maximum of 50 different versions on a single CD now.
I'll start by building 1 entry per version, but yeah, additional test versions are of course welcome if you have the time to build some.
Now i know what i'll do this weekend, thanks =]

It's hard to tell anything without seeing actual spi communication, but, according to that amount of data we have on this bug - its sounds like a good guess. I may provide build with increased delays in spi mode request call.

Are SPI mode requests made before each read|write attempt?
Cause if yes, having just a single one when the software starts instead might potentially solve the problem entirely.
That's of course assuming SPI mode can persist once activated, and that it's not dangerous that it does.
And if the process of reading|writing somehow causes the SPI mode to vanish, you could put one request at software start, and one after each read|write attempt.
Cause the time used to go back to the main menu and initiate another read|write might represent a long enough delay.
Those are just ideas, i'm completely blind here.

 

[xhul]

I'm just back from having tested the 40 versions i found in this forum, thanks to The Rockin'-B for having spared my CDs.
In a nutshell:

VERSIONS 0.1XX

All those basically follow what i had already discovered about 0.1.
"SD card init error" is always displayed on the first read|write attempt.
Any read|write attempt after that is always successful, including on any other version loaded using "A" from the main menu.

VERSIONS 0.2XX and 0.3XX

All those basically follow what i had already discovered about 0.381.
"SD card init error" is always displayed on all read|write attempts.
If any of those is loaded from a version 0.1XX, all read|write attempts become successful.

CONCLUSION

If i had to guess, i'd say the FAT library change done in 0.2a is probably what caused the "first attempt trick" to stop working.
The new library itself is fine though, since the reads|writes can be completely functional if the "first attempt trick" was performed on any 0.1XX version beforehand.

SPECIAL BEHAVIOURS

That's just for the record, you're most probably already aware of those.

All versions it seems:
Pressing the reset button never resets the console, and the software hangs.
Pretty sure it's because the software was loaded from Atlas, didn't think it was possible though.

0.126a:
Shows "SD card init error" on attempt 1 and "Error opening bkramsv.bin" on all further attempts.
The fact that the messages are different shows that it still follows the expected behaviour.
I believe the code that tries to access bkramsv.bin is simply incorrect.

0.2a:
Shows "Error opening bkramsv.bin" on all attempts.
To be sure, i checked with no module in the slot, and the behaviour is indentical.
I guess it still follows the expected behaviour, just that message has priority over "SD card init error".

0.32>0.374:
Expected behaviour, but the display signal is unstable as f**k.
At best the text flickers significantly.
At worse my Retrotink 2X SCART completely loses the RGB signal when the software starts.
The signal can come back if the link between the A/V port and the Retrotink is interrupted and then restored.

 

[xhul]

For the record, i tried removing the module when at the main menu, and putting it back.
When i do that, i have to reinitialise the card again, which pretty much confirms that it's indeed SPI mode related, at least for versions 0.1XX.

Deactivating SPI mode that way should allow me to try test versions without having to burn them =]
Basically: load 0.127d from CD > activate SPI mode > load test version boot.bin > remove+reinsert module > fresh testing.

 

[aggrippa]

I'm not sure if anyone else has already asked this question, or not, but how do i move save files over from mednafen to the SD Loader. I recently bought one of these off of Etsy, and I got it working. I was told, you can use Yabause to move files, but I only ever got that program to work twice. I saw something about Retroarch, and Beetle Saturn, but Medanfen is the only Saturn emulator, I've gotten to work long enough on my system to get useful saves out of it. I tried moving my save files manually over to bkramsv.bin file, but they don't go inside it manually. I tried using the standard files on the disc that came with it, but it keeps coming up with an error message that reads (files to large), or something like that. It's kind of hard to read on a crt screen. Any help would be apreciated.

 

[aggrippa]

Thank you, tzmwx! Very nice way to avoid searching for spare controller connector, like it!
I added support for analog pad, and, also, cant resistate to tweak byte shifting a little, now total instructions count per 1 byte = 136. DIdnt tested it on real hw yet. But at least it works now on mednafen with "ss.input.port1 3dpad" option. Would be cool if you will try it on your config!

How did you get it to work with Medafen? I've been trying to port my Mednafen saves over to the bkramsv.bin, so I can port it over to my physical Saturn.

 

[xhul]

I'm not sure if anyone else has already asked this question, or not, but how do i move save files over from mednafen to the SD Loader. I recently bought one of these off of Etsy, and I got it working. I was told, you can use Yabause to move files, but I only ever got that program to work twice. I saw something about Retroarch, and Beetle Saturn, but Medanfen is the only Saturn emulator, I've gotten to work long enough on my system to get useful saves out of it. I tried moving my save files manually over to bkramsv.bin file, but they don't go inside it manually. I tried using the standard files on the disc that came with it, but it keeps coming up with an error message that reads (files to large), or something like that. It's kind of hard to read on a crt screen. Any help would be apreciated.

Murzik seems to be a little busy, but maybe we can help.
It's likely that the Mednafen save format isn't the same as the one used by the SDLoader software, which is why it fails to restore the saves on real hardware.
If you provide your Mednafen save file, i can investigate, and maybe do the conversion for you.

 

[aggrippa]

Murzik seems to be a little busy, but maybe we can help.
It's likely that the Mednafen save format isn't the same as the one used by the SDLoader software, which is why it fails to restore the saves on real hardware.
If you provide your Mednafen save file, i can investigate, and maybe do the conversion for you.

sure. Do you want me to pm my files, or just post them on the forums?

 

[xhul]

sure. Do you want me to pm my files, or just post them on the forums?

I check this thread daily, but i only log in when i have to reply something, so a post would offer better visibility as far as i'm concerned.
But if for some reason you want some privacy regarding the data, a PM would be more appropriate.
You call =]

 

[aggrippa]

I check this thread daily, but i only log in when i have to reply something, so a post would offer better visibility as far as i'm concerned.
But if for some reason you want some privacy regarding the data, a PM would be more appropriate.
You call =]

Sadly this site doesn't seem to like BKR, SMPC, BCR files, so I can't send them through here. Thank you for the offer though.

 

[RubyRoid]

Sadly this site doesn't seem to like BKR, SMPC, BCR files, so I can't send them through here. Thank you for the offer though.

Hello, try to put the files into a zip archive and upload them that way.

 

[aggrippa]

Hello, try to put the files into a zip archive and upload them that way.

That's a good idea RR

 

[aggrippa]

That's a good idea RR

except it apparently doesn't work that way either.

 

[xhul]

except it apparently doesn't work that way either.

In the mean time, i took a look at the Mednafen save system, and i think i found why SDL doesn't digest the saves right away.
Additionally, i found a way to make them compatible.
So, if you manage to upload the data somewhere, be sure to include all the .bkr files located inside the "sav" directory in Mednafen, each should have a 32KB size.

 

[aggrippa]

In the mean time, i took a look at the Mednafen save system, and i think i found why SDL doesn't digest the saves right away.
Additionally, i found a way to make them compatible.
So, if you manage to upload the data somewhere, be sure to include all the .bkr files located inside the "sav" directory in Mednafen, each should have a 32KB size.

Yes. I already discovered the BKR files are the only ones that seem to matter, when converting from Mednafen to other files. RR used several programs before finding one that works. I'll post the link below.
ss-save-parser available here:

Releases · hitomi2500/ss-save-parser

Parser for Sega Saturn images of various save media. - hitomi2500/ss-save-parser

github.com

 

[xhul]

Yes. I already discovered the BKR files are the only ones that seem to matter, when converting from Mednafen to other files. RR used several programs before finding one that works. I'll post the link below.
ss-save-parser available here:

Releases · hitomi2500/ss-save-parser

Parser for Sega Saturn images of various save media. - hitomi2500/ss-save-parser

github.com

That's actually the tool i intended to use for you.
Glad you managed to do everything by yourself =]