Well, the code won't be of much help to you - I'm just saying "you can write a (de)compressor in just about anything." It would have to use the exact same RLE scheme - and for the record, no two RLE implementations I've seen have been exactly alike. If this were a GBA or DS game, it'd be a different story: those systems have LZ decompression algorithms written into the BIOS, so if a game for either one uses compression at all, it'll probably be the scheme that the system has built-in decompression for.
Anyway. RLE is a simple way of encoding graphics - the general idea is that graphics tend to use long strings of the same bytes in sequence (think large areas of solid color or transparency), so they have a mechanism for indicating a byte to write and how many times to write it. Solving a compression scheme like this is a matter of figuring out how the compression scheme differentiates compression codes from "plaintext" (regular bytes to output without modification), and how exactly the compression codes translate to graphics data. Mind, it could also be some form of the aforementioned LZ compression, which is a little more sophisticated: instead of compression codes indicating a byte to write and how many times to write it, they indicate how far back in the plaintext to look for the next sequence of bytes and how long it is. That is, if there's a lot of data being repeated over and over in the uncompressed graphics (also a likely situation), then the compression scheme is designed to replace the repeated instances with a code indicating to copy what comes next from somewhere earlier.
The important thing to keep in mind is that compression is just a code, and it can be cracked - it can be even easier than a newspaper cryptogram as long as you understand what you're looking at, because it gives you a partial solution right off the bat (as you've noticed already, there's easily-visible "plaintext" among the encoded data). A good way to start is, naturally, to compare the compressed and uncompressed data - especially the visible plaintext.
(Oh, and for the record, "plaintext" isn't necessarily text! It's cryptography jargon referring to unencoded data.)