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.
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.
Was the CRC check a problem? I'm using 2x 64MB cards and didn't notice much delay.
Might just be used to it now though.
I'm testing the v7 code with my various cards now, hope it goes well
Edit:
Getting a "(FileMcd) Warning: writing to uncleared data." when copying a PSX save back onto a EPSXE memcard. Is that expected? (Copied that same save from the EPSXE card onto my PS2 card without issue. Nice!
)
Edit2:
That save I copied back does load in EPSXE but somehow it doesn't show up in the PCSX2 bios anymore.
So EPSXE can read it but the PS2 has some kind of issue with it. Could it be the last access time stamp?
I noticed those don't seem to work.
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.
New build!
v8
The warning was indeed important, because the PS2 memcard resets the block to FF's but the PS1 doesn't. The write function xor's the values before doing the file write, so the PS1 memcard gets messed up. Couldn't even be formatted cuz after writting all zeroes to clear the page, nothing more could be written into it. Just added a simple write for PSX memcards.
The auto eject changes were left unchanged except the checksum thing being removed, leaving only the CRC check. That means the CRC is currently unrestricted. Good for testing how slow could it be with 8x 64 MiB cards plugged.
As for the lack of dates on PSX saves, that's just a feature that ain't on the PSX file system. Which makes me think that just a PS2 CRC check of superblock + FAT could be enough, without any need to keep track of accessed sectors (as per the safe light check idea).
#EDIT: Forgot, FAT can be scattered throught the card... grrr...
Well, you prolly know about the internal bad sector list every memory card has.
Considering that we could get away with one or two single bytes for storing a "has been written to" number,
it should be possible to find some space somewhere
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?
That would make the files... not raw. And the length is used here and there, so better just put something inside.
There's the possibility of using the last cluster. It shouldn't be used, and I could try to check if there's a read from there so as to return default data (would make it formatable). I would have to check if it's even reached by a format.
If some areas of the memory card are truly unused, then sure, using them seems perfectly fine to me. But I'm not sure how valid would be a decision that "this area is not used" after few tests.
How many places use the raw memcard file size anyway? and if there's more than one such place, maybe they could all pass through one function which takes these extra bytes (if exist) into account?
The negative of the extra bytes approach is, however, that possibly external tools will not know how to handle it.
So if you look for unused area, please try really hard to make sure it's unused
and also (obviously) make sure the patch is backward compatible with any existing files which don't include the CRC.
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.