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

It has just been discovered that internal backup files cannot be used for yabasanshiro.


About EXT4M memory backup files:
Do not modify the backup method of this software . There is no error in the transferred information. Yabasanshiro needs a 512Cluster format. The bksv512k.bin is a 256Cluster format and needs to be converted with “SS Ram Backup Parser 0.9.9”

The problem is that the 512cluster format is different from the source file after being modified back to the 256cluster format.This file cannot be used on the real HW. We need a perfect backup management software.
 

Attachments

  • B5FAC4ED-8EEA-4DCB-9C71-4BE00EE76FAB.jpeg
    B5FAC4ED-8EEA-4DCB-9C71-4BE00EE76FAB.jpeg
    273.4 KB · Views: 165
  • C9AD1DB4-123B-433B-81C8-4A065B5BBC9C.jpeg
    C9AD1DB4-123B-433B-81C8-4A065B5BBC9C.jpeg
    691.4 KB · Views: 156
  • 60A60E85-57C7-4834-85C2-533DC82F5D6A.jpeg
    60A60E85-57C7-4834-85C2-533DC82F5D6A.jpeg
    1,004.5 KB · Views: 156
Last edited:
But still, there is a possibility, that this cart somehow alters bup library when do bup_init at boot (when it copy some bios bup code to ram). So, may you, please, confirm if this cart have some boot rom with boot code (0x22000000).
I suspect it, because, according to this thread, second block is used as spearator and must be empty, but in your dump, its not empty. So, possible that this is some altered format used by this backup ram cart (and it patches bup functions somehow).
So, may you check 0x22000000?

Maybe your dump will be interesting for hitomi2500 or slinga
 
Last edited:
I used phoebe (ODE) and rmenu software
 

Attachments

  • 9646E08C-F0DA-40AE-B149-02D9C8C4A810.jpeg
    9646E08C-F0DA-40AE-B149-02D9C8C4A810.jpeg
    1,003.7 KB · Views: 148
  • B93FCA3B-F5E7-4836-824C-17BE9276BCB6.jpeg
    B93FCA3B-F5E7-4836-824C-17BE9276BCB6.jpeg
    916 KB · Views: 142
  • 06A2B451-7764-463B-9530-7FF8281DAA76.jpeg
    06A2B451-7764-463B-9530-7FF8281DAA76.jpeg
    1,003.4 KB · Views: 153
  • 745590DD-E013-4A5A-89F8-60AC8A626DAD.jpeg
    745590DD-E013-4A5A-89F8-60AC8A626DAD.jpeg
    1 MB · Views: 160
I see, thank you.
But still interesting, if dump is 1:1 why it processed ok on real hw, and not on emulators. I still suspect some tricks from cart logic :) Anyway, what is it. this cart? According to Yabause wiki 4Mbit backup ram cart id is 0x21 (i think its true for 1st party carts), but this cart id is 0x1
 
Last edited:
visit here and check this file:

 

Attachments

  • ssmemorytzmwxdump 2.zip
    831 bytes · Views: 150
By the way, great idea and realization. And not depends on cart port connector quality (condition).
From view on dump, thats why it use 256b block (as "BackupRam Format" placed from 0x00 to 0xFF in ssmemorytzmwxdump.BIN ) on your cart.
 
Some information,
Saturn BIOS only supports these two Flash chips: AT29C040(512blocks)and AT29C040A(256blocks),I am using AT29040A now, so my file is 256 format!yabasanshirno maybe AT29C040 ,512 format?
 

Attachments

  • F35327D4-D350-4C04-B0A9-4C8F41203C2A.jpeg
    F35327D4-D350-4C04-B0A9-4C8F41203C2A.jpeg
    875.8 KB · Views: 166
Just created blank empty 1mb file cart.bin and set it in Yabause as 4Mbit cart. After power/bios memory manager/power off cycle, the file have 512b header block. Never got inside of bios bup routines, but using infromation you give, probably it set block size by reading vendor/device id of eeprom. So, if it is true, then emulators have hardcoded vid/device id for at29c040. Didnt checked sources, just suppose it.
 
Update:
v0.212b - few fixes

From Yabause code (src/bios.c):
C:
static u32 GetDeviceStats(u32 device, u32 *size, u32 *addr, u32 *blocksize)
{
   switch(device)
   {
      case 0:
         *addr = 0x00180000;
         *size = 0x8000;
         *blocksize = 0x40;
         return 0;
      case 1:
         if ((CartridgeArea->cartid & 0xF0) == 0x20)
         {
            *addr = 0x04000000;
            *size = 0x40000 << (CartridgeArea->cartid & 0x0F);
            if (CartridgeArea->cartid == 0x24)
               *blocksize = 0x400;
            else
               *blocksize = 0x200;

            return 0;
         }
         else
            return 1;
      default:
         *addr = 0;
         *size = 0;
         *blocksize = 0;
         return 1;
   }

   return 1;
}

So, if it is not 32Mbit cart (0x24) then blocksize will be always 512 (or 1024 for 32Mbit)
 

Attachments

  • sdloader0212b.zip
    152.7 KB · Views: 137
Last edited:
Sorry, and thank you for info! There was bug, and now its fixed.

v0.215
- cleanup and experimental tweaks (tested ok)

v0.214
- fix and speedup
Now 648kb binary loads and executes in 8s (so, transfer is around 80kb/sec)
 

Attachments

  • sdloader0214.zip
    152.7 KB · Views: 129
  • sdloader0215.zip
    152.9 KB · Views: 134
Last edited:
Update:
v0.217
- use part of sh2 cpu cache to store frequently accesed fat driver structures and buffers

Thank you, braza!

You may get new v0.216, it have little more speed comparing to 0.215 (648kb in 7.8s, so, transfer speed is around 83kb/sec).
 

Attachments

  • sdloader0216.zip
    153 KB · Views: 127
  • sdloader0217.zip
    153.1 KB · Views: 134
Last edited:
For yabasanshiro, you need to run it through my converter. The format is not 1:1
Hello,check zip file !The file(Bksv4m.bin)cannot be used by yabasanshiro & SSF through your converter.
About half of the items have been lost.

Another file(Bksv4m256to512.bin)can be used by yabasanshiro & SSF after being converted to 512 through SS RAM Backup parser0.9.9.the items have not been lost.
 

Attachments

  • BKSV4M256to512.zip
    38 KB · Views: 136
Last edited:
Update:
v0.217
- use part of sh2 cpu cache to store frequently accesed fat driver structures and buffers

Thank you, braza!

You may get new v0.216, it have little more speed comparing to 0.215 (648kb in 7.8s, so, transfer speed is around 83kb/sec).
0217 perfect,1024K in 10.30s,speed 99K/S?
 
0217 perfect,1024K in 10.30s,speed 99K/S?
Thank you! 99Kb/sec seems real.

Also, for new test version v0.218a, tried to inline some critical asm code into sd card block transfers functions. After some polishing, it get overhead little lower, and saves few more instructions per byte transfered.

v0.218b - more polishing, few more instructions per byte saved (tested ok on real HW, speed increased)
 

Attachments

  • sdloader0218a.zip
    153.2 KB · Views: 117
  • sdloader0218b.zip
    153.3 KB · Views: 132
Last edited:
Speed:
0.217:105K/s
0.218A:109K/s
0.218B:112K/s
 

Attachments

  • 98446454-71C9-4299-94B3-598E3F288034.jpeg
    98446454-71C9-4299-94B3-598E3F288034.jpeg
    1.2 MB · Views: 147
  • 17AC8F5B-CF5D-453A-ADE5-B3CB83F42924.jpeg
    17AC8F5B-CF5D-453A-ADE5-B3CB83F42924.jpeg
    1.2 MB · Views: 142
  • D7CD4596-2E72-43EF-AFF4-C55FE3262FAA.jpeg
    D7CD4596-2E72-43EF-AFF4-C55FE3262FAA.jpeg
    740.1 KB · Views: 136
tzmwx, thank you! Im glad that it increasing speed even by small steps, that means, those optimizations are worth it.
Here is current build v0.218c, few more optimization affecting write speed (to sdcard).

In next step, i want to add backup ram cart vendor id /device id reading. So would be nice to test at your cart flash.

tzmwx, please, may you try sdloader_test.zip version attached to message? I added vendorid/deviceid reading. If it will display correct ids for your flash, then i will add restore function for your cart. If it will display 0x41/0x61 - it means it didnt enter identification mode.
 

Attachments

  • sdloader0218c.zip
    153.3 KB · Views: 128
  • sdloader_test.zip
    91 KB · Views: 147
Last edited:
Back
Top