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

Thank you very much! I will optimize it more for next version, as there is already few ideas how to cut instructions per byte count.
0.127c can work on real hardware.I got a 512K file,
but , the 4M memory card file is only 512K,Incompatible with SSF,yaba....,this file needs 1024K in EMU
 
0.127c can work on real hardware.I got a 512K file,
but , the 4M memory card file is only 512K,Incompatible with SSF,yaba....,this file needs 1024K in EMU
Please, may you attach this file? And what it shows at cart_id and [1] id and size?
Oh, i see, for backup ram carts, saturn use 8bit wide data access (same as for internal 8bit sram). I will update code. Anyway, please, upload your resulted file and info about id and size
 
Last edited:
Ext 512K (4Mb) >>> File:1024K

Int 32K >>> File:64K
 

Attachments

  • 65DC7D36-040C-4445-9236-39CE9BD649CE.jpeg
    65DC7D36-040C-4445-9236-39CE9BD649CE.jpeg
    176.3 KB · Views: 154
  • FA3A7312-CB13-4984-B769-32220C925F49.jpeg
    FA3A7312-CB13-4984-B769-32220C925F49.jpeg
    1.3 MB · Views: 150
Wrong cluster size?
 

Attachments

  • 0CC9689C-A686-4707-87A7-9E61B46D116C.jpeg
    0CC9689C-A686-4707-87A7-9E61B46D116C.jpeg
    511.4 KB · Views: 150
  • 0A8E6B99-6446-4713-84A9-68449BDACDFF.jpeg
    0A8E6B99-6446-4713-84A9-68449BDACDFF.jpeg
    138.2 KB · Views: 141
Some speedup tricks :
- When dumping internal backup memory or cartridge, bytes at even address are FFh and consequently don't need to be dumped.
- Bit shift on Saturn is not super efficient, so instead you may want to use a mask table and do an AND to get the status of each bits.
- If not already done, you may want to pre-record the values to write to peripheral when a bit is zero and do the same when a bit is 1 too.

Code:
void spi_send_byte(unsigned char byte_to_send)
{
    int i;
    unsigned char mask[8] = {0x80, 0x40, 0x20, 0x10, 0x08, 0x04, 0x02, 0x01};

    for(i=0; i<8; i++) // Unroll the loop may be a bit faster
    {
        if(byte_to_send & mask[i])
        {
            PDR1 = constant_value1; // CS=0, MOSI=1, CLK=0
            PDR1 = constant_value2; // CS=0, MOSI=1, CLK=1
        }
        else
        {
            PDR1 = constant_value3; // CS=0, MOSI=0, CLK=0
            PDR1 = constant_value4; // CS=0, MOSI=0, CLK=1
        }
    }
}

The sample code above is completely untested, so for example you may need to verify if SPI clock polarity is correct, if MSB or LSB should be sent first etc.
BTW, Gamer's Cartridge uses SPI bitbang too, but the AND operation above is done on cartridge side. It's like blast processing but for SD card access :D
 
tzmwx, try this build (0.127d_bug) or (0.127d_bug2, have few possible fix hardcoded for dumping 4mbit card, hope it helps)


Actually, i tested code on Yabause, and it get correct header structure in dump, of course it was modified to not use spi communication, but fat fs layer is still used. So, in this build i lowered buffer size for backup function.

Thank you, cafe-alpha. I did something similiar, just trying to keep everything, including masks in scratch/arguments registers, and not loading anything in actual bit in/out process to minimize count. Anyway, i already migrated codebase to new fat library, probably it will be more effective in means of speed (will see when it will be tested).
 

Attachments

  • sdloader0127d_bug.zip
    75.9 KB · Views: 125
  • sdloader0127d_bug2.zip
    76 KB · Views: 121
Last edited:
New version 0.2a. Hits 60kb/sec transfer speed now! No more need to place files for saving, SDLoader will create it if needed.

Changed fat library. It is only test release. But basic functions works ok (load and run binaries, dumping internal backup ram)

Just for test, dumped simple action replay cart (without backup ram) with this version (of course, modified a little), 256kb rom mapped at 0x02000000. It dumped fine in few seconds and after transfering to pc, running fine in Yabause without issues. So, i hope, it will dump your 4mbit backup ram now without errors, tzmwx.
 

Attachments

  • sdloader02a.zip
    152.4 KB · Views: 131
Last edited:
Is possible to write action replay?
Yes, by setting address and data lines to mimic jedec eeprom erase/write sequences it is possible to write onboard eeprom, and if /we properly decoded on cart. But it is a feature for later version.
 
New version 0.2a. Hits 60kb/sec transfer speed now! No more need to place files for saving, SDLoader will create it if needed.

Changed fat library. It is only test release. But basic functions works ok (load and run binaries, dumping internal backup ram)

Just for test, dumped simple action replay cart (without backup ram) with this version (of course, modified a little), 256kb rom mapped at 0x02000000. It dumped fine in few seconds and after transfering to pc, running fine in Yabause without issues. So, i hope, it will dump your 4mbit backup ram now without errors, tzmwx.
The files dumped by 0.127d-bug & 0.2a cannot be directly used by the yabasanshiro,and the items are still lost. need to use the segasaturn RAM Backup parser 0.9.9 to convert them to SH2 and 512 for normal recognition。
 
Update:
v0.21 - added aligned access to external ram cart (tzmwx, check this build too)


The files dumped by 0.127d-bug & 0.2a cannot be directly used by the yabasanshiro,and the items are still lost. need to use the segasaturn RAM Backup parser 0.9.9 to convert them to SH2 and 512 for normal recognition。
Please, try this build (sdloader_test) with external cart backup ram viewer (UP/DOWN to scroll) and tell if its show header and saves ok or same as in your dumps? Because, on Yabause it works without errors, and dump exactly 1:1 as ext backup ram (i may only suspect that at real hw byte accessing to even adresses at cs1 cause some exception, which affect integrity of dump - if it is, than just need to align reading to only odd bytes. But anyway, byte read at even addresses of internal sram didnt caused any problems, maybe its smpc involving while access to cs1. Anyway, lets see what this build will show about reading extram)
 

Attachments

  • sdloader_test.zip
    92 KB · Views: 118
  • screen00.jpg
    screen00.jpg
    139.4 KB · Views: 129
  • screen01.jpg
    screen01.jpg
    139.4 KB · Views: 127
  • screen02.jpg
    screen02.jpg
    120 KB · Views: 135
  • screen03.jpg
    screen03.jpg
    134.3 KB · Views: 132
  • sdloader021.zip
    152.7 KB · Views: 134
Last edited:
Update:
v0.21 - added aligned access to external ram cart (tzmwx, check this build too)



Please, try this build (sdloader_test) with external cart backup ram viewer (UP/DOWN to scroll) and tell if its show header and saves ok or same as in your dumps? Because, on Yabause it works without errors, and dump exactly 1:1 as ext backup ram (i may only suspect that at real hw byte accessing to even adresses at cs1 cause some exception, which affect integrity of dump - if it is, than just need to align reading to only odd bytes. But anyway, byte read at even addresses of internal sram didnt caused any problems, maybe its smpc involving while access to cs1. Anyway, lets see what this build will show about reading extram)
sdloader-test:
Same as sav.zip file (bksv512k0127 & bksv512k020),Bksv512k020TO512cluster file has been converted and can be used by yaba.
37CEDA47-904A-4EFB-A6B5-16822DF8EC79.jpeg 4CFB5E69-2B33-42A2-978F-D775276CFB12.jpeg 09798372-9CB2-4974-A46F-DD7235F9C132.jpeg


021 is stuck during storage, and all files in the SD card are lost.
93C36B14-156B-4B4C-83E3-D92D66D29DDE.jpeg
07DE870D-8A0D-421B-9FCA-897325EC1517.jpeg
 

Attachments

  • sav.zip
    30 KB · Views: 117
Last edited:
Updated SDLoader to 0.211:
- removed aligned access to ext backup ram
- added more output info about ext backup ram

to tzmwx:
I see. I will take a look at it and will try to find one of my backup ram carts to debug.
First. May you, please, use Charles MacDonald's Sega Saturn Memory Map Viewer (attached, main.bin, load to 0x06004000, may load from SDLoader, just rename to boot.bin) to check backup RAM header again? You need to check from 24000000 and up, to see if it is same as SDLoader see and dump it, or is it have header lenght as expected?
 

Attachments

  • main.zip
    3.2 KB · Views: 122
  • screen00.jpg
    screen00.jpg
    179.7 KB · Views: 125
  • screen01.jpg
    screen01.jpg
    179.7 KB · Views: 128
  • sdloader0211.zip
    152.8 KB · Views: 113
  • screen02.jpg
    screen02.jpg
    87.7 KB · Views: 141
Last edited:
Same as sav.zip (bksv512k0127.bin & bksv512k020.bin)
 

Attachments

  • ACF39BD9-2A78-4149-B52D-73FFF4279B20.jpeg
    ACF39BD9-2A78-4149-B52D-73FFF4279B20.jpeg
    1.1 MB · Views: 109
  • 381C61A5-3DB6-4728-B878-507B9EEBCB1E.jpeg
    381C61A5-3DB6-4728-B878-507B9EEBCB1E.jpeg
    676.5 KB · Views: 113
  • 92E2B654-1FD2-4535-89C9-885D62095102.jpeg
    92E2B654-1FD2-4535-89C9-885D62095102.jpeg
    697.8 KB · Views: 113
  • 346B58A4-9903-484F-BA56-48017F47BA69.jpeg
    346B58A4-9903-484F-BA56-48017F47BA69.jpeg
    848.5 KB · Views: 115
  • 0C7EF3AA-D0DD-40B1-B10D-AD79E8BBCC70.jpeg
    0C7EF3AA-D0DD-40B1-B10D-AD79E8BBCC70.jpeg
    2.4 MB · Views: 122
I see. First idea to check, what if it mapped not to 0x24000000, but with -0x200 offset (to 0x23FFFE00), thats why its header looks halved. Please, may you check with memory viewer this adress 0x23FFFE00 and up to 0x24000000 to see if it have backup ram header signatures there ("Backup Ram Format").. And just to be sure, pls, check also noncached 0x03FFFE00 - 0x04000000 too
And does this memory cart have some boot rom (mapped at 0x22000000) which runs at console start? I asked, becuase, it have cart id 0x1.

Update:
v0.212 with few optimizations to filesystem. Hope it will give little boost to speed (not tested on real hw yet)
 

Attachments

  • sdloader0212.zip
    152.8 KB · Views: 123
Last edited:
Back
Top