dolphin-emu
Handle dumps from "MaxDrive" cards
The Datel "MaxDrive"/"MaxDrivePro" cards are exactly 8,192 * 1,000 bytes, rather than the expected 8,192 * 1,024 bytes. This produces a cryptic error about an unsupported size of 0x7D0000. Adding support for the slightly-wrong size, and allowing that precise mismatch with the header size (still reported as 0x40 Mb) allows reading files off these. Which allows transferring files from gamecube save cards to a desktop.
Additional note: The card does not work reliably as a USB drive under Linux unless you have used the MaxDrive software to "prepare" the drive for use with the PC. I don't know what that does, but the failure symptom looks exactly like a failing drive, which is certainly very concerning given the age of the hardware. But actually it's just something weird about their internal chipset producing bogus data when queried. This might be worth documenting somewhere other than the source.
Signed-off-by: Seebs [email protected]
Okay, updated to drop the excess parens and use a more accurate symbolic name, which I think makes the intent clearer. Probably.
where does "actual size of the dump" really come from? How were those dumps made? What happens if you try to write the expected full size of data to the card and read-back?
The "actual size" is what the drive probes as when plugged in on USB; exactly 8,192,000 bytes, or 16,000 512-byte blocks. I didn't try to write to the card, because there's clearly some kind of deep magic going on. The same card will 100% reliably fail to read sectors under Linux if not "prepared" using their gamecube software, then read perfectly well once prepared. I'm assuming they have some fancy controller logic in there that is using part of the flash for a drive map or something weird.
Without this patch, the size of a dump of the full card (dd if=/dev/sdb of=MemoryCardA.USA.raw) isn't recognized. Appending the missing 384 512-byte blocks produces a card which fails checksums, because the checksum for the card was computed for the original card size.
With the patch, the dump works perfectly, no additional fiddling required.
I'm really not familiar with this code anymore, but I'd be willing to bet it's not good (will crash during some operation) to have a mismatch between the size dolphin thinks the card is, and the size kept in the header. I guess the real problem is that dolphin needs to be compatible with Datel's crap PC software (otherwise we could just expand the file and/or fix the size in the header, and update checksums)... As long as you think any edge cases introduced by this mismatch are accounted for, I guess we have to accept this :(
I spot-checked the code, and so far as I can tell, the actual-size-read is consistently used for everything except the header checks. It might fail strangely with copying to the card. I can try to make time to do some more experimenting with it, but at least for reading from the cards, it seems to just work; everything uses the recorded size in bytes, rather than the theoretical Mb size from the header.