I have not, no. Only the loading screen was able to be modified, which coincidentally is the game's sole isolated TIM...
Then, Klarth is probably right. You should first check whether the game verifies some kind of checksum on the files of the archive. This should be relatively easy. Pick an emulator with a good debugger (either no$psx or pcsx1.5 with debugger). Look in RAM where your TIM file is loaded, set a read breakpoint on that address, and try to see at which point the game decides to call the intro routine.
April 12, 2020, 06:41:06 am - (Auto Merged - Double Posts are not allowed before 7 days.)
By the way, I had a look at the game, and although I can find the title screen TIM in RAM, there is no trace of it in the disk images. How are you actually replacing this image? I fear there is some compression going on, and you are just replacing the compressed version of this image or even some other image, and that's why the game complains. If no compression were involved, I would at least see the title screen in the disk image with TimViewer.
Here is the TIM file I get by scanning the RAM while in the title screen. There is also a gray scale png version of it. However, there is no trace of this TIM in the disk image.https://www.dropbox.com/s/pdtylr4d1onzzf3/SLPS_00817.000_000001_04b_01c.zip?dl=1
The image you are modifying is something else. It is not the TIM the game uses for the title screen.
April 12, 2020, 08:33:30 am - (Auto Merged - Double Posts are not allowed before 7 days.)
I can confirm the game uses an LZSS compression for its files.
Compressed files all start with a sequence of 3 magic bytes "RUX". Your title screen compressed TIM file can be found in OP1.PAK at address 0xBB26.
This is the structure of RUX files, you might need some background on how LZSS works, I did not have time to polish these notes.
The main routine decompressing RUX files can be found in RAM at address 0x8003E9C4
uint8_t magic //RUX;
uint8_t is_big_endian; //if 0, the next int32_t is read in little endian, otherwise big endian
int32_t decompressed_size; //if it is negative, the game gives up decompressing.
Structure of compressed stream:
XX XX .... XX XX ...
XX XX are the decompression flags typical from LZSS decompressions. XX XX is always read as a uint16_t in little endian, independently from the is_big_endian flag. After it is read, each bit, from the most significant to the least significat determines whether next there is a plaintext byte to be copied in the output, or a sequence of bytes specifying how to decompress.
If the bit is 0, juts copy the next byte, if it is 1, then read the next uint16_t in little endian. Let this value be the two bytes AB CD. If A is not zero, then A+1 denotes how many bytes to recover from the current output stream, and BCD+1 is the jump back in the current output stream.
If A is zero, then use ABCD as jump, read the next byte, sum 0x11 to it, and the result is the amount of bytes to recover.
Keep going until all flags in XX XX are over or the decompressed size is reached.
Then, move to the next flags XX XX, and keep going until the decompressed size is reached.
Regarding PAK files, they are quite easy. THey start with a sequence of uint32_t's, each being the address of a file inside the PAK (the addresses are stored in little endian).
Here is a quick decompressor for RUX files (it's a command line tool). I tried it over the RUX with the title screen, and I get a 1:1 match with the original decompressed TIM found in RAM, and when recompressing it back, I get exactly the same RUX file, so I believe it compresses in the same way as the devs tools.https://www.dropbox.com/s/95fpe8txmrlipki/CommunityPOMDecompressor.zip?dl=1
As you can see, the decompressor works as intended. I made a slight modification to the title screen using usenti and TimView2:
"Fall in Cafe" is the new dev group for the game XD.