+- Dolphin, the GameCube and Wii emulator - Forums (https://forums.dolphin-emu.org)
+-- Forum: Dolphin Emulator Discussion and Support (https://forums.dolphin-emu.org/Forum-dolphin-emulator-discussion-and-support)
+--- Forum: Support (https://forums.dolphin-emu.org/Forum-support)
+--- Thread: Built in decompression algorithm (/Thread-built-in-decompression-algorithm)
Built in decompression algorithm - Bring Stabity - 11-20-2016
Hello,
I'm working on a project to translate SRW GC, along with Dashman who's also on here. https://forums.dolphin-emu.org/Thread-solved-recompiling-dolphin-to-set-memory-read-breakpoint
We've made some great progress so far. VWF has been implemented, which is the biggest thing that I've been responsible for. However, the font itself has to be hacked into memory. Currently, we have a small bit of free space where we've inserted the font, but it starts overwriting important data if we put too much in. As such, we'd rather replace the original font with our new font on the disc, but that requires us to understand the compression/decompression algorithm.
We have the original file from the iso, and we have the decompressed file pulled from memory. If I try launching Dolphin normally, the data is immediately in memory. If I don't skip BIOS and use the IPL, the moment that the contents appear in memory is after the processor exits from a loop where it's querying 0x8145D998 constantly. Once that value is non-zero, the data is where it should be. I'm pretty confident that this is some combination of DMA and using the operating system's decompression algorithm. I was wondering if that decompression routine is documented somewhere?
Thanks
RE: Built in decompression algorithm - gamemasterplc - 11-20-2016
The algorithm is a Yay0 if it is using the BIOS fonts. Try setting a Write breakpoint on the data and restart the game and start running again when the breakpoint is hit until you find at least 1 byte of the expected data at the memory address to find the routine that decompresses the font. You might be able to update chunk pointers in the file and create a bypass decompression hack to insert the font in the game. Your custom image must be in the original texture format and resolution for it to work properly from experience.
RE: Built in decompression algorithm - Bring Stabity - 11-21-2016
It's not using the BIOS fonts (unless I'm misunderstanding your point). There's a file, font.pak on the ISO that contains the compressed fonts. The decompression and loading into RAM is done through a system call rather than a decompression routine in the game code.
The .pak file is structured like this:
address size
0x0000 0x0004 little endian representation of 0x1 (not sure of meaning, possibly that there's only one file)
0x0004 0x0004 little endian representation of size of filename (0x9 in this instance)
0x0008 0x0009 filename (font.bin_ in this case)
0x0011 0x0004 little endian representation of size of compressed data (0x4DE31 in this instance)
0x0015 0x0004 little endian representation of size of decompressed data (0x9BACC in this instance)
0x0019 0x4DE31 the payload. The first three bytes are 00. That may be part of the data, or it may be padding to get the compressed data PPC word aligned.
There was no yaz or yay magic word in the header, but I'll work through the first few bits of data and see if it matches.