Dolphin, the GameCube and Wii emulator - Forums

So, I have a couple of old "MaxDrive" gamecube cards, which work fine in my gamecube. I can read them on my Linux box, although I have to use a USB1 hub to do it (they get weird errors at full speed).

Problem: They're exactly 16,000 512-byte blocks, 8,192,000 bytes. If I ask Dolphin to use the resulting image as a save device, it says it's not valid, because it's 0x7D0000 bytes. It is, indeed, exactly 384 blocks smaller than a 16384-block file.

Just a quick check of the structure of the file makes it look like they have at least similar header structures, I don't have access to a Wii with gamecube ports, or a gamecube with any homebrew type support, so I can't easily do anything with the other memory cards I have floating around. But it looks like these are at least *similar* to the data found in the Dolphin-generated memory card file I have lying around. Possibly not identical; the Dolphin file seems to have its first save data start at 0x2000, the MaxDrive's save data seems to start at 0x80. Appending zeroes produces "memory card file size does not match header size". Messing with this more, it looks like I'm running into a checksum problem; a naive attempt to manually fix the checksums failed.

The original files read from the device don't have a "size in mbits" in the location that the RAW file apparently does. They just have zeroes at 0x22.

So it looks as though, if I could simply ignore the header and file size checks, and have the software just trust that the file size is fine and ignore the lack of a specified size in mbits, the actual contents would be fine. Probably. But I can't see an easy switch to flip for "trust me, I know what I'm doing". The directory checksums mean that I can't just, say, embed the data from this save image (except for its bogus header) right after the header in an existing file of a different size. I'm gonna see if I can just turn off the checks, and special case "size of zero means trust the file size and don't compare size in mbits to file size" or something, but... I have no clue whether that's likely to work.

I think I'm confused by the memory card code. Oh! I get it. "MemCard1019Mb" is not "size of a 1019-Mb memcard" (which would be a bit under 128MB), it's "size in megabits of a 1019-block memcard". Okay, so, I got it partially-working, but all the checksums came out wrong, and I now somewhat suspect that the cards are unreliable. I can sometimes read one or the other of them. Sometimes they fail, but when they fail, they have very persistent behaviors for a given card with a given set of data; like, it can't read at all, or it reads everything, or it reads exactly 8KB or 12KB. Put it in gamecube, mess with files or something, it comes out different.

It looks like Datel may have shipped them with bogus headers with no card size listed in the initial header; I reformatted one on the gamecube and that one now seems to have a correct header. Unfortunately, only 12KB of it are responsive right now.

The one 8MB dump I got now opens at all, with the size hackery and also completely disregarding checksums, but says it has 127 free directory entries and >65k free blocks, which suggests that it's just failing entirely to read things. Unfortunately, I'm not familiar enough with the format or code to decipher that without more time to look at it, and I'd want higher confidence that the image I have is even correct.

They appear to work better after being left alone (?!?) so I'm leaving it overnight.

My guess is that the size hackery of allowing a 995-block card of exactly 8,192,000 bytes would probably be fine if the card image were correct, but it's just a guess.

So, one of the card is just fried -- the gamecube can't use it either, apparently? I'm not sure why, but I think at this point I'll take it apart and look for obvious exploded parts or something.

But I went into the MaxDrive utility program on the gamecube, and asked it to Prepare The Drive for use with a PC, and with that, my patches work and I can access saves on it. Woo!