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:


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...

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.

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

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.

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.

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.