Okay. "KLZ" isn't good news; it sounds like the files you're looking into might be LZ-compressed.
...well. It is good news in that 1. it tells us the kind of compression you'll need to crack and 2. LZ is dead simple. The Cliff's Notes version is that it outputs "plaintext" bytes until it hits a compression code, which is a length-width pair indicating how far back in the output buffer to look for the next bit and how many bytes to copy from that point. How those compression codes are flagged varies, but I think I might be able to hand you a breakthrough.
You see how there are seven "garbage" bytes before the recognizable "TIM2" there? I know this is my DS hacking experience talking, but it seems strange that they'd align the data on an odd number. I think those first six bytes have to do with the compression properties (the uncompressed size is probably in there somewhere), and the seventh is - drumroll! - a compression code indicator. DS's LZ implementation groups codes (both plaintext and compression) into groups of eight, prefixed by a single byte containing indicator flags. If the flag is clear (0), the corresponding code in the sequence is plaintext; if it's set (1), then it's a compression code. I know this is a PSP game we're talking about, but that doesn't mean it might not use a similar implementation.
To use that snippet as an example, the first indicator is "00", so the next eight bytes are meant to be output as plaintext (yay!). Then we hit "81" - which, in binary, is 10000001 (that's a lot of dalmatians!). We don't treat this as a literal number - it just tells the decompressor when it should try to read a compression code and when it should output plaintext. What it tells the compressor is that the next two bytes (again, assuming this works like the DS's built-in LZ implementation) should be read as a compression code, the six bytes after it are plaintext, and the two bytes after them are another compression code (seeing the pattern?). The next byte after that is "20", or 00100000, which means that (assuming this is little-endian) the next five bytes are plaintext, followed by a two-byte compression code, followed by two more plaintext bytes (otherwise, the order is reversed - two plaintext, a compression code, then five plaintext).
I don't know if the currently-available PSP emulators have enough debugging functionality to be of much help, but if you could actually find the uncompressed file in memory - or even just the first part of it - it'd be tremendously useful. Without the uncompressed file, figuring out the specifics of the game's LZ implementation is a little like fumbling around in the dark (in a haunted school full of murderous ghosts :3).