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

[Guich75]

Hello everyone, and a big thank to Murzik for this amazing project. Finally an easy way to keep my saves safe and also swap them with other Saturns and FPGAs.
My question is: is it possible to load the arcade version of Outrun hidden in the main game from SDLoader? (After Burner II and Space Harrier also have the same feature).To unlock it you need to use pad 2 but I prefer to keep it for SDLoader.
It could be done? Any ideas on this?
When I tried to load Sonic Wings from SdLoader (and I confirm that it works perfectly!) I immediately thought of Outrun.
Thanks and have nice day.

 

[xhul]

Hello everyone, and a big thank to Murzik for this amazing project. Finally an easy way to keep my saves safe and also swap them with other Saturns and FPGAs.
My question is: is it possible to load the arcade version of Outrun hidden in the main game from SDLoader? (After Burner II and Space Harrier also have the same feature).To unlock it you need to use pad 2 but I prefer to keep it for SDLoader.
It could be done? Any ideas on this?
When I tried to load Sonic Wings from SdLoader (and I confirm that it works perfectly!) I immediately thought of Outrun.
Thanks and have nice day.

Hello there =]
Considering how low the speed transfer is on controller ports, i'd say it's likely that once the game has started, everything is in RAM, which means you can probably replace the module by a controller safely.
That's of course assuming the game is patched to actually work from the SDLoader to begin with.
I'm sure Murzik will come to confirm that assumption or not.

 

[RubyRoid]

A quick update for everyone, I just got a PAL Saturn to verify compatibility with SDLoader module and can confirm that it works just fine!
Here's a short clip of it in action: SDLoader on PAL Sega Saturn

 

[SAGA]

Hello, and thanks for the reply =]

The investigation is a bit in a standby state, cause both the seller and me are waiting for some hardware for testing.
But in the mean time, i successfully found somebody kind enough to test his SDL on a PAL machine, and it worked fine.
That means if there's indeed a compatibility issue with PAL machines, only some specific ones (motherboard or whatever) may be concerned.

Regarding the PSK patch, i already tested it as well of course, it always returns to the multiplayer, probably because it fails to read boot.bin.

I haven't tested previous SDL versions yet, but i intended to go that road after more hardware tests.

The problem with the SD theory is that it was tested before shipping, and i still can't see how it could magically become corrupted during the transport, not to mention it never showed any error during intensive testing on PC.
As a matter of fact, i just tested it on my Atari Lynx RetroHQ gamedrive, and it's perfectly recognised.
But because i'm ready to accept that the SD is the culprit, i already purchased another one, and this time, i took non-SDHC (2GB), that i intend to test in both FAT16 and FAT32, just in case.

More feedback soon then.

EDIT:
The seller told me that the size of the SD matters, is that true?
I ask because other than the 8GB (SDHC-C4) included with the module, i also tested a 32GB (SDHC-U1), and i wanted to know if the bigger one is supposed to work or not.

You think the problem is too complicated. The TF card compatibility issue has nothing to do with PAL. It is just a simple TF card compatibility issue. You can try it with a TF card from many years ago. Someone once encountered a situation where 5- 6 TF cards could not be used. Later, I gave him a card that was sure to work and the problem was solved.
In addition, if you really can’t find a usable TF card, you can consider using a large SD card module. This module does not use the LVC125 level conversion chip, but only uses a simple pull-up resistor. The result is very good compatibility. I have tried more than a dozen SD cards of different capacities and brands, and the current test is 100% compatible and can be used normally.

 

[xhul]

You think the problem is too complicated. The TF card compatibility issue has nothing to do with PAL. It is just a simple TF card compatibility issue. You can try it with a TF card from many years ago. Someone once encountered a situation where 5- 6 TF cards could not be used. Later, I gave him a card that was sure to work and the problem was solved.
In addition, if you really can’t find a usable TF card, you can consider using a large SD card module. This module does not use the LVC125 level conversion chip, but only uses a simple pull-up resistor. The result is very good compatibility. I have tried more than a dozen SD cards of different capacities and brands, and the current test is 100% compatible and can be used normally.

I started to consider unlikely causes for a reason.
Indeed, the TF card that came with the module was carefully tested by the seller before shipping.
As a matter of fact, he re-tested the exact same model yesterday.
We now know that Saturn models aren't involved, but that didn't hurt checking.

 

[xhul]

In addition, if you really can’t find a usable TF card, you can consider using a large SD card module. This module does not use the LVC125 level conversion chip, but only uses a simple pull-up resistor. The result is very good compatibility. I have tried more than a dozen SD cards of different capacities and brands, and the current test is 100% compatible and can be used normally.

By "large SD card module", do you mean that the module itself is larger, or that it takes large SD cards?
Cause i've been searching the web and all the available modules i've seen seem to work with (small) TF cards.

#######

As i expected, the new card didn't solve the problem.

So currently, i'm at:
- 2 different modules.
- 3 different cards, including 1 tested & sent by the vendor before shipping, and 1 very similar to the one tested by Murzik (2GB, FAT16, even tested both cluster size configurations).
- 3 different saturns tested by me, and 2 by the vendor (same module+card).
- CD version of the software, as well as PSK patch.
The number of leads grows thin.
I can't help but think the problem comes from something really dumb, but i've tested a lot already.

I think i'm gonna sacrifice one more CD to test version 0.1 just in case, but since the PSK patch doesn't even make it to the software, i don't expect to see a difference.

My next move is gonna be to send one of the modules back to the vendor, as well as the original card that came with it.
We might see a bit clearer, depending on the results of his tests.

 

[SAGA]

By "large SD card module", do you mean that the module itself is larger, or that it takes large SD cards?
Cause i've been searching the web and all the available modules i've seen seem to work with (small) TF cards.

#######

As i expected, the new card didn't solve the problem.

So currently, i'm at:
- 2 different modules.
- 3 different cards, including 1 tested & sent by the vendor before shipping, and 1 very similar to the one tested by Murzik (2GB, FAT16, even tested both cluster size configurations).
- 3 different saturns tested by me, and 2 by the vendor (same module+card).
- CD version of the software, as well as PSK patch.
The number of leads grows thin.
I can't help but think the problem comes from something really dumb, but i've tested a lot already.

I think i'm gonna sacrifice one more CD to test version 0.1 just in case, but since the PSK patch doesn't even make it to the software, i don't expect to see a difference.

My next move is gonna be to send one of the modules back to the vendor, as well as the original card that came with it.
We might see a bit clearer, depending on the results of his tests.

This is the module I'm talking about, which uses an SD card, not a TF card.

 

[xhul]

View attachment 9617This is the module I'm talking about, which uses an SD card, not a TF card.

I see, thanks for your time.
I didn't find any ready-to-use version of it, but it's good to know there's a more compatible module out there.
A least i may have a backup plan if the current investigation never leads anywhere.

 

[xhul]

After having been pretty busy, i went back to the testing.
This time, i tried the 0.1 CD version, and the results were a bit unexpected.

The good news is that i finally managed to save|restore the save RAM.
So at least, it's safe to say that the hardware itself (both module and TF card i used) is probably fine.

However, i'm glad i insisted because for some reason, the very first communication attempt (no matter if it's a backup or restore) always gives an SD card init error.
But once that failure occurred, all subsequent backups|restores work fine.
Because of that discovery, i tried the 0.381 CD version again, since i wasn't sure i did more than one attempt on each session.
I can confirm that on that version, the SD card init error occurs on all attempts.

So here is what we have so far:
0.1 CD -> SD card init error on very first RAM backup|restore | all subsequent RAM backups|restores successful.
0.381 CD -> SD card init error on all RAM backups|restores.
patched PSK -> Always returns to multiplayer (boot.bin read failure assumed).

Now the challengy questions:
Why does 0.1 work and not 0.381?
And why does the very first attempt always fail on 0.1?

 

[Flynn]

After having been pretty busy, i went back to the testing.
This time, i tried the 0.1 CD version, and the results were a bit unexpected.

The good news is that i finally managed to save|restore the save RAM.
So at least, it's safe to say that the hardware itself (both module and TF card i used) is probably fine.

However, i'm glad i insisted because for some reason, the very first communication attempt (no matter if it's a backup or restore) always gives an SD card init error.
But once that failure occurred, all subsequent backups|restores work fine.
Because of that discovery, i tried the 0.381 CD version again, since i wasn't sure i did more than one attempt on each session.
I can confirm that on that version, the SD card init error occurs on all attempts.

So here is what we have so far:
0.1 CD -> SD card init error on very first RAM backup|restore | all subsequent RAM backups|restores successful.
0.381 CD -> SD card init error on all RAM backups|restores.
patched PSK -> Always returns to multiplayer (boot.bin read failure assumed).

Now the challengy questions:
Why does 0.1 work and not 0.381?
And why does the very first attempt always fail on 0.1?

My experience has been exactly the same where I can only get it to work on 0.1 and only backup/restore.

 

[xhul]

My experience has been exactly the same where I can only get it to work on 0.1 and only backup/restore.

Nice, i was starting to think i'm the only cursed user.
We'll get to the bottom of this.

#######

Just back from another testing session, and i think i made an interesting discovery.
But hold on to your butts, cause that's some crazy testing wizardry.
On 0.1, the first attempt, despite it fails, clearly allows the FAT to be read properly, which is why all the subsequent attempts succeed.
So i thought, how permanent is that activation?
Well, to try to answer that, i tested something i really thought would lead nowhere, but it did.
Note that i used a modchip to read the CDs:
1) Load 0.1 from the CD.
2) Make one backup|restore attempt fail, and go back to the SDL main menu.
3) Open the CD tray, and replace the 0.1 CD by the 0.381 one.
4) Close the CD tray, and immediately press the reset button on the console.
At that point, 0.381 loads, and guess what? no SD card init error.
Then i thought, let's see if that works with the patched PSK as well, and the answer is yes, boot.bin gets loaded successfully.

What does it mean?
Well, my guess is that during|after the very first backup|restore attempt, the code from 0.1 initialises some FAT-related data somewhere in RAM, and that a reset doesn't cut the power long enough for it to expire.
But still, that doesn't quite explain why i have to go through all that while 0.381 works right away for most users.

More testing results to come, stay tuned...

 

[RubyRoid]

My experience has been exactly the same where I can only get it to work on 0.1 and only backup/restore.

What's your console revision? Asking in case there is some hardware incompatibility with some systems.
Also we've just discovered with @xhul that our PAL VA9 systems are not exactly the same on the inside.

 

[xhul]

What's your console revision? Asking in case there is some hardware incompatibility with some systems.
Also we've just discovered with @xhul that our PAL VA9 systems are not exactly the same on the inside.

Don't open the machine, just let us know the first 4 characters of the serial number (sticker at the back).
Also, i wanna point that PAL-VA5 motherboards might vary as well, considering one of my contact has one that shows no problems with the SDL software.

 

[Flynn]

Don't open the machine, just let us know the first 4 characters of the serial number (sticker at the back).
Also, i wanna point that PAL-VA5 motherboards might vary as well, considering one of my contact has one that shows no problems with the SDL software.

My serial number starts in AD65
Happy to provide more information if it helps

 

[xhul]

My serial number starts in AD65
Happy to provide more information if it helps

A VA5 made in indonesia then, thanks.
Same as my two VA5 actually, which are both concerned by the problem.
What's the original region though (EU|USA|JPN)?

 

[Flynn]

A VA5 made in indonesia then, thanks.
Same as my two VA5 actually, which are both concerned by the problem.
What's the original region though (EU|USA|JPN)?

It is a EU region console

 

[xhul]

It is a EU region console

Cool, thanks again for your time.
Regarding the potential hardware part of the problem, we already have obvious differences between a concerned VA9-PAL unit and a non-concerned one.
When it comes to VA5-PAL units, i asked my contact to provide some photos of his, since it's the only non-concerned one of the 4 we have.
If he agrees (i can't guarantee anything), i'll be able to compare the photos with my 2 concerned VA5-PAL units.

 

[xhul]

In case we never solve the issue, i found a new trick =]
I believe it's the most convenient way to make 0.381 work on machines that aren't compatible with it natively.
You basically use 0.1 to enable the proper communication with the TF card, and then boot 0.381 from it.
You just need 1 CD, and of course a way to boot from it (swap or PSK cartridge or modchip).
There you go:

1) Burn the 0.1 ISO (sdloader.zip, available on the very first post of this forum).
2) Put the 0.381 boot.bin on the TF card (sdloader0381.zip, available on the very first post of this forum).
3) Boot from the 0.1 CD on the console.
4) On the main menu, press A.
5) "SD card init error" is displayed, press START to return to the main menu.
6) On the main menu, press A again.
7) "BOOT.BIN" is displayed, press START to load it.
8) Wait until the 0.381 main menu is displayed (approximately 10 seconds).

Having to do that each time you want to use the latest version is a significant time loss, but it's the best way i found so far.
The method is identical if you have an ODE installed, just you boot the 0.1 ISO from it instead of burning a CD.
If you have a way to do that, running the 0.1 binary from 0x06004000 manually should work as well.

It's likely that some other versions than 0.1 allow to boot 0.381 the same way, but burning 1 CD to test each of them isn't exactly seducing.
I actually tried to inject the software on a multiboot CD (Atlas), but i never went past the SEGA logo so far.
@Murzik: By any chance, can you provide the IP.BIN used to create your ISOs? (cause i believe the one i created manually from the ISO might be the reason why your software doesn't work on Atlas).

 

[Murzik]

I actually tried to inject the software on a multiboot CD (Atlas), but i never went past the SEGA logo so far.

It's because included sdloader.iso image have ip and sdloader exectuable (0.bin) builded for 0x06010000. And standalone sdloader executable (sdloader.bin) builded for 0x06004000. And thats all difference between 0.bin in sdloader.iso and sdloader.bin. So, choose one binary: 0.bin (0x06010000) from iso, or sdloader.bin (0x06004000), that suits your multiboot CD requirements.

About sd card init error . Its very difficult to trace cause of this behaviour, just because i cant repeat it on my saturn hardware. Probably some sensitive timings/delays, that breaks in that exact hw configuration when trying to set sd card in spi mode. Its possible to debug it.

 

[xhul]

It's because included sdloader.iso image have ip and sdloader exectuable (0.bin) builded for 0x06010000. And standalone sdloader executable (sdloader.bin) builded for 0x06004000. And thats all difference between 0.bin in sdloader.iso and sdloader.bin. So, choose one binary: 0.bin (0x06010000) from iso, or sdloader.bin (0x06004000), that suits your multiboot CD requirements.

I see, thanks for the clarification.
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.

About sd card init error . Its very difficult to trace cause of this behaviour, just because i cant repeat it on my saturn hardware. Probably some sensitive timings/delays, that breaks in that exact hw configuration when trying to set sd card in spi mode. Its possible to debug it.

Yeah, a delay issue was part of my initial theory.
It's interesting to see that on 0.1, the issue completely vanishes after the very first attempt.
Speaking of SPI mode, maybe it's something like:

ATTEMPT 1:
- Code: request to set card in SPI mode sent.
- HW: SPI mode activation starts.
- Code: attempt to read file system made -> fails cause SPI mode activation still in progress.
- HW: SPI mode activation completes (but too late!).
ATTEMPTS 2+:
- Code: request to set card in SPI mode sent -> ignored cause SPI mode already activated.
- Code: attempt to read file system made -> succeeds cause SPI mode indeed activated.

It's even more interesting that once attempt 1 fails on 0.1, all reads|writes become successful on 0.381 as well (i would suspect on all other versions actually).
And once it's done, you can even power off the console for less than 3-5 seconds and all reads|writes are still OK.
I initially thought a RAM location was involved to explain that, but maybe the juice simply allows the card to remain in SPI mode?