A File System Entry in a psu is described as follows:
32 byte header (contains count of files in psu/file size, creation date, mod date etc.)
– 32 byte x [0x0h]
– 448 bytes reserved for entry name (unused bytes are 0x0h)
– file content OR 0 bytes if directory entry
– filler bytes to make file content block multiple of 1024 (most often 0xFF, 0xCD or 0x00)
The first file system entry in any valid psu file is the name of the directory the remaining entries are to be located in. This entry contains a count of the # of files expected to be contained within its directory.
Note the . and .. file system entry should always exist in the psu file.
The overall layout of the psu file is:
[DIR ENTRY (file count = X)]
[. FILE ENTRY]
[.. FILE ENTRY]
[FILE ENTRY 3]
….
[FILE ENTRY #X]
OK, here’s a byte-by-byte run-down of a file entry
32 byte header
– byte 0 and byte 1 represent some sort of ID.
-0x2784 for DIR ENTRY, . ENTRY, and .. ENTRY (required entries)
-0x9784 for any other entries
-0x27A0 for ps2 system save file (i.e BEDATA-SYSTEM save for Euro PS2)
– byte 3 and byte 4 always appear to be 0x00
– byte 5, byte 6, byte 7, and byte 8 are the # of files in the directory for DIR ENTRIES and the file size for FILE ENTRIES(byte 5 is MSByte, byte8 is LSByte)
– byte 9 through to byte 16 represents the creation date of the entry
– byte9 = seconds, byte10=minutes, byte11=hours, byte12=days,byte13 = months, byte14 = year(LSByte), byte15=year(MSByte)
-The 16th and 17th byte of the header is the start sector address to write the file content to. It appears that the Memory Card might be formatted as a FAT12 file system or at least something inspired by FAT12
– byte18 through to byte24 are UNKNOWN (I suspect part of it may be a checksum, if anyone has any suggestions, let me know 😉
– byte25 to byte31 represents the last modified date(same format as byte5-byte8)
32 bytes of 0x00h
Not much to explain here. I’ve never seen any of these bytes containing anything but all zeros.
448 bytes reserved for entry name
– entry name right filled with 0x00’s.
File content
Direct binary dump of file described in file name entry above. For DIR ENTRY, . entry, and .. entry, there is obviously no content. The number of bytes in this block should match the number described in the header block for this entry.
filler bytes to make file content block multiple of 1024
additional bytes at end of file content block to ensure that file content block is a multiple of 1024. The filler bytes are quite often 0x00, 0xCD or 0xFFs, but in some cases, they just appear to be garbage bytes. The seem to be irrelevant to the format, as long as the correct number of additional bytes exist.
i.e Filler Bytes required = 1024 – (File Size % 1024)
