I've got this over at Xentax too, but I figured I'd port it over here since it deals with how the PSX handles compressed data. Figuring this out will be a useful exercise for me, and PSX enthusiasts here may also be interested (or already know what's going on).
While the vast majority of Front Mission 2's graphics are uncompressed on the game CD, it appears that the character portraits are compressed in a manner functionally similar to RLE compression, i.e., runs of identical bytes or repeating byte patterns are collapsed into just a few. However, it doesn't seem to be simple RLE and I can't find any sort of identifying marker at the beginning of the compressed graphics data that would indicate what type of compression is being used. I'm interested in the opinions and observations of this forum's veteran game resource investigators.
The following pics are three comparisons between the compressed data on the game CD (top) and uncompressed form as it appears in VRAM (bottom). Green bytes in the upper section of the examples are the compressed form of their expanded counterparts in the lower section of each example. Red bytes are identical in both the data on the game CD and in VRAM, meaning they are not compressed on the game CD.
This comparison is particularly interesting. Notice the compressed code 41 E9 04 from the game CD. This corresponds to four E9 bytes of uncompressed data, as if the compressed code specified that there would be four E9 bytes in a row.
Ah, you can see another instance of what appears to be near-straight RLE compression here. There's a compressed run that reads 40 08 03 in the upper portion of this pic, and it corresponds to an expanded run of 08 08 08 in the lower portion.
Another thing I've noticed is that the first byte in many runs of compressed data may have something to do with the uncompressed length of that run. For example, if a compressed run begins with the byte 9D, the uncompressed run has 31 bytes. Here's a list of equivalencies that appear in these examples:
9A: uncompressed run has 28 bytes
9B: uncompressed run has 29 bytes
9C: uncompressed run has 30 bytes
9D: " " 31 bytes.
A0: " " 34 bytes.
But this pattern doesn't hold all the time. I observe one compressed run beginning with 82 that has an uncompressed length of 10 bytes, and a compressed run beginning with C2 that has an uncompressed length of 30 bytes. Is it possible that the compression scheme being used here involves a mixture of compression techniques?