slinga
Established Member
Still working on libslinga (GitHub - slinga-homebrew/libslinga: Sega Saturn save game library).
I'm trying to think of an algorithm to read a Sega Saturn save file without the need for malloc(), large stack space, or a large global buffer. For Save Game Copier I used jo_malloc() to allocate a buffer to store the block ids. With libslinga I am not assuming I have access to malloc(). The official BUP library preallocated a large section of memory (4k bytes?) to use for this table.
Additional information:
- Save-Game-Copier/backends/sat.h at master · slinga-homebrew/Save-Game-Copier
- Save-Game-Copier/backends/sat.c at master · slinga-homebrew/Save-Game-Copier - getSatBlocks() reads the block IDs into a dynamically allocated buffer. getSATSave() reads the save by walking the list of block IDs.
*// -- to complicate matters, the block ids themselves can extend into multiple blocks. This makes computing the block count tricky* this is what makes parsing the SAT table tricky. In SGC I reduced the complexity by just reading the entire table into a dynamically allocated array and working with that.
Assuming a maximum save of ~32k for internal memory
-- by my calculations 29,548 byte save will take 510 blocks. 2 blocks are overhead. 512 blocks x 64 bytes per block = 32k.
-- 510 blocks * 2 bytes each = 1020 bytes for the SAT table.
Assuming a maximum save of 256k:
- I need 4,521 blocks
- 4,521 * 2 = 9,042 bytes for the sat table
I'm trying to think of an algorithm to read the SAT blocks without having to allocate the SAT table. I think there might be something to reading the save backwards, but I haven't come up with an algorithm yet. I will also need the reverse to be able to write a save as well.
I plan to think hard this weekend.
I'm trying to think of an algorithm to read a Sega Saturn save file without the need for malloc(), large stack space, or a large global buffer. For Save Game Copier I used jo_malloc() to allocate a buffer to store the block ids. With libslinga I am not assuming I have access to malloc(). The official BUP library preallocated a large section of memory (4k bytes?) to use for this table.
Additional information:
- Save-Game-Copier/backends/sat.h at master · slinga-homebrew/Save-Game-Copier
- Save-Game-Copier/backends/sat.c at master · slinga-homebrew/Save-Game-Copier - getSatBlocks() reads the block IDs into a dynamically allocated buffer. getSATSave() reads the save by walking the list of block IDs.
C:
//
// SAT structures
//
//
// Saturn saves are stored in 64-byte blocks
// - the first 4 bytes of each block is a tag
// -- 0x80000000 = start of new save
// -- 0x00000000 = continuation block?
// - the next 30 bytes are metadata for the save (save name, language, comment, date, and size)
// -- the size is the size of the save data not counting the metadata
// - next is a variable array of 2-byte block ids. This array ends when 00 00 is encountered
// -- the block id for the 1st block (the one containing the metadata) is not present. In this case only 00 00 will be present
// -- the variable length array can be 0-512 elements (assuming max save is on the order of ~32k)
// -- to complicate matters, the block ids themselves can extend into multiple blocks. This makes computing the block count tricky
// - following the block ids is the save data itself
*// -- to complicate matters, the block ids themselves can extend into multiple blocks. This makes computing the block count tricky* this is what makes parsing the SAT table tricky. In SGC I reduced the complexity by just reading the entire table into a dynamically allocated array and working with that.
Assuming a maximum save of ~32k for internal memory
-- by my calculations 29,548 byte save will take 510 blocks. 2 blocks are overhead. 512 blocks x 64 bytes per block = 32k.
-- 510 blocks * 2 bytes each = 1020 bytes for the SAT table.
Assuming a maximum save of 256k:
- I need 4,521 blocks
- 4,521 * 2 = 9,042 bytes for the sat table
I'm trying to think of an algorithm to read the SAT blocks without having to allocate the SAT table. I think there might be something to reading the save backwards, but I haven't come up with an algorithm yet. I will also need the reverse to be able to write a save as well.
I plan to think hard this weekend.