Comments on: PCSX2 memory card format revisited

By: gothi

gothi — Fri, 30 Mar 2007 07:23:00 +0000

Thank you both for your updates, they’re most welcome

Matt, thanks for the link to the checksum routine, I’ll be looking into that as soon as I get some spare time.

By: Matt

Matt — Thu, 29 Mar 2007 08:00:00 +0000

I was able to figure out the CRC had 3 bytes each for each successive 128-bytes of data, with the first byte being the most likely to change. Because of how consistent they are (And the fact that they’re the same when all values are 0×00, when all values are 0xFF, and when all (word) values are 0x7FFF, it’s obviously just an xor of…something.

Looking at the PCSX2 source shows the value isn’t generated by PCSX2 directly (That is, PS2 code generates it, rather than the memcard itself).

Further googling revealed source to generate the checksum: http://www.geocities.com/SiliconValley/Station/8269/sma02/sma02.html

Not exactly the most obvious algorithm.

By: alkarl

alkarl — Sat, 18 Nov 2006 20:26:00 +0000

facts:
the *.ps2 files are 8650752 bytes long.
with 16384 frames.
each frame is 528 bytes long.

a frame is composed successively of:
512 bytes of data.
12 bytes of checksum.
4 constant NULL bytes.

the checksum's bytes are divided in four 3bytes long cheksum's units.
the result of the checksum of each 128bytes of data is stored in it's corresponding checksum's unit.
the default value of the checksum's units is 77 7F 7F.
the checksum's process ignore the bytes with a 00 value.

uncertainties:
as for the FF & 7f their sequence must perfect through all the 128 bytes to not alter the checksum's unit default value.
the footers have too much dissimilarity to be holding attributes i rather stick with the checksum theory.
the checksum could be a 24bits type & big endian :s