Shadow Man: 2econd Coming: Shadow Man: 2econd Comming loading fix

This patch fixes bug in SOUNDREL.IRX module which causes data corruption when new data is loaded faster than unpacked. This happens more often on emulators but also can happen on real hardware under some circumstances, for more info check info.txt in the archive.

Patch is made for all existing releases of the game, pick the one needed for your particular version and apply to the CD image through any available PPF patching tool, PPF-O-Matic is a good choice.

### What is this? ###

This is the patch for game Shadow Man: 2econd Coming on PS2, it fixes bug in
SOUNDREL.IRX that can cause data corruption during loading. On emulators
this bug is more pronounced because they don't take into account access
delays introduced by laser mechanism and in some circumstances it shows
itself on real hardware. And that is how I experienced this game back in the
day, my own PS2 read data from CD faster than it was decompressed, so in
some levels I had broken textures.

For patching use any available PPF patching tool, PPF-O-Matic is a good
choice.

ISOs must have these checksums:

USA

Serial number: SLUS_204.13
CRC32: dd673b1d
MD5: 17e1f9e7624a0c099a28c0c3ceb644fb
SHA-1: 419697e9a655517e0b2589a28de8ca6862dca66f

Europe

Serial number: SLES_504.46
CRC32: fad31937
MD5: 53a561de1c635da4d96a041b6aa2141a
SHA-1: cb64690f82146ee3839a9b53dded5ae3edbf43ec

Germany

Serial number: SLES_506.08
CRC32: 8acb782f
MD5: 69f76731d730d4f19ded307cc6fe4c36
SHA-1: 13624d5101f10d172c6a907113b1b9d0feaf0f19

### Explanation of the bug in the IRX module ###

Loading function has two modes for loading data:
1. Double buffered mode for reading directly from CD by setting sector
address and number of sectors to read.
2. Single buffered mode for reading through the use of file system access,
its purpose is loading from host but it can access files on CD if forced.

During initialization stage IRX module statically allocates two buffers for
compressed data, they're both equal to 0x8000 bytes and placed next to each
other. But data chunks on CD are very rarely aligned to boundary of 0x800
bytes(single sector size), so if chunk has size between 0x7802 and 0x8000
bytes and it's located at the risky offset then it can span across bigger
number of sectors than can fit into one buffer of 0x8000 bytes.

Here is visual representation of how this happens:
A B
------------------------------------- ------------------------
| ! | | | ! |
| 1 ! | 2 | 3 ~/~ 16 | 17 ! |
| ! | | | ! |
------------------------------------- ------------------------

On this picture you can see boundaries of chunk 'A-B' marked by ! symbol and
the rest is the boundaries of sectors. We can see here that if only data was
properly aligned, it would nicely fit into 16 sectors, but instead it spans
across 17 of them and IRX module actually reads data from CD by the number
of sectors which contain the whole chunk, it can be unpacked properly only
when it's fully loaded. So when such chunk arrives into buffer to be
processed it can either corrupt currently processed data in the neighbor
buffer or will be corrupted itself by the next chunk.

And while the code which decides how many sectors to load is really working
as intended the actual bug is in the buffers allocation here:

.text:000016B4 jal sub_D10
.text:000016B8 li $a0, 0x8000 # 1st load buffer size
.text:000016BC li $a0, 0x8000 # 2nd load buffer size

These values must be set to 0x8800, extra 0x1000 bytes isn't such a big deal
and in my tests game didn't had issues with such approach. It is also
possible to force IRX module to always use file system access instead of
direct CD access but it will potentially decrease loading speed, so I chose
first method.

Raziel I.C.H.I. Znot
17.12.2019


USA

Serial number: SLUS_204.13
CRC32: dd673b1d
MD5: 17e1f9e7624a0c099a28c0c3ceb644fb
SHA-1: 419697e9a655517e0b2589a28de8ca6862dca66f

Europe

Serial number: SLES_504.46
CRC32: fad31937
MD5: 53a561de1c635da4d96a041b6aa2141a
SHA-1: cb64690f82146ee3839a9b53dded5ae3edbf43ec

Germany

Serial number: SLES_506.08
CRC32: 8acb782f
MD5: 69f76731d730d4f19ded307cc6fe4c36
SHA-1: 13624d5101f10d172c6a907113b1b9d0feaf0f19