Posts: 923
Threads: 7
Joined: Jan 2012
Reputation:
47
Location: Argentina
04-29-2013, 12:23 AM
(This post was last modified: 04-29-2013, 12:23 AM by KrossX.)
Auto eject is unchanged in ma'mess. I just copy/pasted it, basically. That means, it does a CRC check of the entire thing and only works on cards in slot0. Since it's only slot0, it ain't mulitap friendly, and that is to avoid the max of 8x 64MiB CRC checks on save... and load.
@avih: Should be harmless I think. You would be able to select PSX cards in the manager but it wouldn't even be recognized as formatted for the BIOS/Games.
Posts: 923
Threads: 7
Joined: Jan 2012
Reputation:
47
Location: Argentina
Done! New build with a quicky memcard check. v7
Worst but fastest check method and easiest to implement from the two I thought. Simply store a 64bit XOR checksum in the memcard on write. During state save and loading, instead of doing any CRC check, just get that checksum. Since it's just reading 8 bytes during save/load per card, the sio part of savestates should be quite faster than when doing a CRC check for 8MB+ files. Thus, now it ain't restricted to slot0 as the original check allowing for auto-eject multitap support.
The region is at 0x408 which is by the end of the second page which is supposedly unused. Each page has a ECC region of 16bytes (12 + 4) so if something checks this unused page, it will show up as corrupted. Seems to work fine so far though.
For the PSX memcards, I just let it use the old CRC check. This ones are small enough to not care.
===
The other method was to have a list of last sectors/pages accessed then do a CRC of the Superblock up to FAT pages (42KiB), and the sector list. Also, including other info in the savestate like type and size for quick fail.
On save, this would mean filling the entire thing making CRCs for each page in the list. It should still be a lot smaller than a CRC to an 8MiB file.
On load, the check could fail on the first(s) CRCs saving some CRC checks. A potential of 1 CRC check per card on load, if the directory/FAT is different.
It will make savestates incompatible though.
Posts: 923
Threads: 7
Joined: Jan 2012
Reputation:
47
Location: Argentina
04-30-2013, 02:47 PM
(This post was last modified: 04-30-2013, 05:22 PM by KrossX.)
The problem with the CRC check was just the potential of 8x 64 MiB to check, if using mulitap. That's why it was disabled for multitap.
I suppose the warning must be based on PS2 expecting 0xFF's, I'll play with the transfers and see what I can find about the timestamps.
#EDIT: Must have messed up something when prettifin' the code before release. Cuz it ain't formatting no more. >_<
#EDIT: It was the checksum. Since it couldn't confirm sector clear, and the page was corrupted as it didn't match ECC. >_<
v7 method is officially discarded.
Posts: 1.909
Threads: 28
Joined: Jun 2010
Reputation:
75
Can't we store this data at the file after the "official" memory card area, such that we use it for checksums, but the BIOS doesn't see this area at all?
Posts: 923
Threads: 7
Joined: Jan 2012
Reputation:
47
Location: Argentina
Well, it's supposedly unused and there ain't a checksum so there's a chance it ain't touched during format. But, the real test would be to fill up the memory card until the last save shows up right before it. So the card would have to be totally full.
It should be backwards compatible as v7 though, in the sense that the card works fine (except format in that case) and if there was no checksum it wouldn't match the previous savestate and just enable the auto-eject. No need to change savestate info, so savestates would also still be compatible.