[Magil]

I took a  look at Culdcept's decompressing function and found it was too troublesome for me to write a recompressing tool (even if I can, perhaps I need to try hard to keep the recompressed data  smaller than original data). So I had an idea in mind that maybe I could let the game read the uncompressed data from CD instead (so I can append the data behind the CD, for example).

But I don't know how to do that.


The decompressing function is like this:

Code: [Select]

decompress(input_address, output_address, output_length)
Input address is stored in a1, refers to a memory address where the unheadered compressed data begins.
Output address is stored in a2, refers to a memory address where the decompressed data will be stored.
Output length is stored in a3, should be the length of the uncompressed data.

And here's my idea:

Store the sector/LBA info at the beginning of the hacked compressed data and flag it with a special byte. Let the hacked function read one byte, if it is zero (for example), read ahead to fetch the sector info and read from CD.

I've read some document but haven't figured out how to do actual CD reading. All I know is the memory address is stored at 1f8010b0, hmm...

[Gemini]

Why don't you just append the compressed & expanded data instead? Bypassing a compression is not only a bad habit, but it also has severe consequences on loadings (i.e. the game will take almost twice the time to load anything not compressed).

[Magil]

Hmm, I don't understand. What do you mean by compressed & expanded data?

The compressed data is not that long at all (some text, for example).
So I mentioned a flag byte, so the game only re-read those with the special flag but run normal decompressing routines if the flag is not present.
  And it is nothing bad to just learn how to read data via DMA, just in case I might need it in the long run.

[Gemini]

You don't need to know DMA registers or how to use them anyway, since all the CD functions are stored in the exe as included libraries. Check the official SDK instead (it floats around the net, very easy to find nowadays).

Hmm, I don't understand. What do you mean by compressed & expanded data?

Compressed data that grew bigger in size and that wouldn't fit in the original location. Example: a new script or a non-optimized compressed chunk.

[Magil]

Check the official SDK instead (it floats around the net, very easy to find nowadays).

Hmm, I will try.
Thank you.


Yeah, finally found the cd reading function after 10+ hours of tracing and testing.
The function itself is neat. It has 4 parameters, a0: the sector number of the package file, a1: buffer address, a2: offset in the package file, a3: length

[Gemini]

Why tracing? Not only that's not the correct way to hack consoles such as the PlayStation, but there are also way better alternatives, like IDA's flirt signatures containing pretty much all the Psy-Q functions or this special version of PCSX with a debugger that can monitor CD access. Seriously, nobody should use tracing anymore for this kind of stuff.

[Magil]

Yeah, I'm kinda slow to get things done.

I used IDA (though I was new to it). But the game also created its own CD reading function which used DsGetSector and its own sector seeking function. So though I found the function that used DsGetSector pretty soon, I had to find its callers and figure out the parameters.

Hehe, guess I will be more skillful next time.

[Gemini]

You can still do that with all the values stored in ra and Program Counter breakpoints. :p Backtracing is usually very easy on the PlayStation.

[Magil]

You can still do that with all the values stored in ra and Program Counter breakpoints.

Yeah, I figured that out though it was too late. 

BTW, actually, direct CD-reading was faster than decompressing the data on an emulator. The data block was 85kb in length after processed and it took a lot of time to be decompressed. That is not really an excuse though, I'm still researching the decompression routines hoping I can eventually understand it.

[Gemini]

If the decompression is really that slow:
1) The decompression algorithm is so horrid it acts slower than it should;
2) The compression codec doesn't really help the stream to get smaller enough to quicken the loading+decompression process.

Still, usually compression reduces CD reading by A LOT. I've implemented a simple LZSS on Soul Hackers and now it takes half the time to load, so there's something not sitting right in your case. :S

[Magil]

Hmm, I converted the asm code into ugly c code, so now I can decompress things without copying them out of RAM dump.

The decompressing process is strange.

1. calculate total decompressed buffer length

2. read from the compressed buffer, set up large look-up table(s).

3. read from the compressed buffer, jump here and there in the look-up table(s) to fetch something, write the results to the decompressed  buffer.
  In step 3, it sometimes copies bytes already decoded, so I wonder whether it is some kind of lz compression.

4. check the length from step 1, if it is not done, then repeat step 2 and 3.

[Magil]

Hmm, I took a look at those help text in game just to find they have to be decoded using mdec after being decompressed.
http://img232.imageshack.us/img232/6369/testmq.png

So is there any tool that can decode/encode individual such pictures?