Okay, allow me to weigh in on the issue.
Although it has been transliterated as Kantam or Cuntam (lol), a Google search shows that there are clearly companies with Quantum in their name which use カンタム as the Japanese version.
Another point in Filler's favour: the Xbox game Quantum Redshift is known in Japan as カンタム レッドシフト 超高速空間 バトルレース. So, again, カンタム equals Quantum.
To be honest I don't really care either way.
To avoid any arguments about this rather trivial point, I'm happy to make two patches, one with Quantum and one with Kantam.
Back to the hacking. The compression was doing more than I expected, but I'll explain here for the benefit of any interested parties - I always think it's good to talk openly about these things for the sake of getting information on record, for those who are learning to hack or who encounter similar issues.
Each 8x8 tile begins with 4 bytes explaining how the 8 pairs will be. A 3 means it's a new value, a 0 means it's the same as the previous value. This is done in two sets, so the first two bytes detail the first four byte pairs, the second two bytes detail the other four pairs. It's assumed that we're starting at zero, so if the first byte pair is zero, you can say it's a repeat of the previous one.
Let's use an example instead of confusing you further.
33 33 33 33
This means that every byte pair that is to follow is unique, so it's followed by 8 byte pairs (16 bytes), but remember that they go through that stupid XOR routine that I can't get to do in OpenOffice Calc.
30 33 33 03
This means the first byte pair is 00 00, because zero means it's the same as the previous. Oh, did I mention it's little-endian? Yeah, it is. Note that if in this example, the fourth byte pair is 7E 7E, and so is the fifth, it is still 3 because it only does four at a time, so for the fifth, we're back to zero again. And byte pair 8 is the same as byte pair 7, because little-endian. So now you only need 6 byte pairs because we eliminate the two repeaters.
Confused yet? Well, it took me a few hours to piece all this together, but now I've got it sussed. I just have to look at the 8 bytes I need, decide which ones repeat, then put the 4-byte header and the necessary byte pairs (after going through the XOR process with an online calculator since I don't think Windows' calculator does it) into the ROM. I've done a few letters successfully, but it would be good to automate the process somehow.
All this makes me think... WHY?! They don't even need a pair! Each pair is identical! Look, if each pair is unique, you have a 4-byte header plus 16 bytes for the tile. That's 20 bytes which could be done in just 8 with no real compression whatsoever!! Honestly, why do they do this to me... especially when there's two perfectly good kana sets sitting in the ROM. Ugh...
Anyway, I continue.