mirror of
https://github.com/superctr/buram.git
synced 2026-07-09 02:08:27 +00:00
Some minor differences between files created by the BIOS and ones created by this tool #1
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @euan-forrester on GitHub (Feb 17, 2023).
During the course of adding support for Sega CD to my site (https://github.com/euan-forrester/save-file-converter) I noticed a couple of differences between files created by this tool and ones created by the official BIOS. They don't appear to affect the BIOS's ability to read files created by this tool.
0x00. I tried a few values (0xFF,0xA5,0x5A, etc) but couldn't reproduce the output of the BIOS. Not sure if you have any ideas.To be clear, these are super minor issues and don't affect the usefulness of the files created by this tool. Your work here is very impressive, and I'm very grateful for it!
@superctr commented on GitHub (Feb 18, 2023):
First issue I don't really know. The BIOS has an API for reading and writing the first block but I don't think any games are supposed to use it and it isn't part of the save filesystem anyway.
The second issue is because the DIR is made out of ECC-coded blocks. When the BIOS appends a file in a new block, it doesn't initialize the unused area of the new ECC block. So the first half of the new block will most likely contain the leftovers from the last block it decoded. However the BIOS knows how many files are in the DIR so having junk in the unused area doesn't affect the functioning of the BIOS.
@euan-forrester commented on GitHub (Feb 18, 2023):
Heh I'm curious about those API calls that can read/write the first block, but I guess it doesn't matter.
And regarding the second issue: uninitialized memory -- of course :). That explains why I didn't seem to be zeroing in on a particular value when I tried initializing it with various things.
One more note I had is that in my implementation I added a bit of an optimization where it checks the CRC of an encoded block before doing error correction on it, whereas this tool always does error correction then checks the CRC at the end. Not sure if there was a particular reason for this -- maybe I'm missing something?
Regardless, thank you again for everything!
@superctr commented on GitHub (Feb 19, 2023):
Regarding the CRC, the BIOS always performs error correction first, then deinterleaves the data and CRC is checked to verify the integrity of the deinterleaved data (rather than checking if ECC should be done in the first place). I kept this because I wanted my implementation to be close to the BIOS. It is of course possible to skip the reed-solomon error correction altogether if you want to optimize it.
@euan-forrester commented on GitHub (Feb 19, 2023):
Hm interesting that it works that way! Well, it certainly makes sense that you wanted to preserve that behaviour here.
Anyway, thanks again for your work and for answering my questions here!