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

[zengzidane]

One idea, how to add a USB port to this device, it should be useful to download the data without TF-reader

@tzmwx​

 

[zengzidane]

@Murzik Hi dude，have one suggestion for SDLoader, could largen the size of letter displaied in next version? On the CRT or small screen, it`s too hard to read, thanks!

 

[Murzik]

Tiny update
Just cleaned my hdd and found unfinished attempt to create generic patch for cd loading functions used in games ( that build with sgl libs) to reroute them to sdloader stub to allow them to work from sd card.
Here is result, the chosen one was unreleased Chelnov/Atomic Runner

To try it, just copy all files from cd to sdcard, and patch 0.BIN with sdloader patch

 

[RubyRoid]

Hello, I've made a small batch of SDLoader modules and put them up for sale on Etsy, feel free to take a look at the result: https://ewasteboutique.etsy.com/listing/1611537274

(To moderators : this is a self-advertisement link, please remove it if it violates any rules)

 

[Murzik]

Sonic Wings Special patch for SDLoader (SDLoader 0.383sws included) As with previous game, just copy all files from (your legally owned) SWS cd to sd card preserving directory structure (to make it short, just copy VSYSSWSP folder to SD root to have in result SD:\VSYSSWSP). Patch 0MAIN.BIN, and run it with provided CFG file (CFG required for proper loading address).

While i started patching this game, i found "hidden" test menu. So, here are two patches actually, one with SDLoader support, and other with SDLoader+TEST MENU enable.

Spoiler: screencap

 

[SAGA]

Sonic Wings Special patch for SDLoader (SDLoader 0.383sws included) As with previous game, just copy all files from (your legally owned) SWS cd to sd card preserving directory structure (to make it short, just copy VSYSSWSP folder to SD root to have in result SD:\VSYSSWSP). Patch 0MAIN.BIN, and run it with provided CFG file (CFG required for proper loading address).

While i started patching this game, i found "hidden" test menu. So, here are two patches actually, one with SDLoader support, and other with SDLoader+TEST MENU enable.

In theory, any game that does not require audio tracks can be run on a TF card. How to modify the boot address? Is there any specific method?

 

[Murzik]

In theory, any game that does not require audio tracks can be run on a TF card. How to modify the boot address? Is there any specific method?

In theory, yes, at least, if particualar game uses blocking cd reads like GFS_Fread - as easy as a walk in the park. Things gets tight on theory, and became complicated, if it using non blocking cd loading/streaming. Although, even in this case, it is possible (again, in theory), for example, if that particular game not using second sh2, to utilise it for sd reading routines. As for modifying boot address, saturn binaries builded/compiled not as pic, so probably the most straighforward way is to disassemble and modify any absolute code addresses/pointers to new position.

 

[capitan tox]

hi...thanks for everything...

I've been following your work for a long time
I tried the boot.cfg file
atomic runner has no problems
but sonic wings loads well and then gives error coff....
do you have help?...

 

[Murzik]

Hi! Thank you very much.

Lets try to find the cause of this error. I decided to start the search from beginning, so i downloaded the patch (SWS_sdloader_patch.zip) myself, and did this (take it as a checklist):

1. Formatted nearest available 16gb sdcard with fat32

2. Patched 0MAIN.BIN from SWS CD with SWS_0MAIN.xdelta (this xdelta patch: YES for sdloader support, NO for TEST MENU) from patch archive SWS_sdloader_patch.zip

xdelta3-3.1.0-x86_64 -d -s 0MAIN.BIN SWS_0MAIN.xdelta 0MAINSD.BIN

MD5 hashes:
da52075e5dd3ae058f27359661f9019f *0MAIN.BIN (original, from SWS CD)
2d0b5e86831cf4c149463fcac12e4094 *0MAINSD.BIN (patched with SWS_0MAIN.xdelta)

3. Now copy to sd card you got in pt.1:
resulted 0MAINSD.BIN, sdl383sw.bin and 0mainsd.cfg (from SWS_sdloader_patch.zip, sdl383sw.bin required for sdl patched SWS to work), and VSYSSWSP from SWSCD.

You will have this structure on your sd card (i renamed sdl383sws.bin to boot.bin, to autoboot it from sdl patched PSKAI cart):

Spoiler: SD card structure

After it, i launched sdl383sws.bin (in my case, it autobooted from sdl patched PSKAI as boot.bin), and then launched 0mainsd.cfg from it. The game runs fine (at least i started first stage, without intention to speedrun it this time 🙂)

So, please, may you repeat those steps according to this checklist (and please, also check md5 hashes to be sure) to see if error still there?

 

[capitan tox]

It seems like I followed the steps correctly.
the only difference is that I use the loader from cd drive ...
basically the game starts...load fine
it makes me select the plane...but then the loading reports coff error....

 

[Murzik]

It would be hard to debug, as in my setup i cant trigger this behaviour. But lets try.
First, about loader versions. You said, you launch sdloader from cd, but, in the end, what exact loader version, that loads 0mainsd binary? Do you use fresh 0.383sws cd burn or you "chainload" 0.383sws from sd after old loader launched from cd, and then (finally!) load 0mainsd from it (383sws)? It is important, as 0.383sws have few fixes for sws, and older loader probably will have problems and will have this error.
Second, why not make use of test menu feature for debugging? 🙂 May you try to use test menu sdl patch? And when you run it, just select TEST GAME with DPAD-U|D =>"A"=>select anything with DPAD-L|R for "TSCL" and "P1" (it is enough to testrun gameplay)=>"A" to start. Is gameplay works?

p.s. If it lets you select the plane, and if we talk here about "TEST MENU NO" version, it means, that patched game code already performed many sdloads and executed few workaround/fixes. BUT. I thought for a moment, maybe you talking about "TEST MENU YES" version, and if yes - then i remember, there is similiar behaviour/error if you plays there with various menus (even, in non patched vanilla cd version).
For example, i dont remember which exact menu option, that allows you to test planes, and it will throw error, if game didnt precached some assest before in this session, by running through (actually, just loading) any stage/testgame. So, im sure you are talking about main (not TEST MENU) game error. Thats right? 🙂

 

[capitan tox]

the version.. yes is 383..
(with the 381 I made beautiful files of my played games)

after many check ....I found defect write above on sd ....brasil.bin..ecc
after the load corrupts the file.....
I thought it was the bad image...but nope...the img is good

in fact I tried 0mainsdt... I didn't see any test menu
I checked the MD5s from the photo you posted (thank you very much)


the file structure inside the SD is the same
I followed the passage you wrote step by step.
I also re-soldered all the contacts (all capacitators ,all ,with the lens).. because I think the corrupt files were due to that..
Now it's very stable..
but (in the test version) it gives me a coff error ( like in the other ver)....
even the game demo gives the same error does not start after the pause..
load the aircraft selection with start..and then crash
..i try to load test menu..crash...
I feel sad....to overcome my frustration..i played a long game of chelnov..he works........great game

 

[capitan tox]

I tried to backup rom.bin from SD (with PSKAISD.BIN)
I saw how it works from yabause..
but on my MK8000 I press "C"...
it doesn't back up...
Maybe my card isn't suitable..
I don't want to give up...I'll try to get an action replay...and I'll try again
add snake game and digger (put in root sd)

 

[capitan tox]

It would be hard to debug, as in my setup i cant trigger this behaviour. But lets try.
First, about loader versions. You said, you launch sdloader from cd, but, in the end, what exact loader version, that loads 0mainsd binary? Do you use fresh 0.383sws cd burn or you "chainload" 0.383sws from sd after old loader launched from cd, and then (finally!) load 0mainsd from it (383sws)? It is important, as 0.383sws have few fixes for sws, and older loader probably will have problems and will have this error.
Second, why not make use of test menu feature for debugging? 🙂 May you try to use test menu sdl patch? And when you run it, just select TEST GAME with DPAD-U|D =>"A"=>select anything with DPAD-L|R for "TSCL" and "P1" (it is enough to testrun gameplay)=>"A" to start. Is gameplay works?

p.s. If it lets you select the plane, and if we talk here about "TEST MENU NO" version, it means, that patched game code already performed many sdloads and executed few workaround/fixes. BUT. I thought for a moment, maybe you talking about "TEST MENU YES" version, and if yes - then i remember, there is similiar behaviour/error if you plays there with various menus (even, in non patched vanilla cd version).
For example, i dont remember which exact menu option, that allows you to test planes, and it will throw error, if game didnt precached some assest before in this session, by running through (actually, just loading) any stage/testgame. So, im sure you are talking about main (not TEST MENU) game error. Thats right? 🙂

I started sgm manager from sd and I noticed how the sd replaces the CD player... it actually takes its place... I noticed that everything that has a folder is not loaded...
it certainly works if pseudokai sends the boot from the card...otherwise it seems to use part of the memory to store the CD...which then seems to mix up all the text files...bizarre...but beautiful

 

[xhul]

Hello there!

I recently acquired a module and it doesn't work.
More specifically, something prevents the SD card from being recognised ("SD card init error" when using the CD, and return to multiplayer when using the PSK patch).
So i started an investigation to figure out why.
First of all, it's worth noting that both the module and card were working fine before they were sent to me, and were in excellent condition when they arrived.
Just in case, i checked the card integrity and nothing indicates that it's faulty at all.

It becomes interesting when you consider that i tested the module on 3 different machines, that are all european saturns originally.
I know it's not supposed to matter, but according to what i read, the video clock rate on NTSC machines is the same as the SH-2, but that's not the case on PAL machines.
Could it be that the SH-2 itself is somehow configured accordingly, causing some low level code based on instruction timing to fail?
Or even simpler: does anybody actually tested a module on a european (PAL) saturn?

Thanks in advance for your time =]

 

[RubyRoid]

It becomes interesting when you consider that i tested the module on 3 different machines, that are all european saturns originally.
I know it's not supposed to matter, but according to what i read, the video clock rate on NTSC machines is the same as the SH-2, but that's not the case on PAL machines.
Could it be that the SH-2 itself is somehow configured accordingly, causing some low level code based on instruction timing to fail?
Or even simpler: does anybody actually tested a module on a european (PAL) saturn?

I'm also quite interested if there may be some incompatibility issue since this is the module I've built and personally tested multiple times before shipping. Everything worked perfectly fine on my Japanese V-Saturn. Then I shipped a replacement which also didn't work at all. I can't imagine the module being internally damaged twice in a row during shipping.

We've been trying to figure it out together, I even ordered a PAL Saturn for tests, but before it arrives it would be great to get some feedback from other users.

 

[fafling]

I know it's not supposed to matter, but according to what i read, the video clock rate on NTSC machines is the same as the SH-2, but that's not the case on PAL machines.
Could it be that the SH-2 itself is somehow configured accordingly, causing some low level code based on instruction timing to fail?

Afaik the sh2 are running at the same frequency as vdp2 in all Saturn models, pal or ntsc.

That frequency is about 1% lower on pal consoles, so both the sh2 and vdp2 run a bit slower.

 

[xhul]

Afaik the sh2 are running at the same frequency as vdp2 in all Saturn models, pal or ntsc.

That frequency is about 1% lower on pal consoles, so both the sh2 and vdp2 run a bit slower.

Yes, 1% seems to match the frequency difference i saw on the source i read.
My current theory (complete speculation) is that some code use instruction timing to handle communication delays, probably as part of the speed transfer optimisation.
Now, if the instruction timing is very tight, and was tested on NTSC machines only, the 1% difference could be unfortunate enough to make the communication fail on PAL machines.

 

[Murzik]

Hi, all! Dont have PAL Saturn, so, cant even test it. Would be helpful to check whats going on there with logical analyzer. Anyway, just as some sort of test, may try old obsolete sdloader versions (before any optimizations were implemented) just to check that it basically works. And sdloader patch for pskai, use basic spi stub, too without most of optimizations, so if you have any possibility, you may try it as a test.

sd cards and spi (cant say anything to cofirm it or not, but i never had any sd card thats not supported spi while used in spi mode)

 

[xhul]

Hi, all! Dont have PAL Saturn, so, cant even test it. Would be helpful to check whats going on there with logical analyzer. Anyway, just as some sort of test, may try old obsolete sdloader versions (before any optimizations were implemented) just to check that it basically works. And sdloader patch for pskai, use basic spi stub, too without most of optimizations, so if you have any possibility, you may try it as a test.

sd cards and spi (cant say anything to cofirm it or not, but i never had any sd card thats not supported spi while used in spi mode)

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.