Memory Card Blues
Please excuse this large essay of a first post. About a month ago, I sat down in front of my 'Cube and started playing. Suddenly, I got an error message - This Memory Card Needs Formatting. Well, this being my 128mb card (with my entire save game collection built up over three years on it), I had no intention of doing that, I simply rebooted the console. In most cases, this would have fixed the problem, but in this one the card still wouldn't read. Having already picked up PSO and a broadband adaptor, I hit the web in search of a memory card importer/exporter and found this site. Gcars loaded up easily enough, and I used it to first rip a 56 block card, a few save files, and then my "corrupted" card. Surprisingly the upload continued well past the 128mbyte mark, at 160mb I got suspicious and killed the program. After comparing the save game extracts to the full card image they were taken from, I wrote a small piece of code to extract similar "save slots" from the corrupted card, and Gcars let me put these onto another of my smaller cards. Although the saves listed up in the memory card manager, games refused to load them, saying they were corrupt. A closer look at the banners showed strange stripes in the images, another go with the hex editer revealed blocks of "empty" bytes in the extracted data at steady intevals. I ripped the card again, this time waiting until the program was finished. The resulting image was 180mbytes, but this time the image was wrecked - it was all just garbage data. I did another rip to be sure (it came out the same), and then a few more "partial" rips. Only the complete ones were totally garbled, but all the other ones still had the "null" blocks. At that point I looked up some technical docs, and read up on the format of the cards. About now I realised that my card was 128mbits, not bytes, and found that Gcars was in fact repeating the same data over and over again into the file. I then ran an extract for 16mbytes of data, but it still had the "null" blocks. Each of these "null" blocks contained a single byte that incremented in value with each block. The first one would be x00, then x01, and so forth. The counter didn't reset when Gcars started repeating the actual card data, it just kept going up. Eventually the entire block was filled up with the incrementing values, replacing the 0 value bytes. Each of the semi-readible exports I did had an extra 124 bytes of data (all set to x00) prefixed to the start of them, which I had to skip over before reading the actual card data. In addition, the card header was written another 38 bytes (again 0's) past where I would have expected it to be (shortening the distance between itself and the directory structure of the card). I guess this is why the program was unable to work out how big the card really was. The first "null block" appeared at offset x230, and was 112 bytes. Eventually the blocks fell to a size of 76 bytes. The "counter" byte I mentioned before was always the second byte of each block, and didn't always increment, but would sometimes seem to change randomly. The distance between the start of each null block was an exact 512 bytes, and this remained constant throughout each export I did. Anyway, here's what I'm wondering - Could any of you guys try ripping a card the same size as mine (2043 blocks), and see if the same "holes" appear in the data? If so, that would indicate that Gcars simply isn't reading the card correctly, as if 1/5 of the data really IS missing then I'll never be able to restore it! With any luck, some of what I've listed here might help with adding large card support to Gcars, but mostly I just want my saves back!
Please excuse this large essay of a first post. About a month ago, I sat down in front of my 'Cube and started playing. Suddenly, I got an error message - This Memory Card Needs Formatting. Well, this being my 128mb card (with my entire save game collection built up over three years on it), I had no intention of doing that, I simply rebooted the console. In most cases, this would have fixed the problem, but in this one the card still wouldn't read. Having already picked up PSO and a broadband adaptor, I hit the web in search of a memory card importer/exporter and found this site. Gcars loaded up easily enough, and I used it to first rip a 56 block card, a few save files, and then my "corrupted" card. Surprisingly the upload continued well past the 128mbyte mark, at 160mb I got suspicious and killed the program. After comparing the save game extracts to the full card image they were taken from, I wrote a small piece of code to extract similar "save slots" from the corrupted card, and Gcars let me put these onto another of my smaller cards. Although the saves listed up in the memory card manager, games refused to load them, saying they were corrupt. A closer look at the banners showed strange stripes in the images, another go with the hex editer revealed blocks of "empty" bytes in the extracted data at steady intevals. I ripped the card again, this time waiting until the program was finished. The resulting image was 180mbytes, but this time the image was wrecked - it was all just garbage data. I did another rip to be sure (it came out the same), and then a few more "partial" rips. Only the complete ones were totally garbled, but all the other ones still had the "null" blocks. At that point I looked up some technical docs, and read up on the format of the cards. About now I realised that my card was 128mbits, not bytes, and found that Gcars was in fact repeating the same data over and over again into the file. I then ran an extract for 16mbytes of data, but it still had the "null" blocks. Each of these "null" blocks contained a single byte that incremented in value with each block. The first one would be x00, then x01, and so forth. The counter didn't reset when Gcars started repeating the actual card data, it just kept going up. Eventually the entire block was filled up with the incrementing values, replacing the 0 value bytes. Each of the semi-readible exports I did had an extra 124 bytes of data (all set to x00) prefixed to the start of them, which I had to skip over before reading the actual card data. In addition, the card header was written another 38 bytes (again 0's) past where I would have expected it to be (shortening the distance between itself and the directory structure of the card). I guess this is why the program was unable to work out how big the card really was. The first "null block" appeared at offset x230, and was 112 bytes. Eventually the blocks fell to a size of 76 bytes. The "counter" byte I mentioned before was always the second byte of each block, and didn't always increment, but would sometimes seem to change randomly. The distance between the start of each null block was an exact 512 bytes, and this remained constant throughout each export I did. Anyway, here's what I'm wondering - Could any of you guys try ripping a card the same size as mine (2043 blocks), and see if the same "holes" appear in the data? If so, that would indicate that Gcars simply isn't reading the card correctly, as if 1/5 of the data really IS missing then I'll never be able to restore it! With any luck, some of what I've listed here might help with adding large card support to Gcars, but mostly I just want my saves back!