I recently decided to try my hand at hacking NES ROMs. I got all the programs I would need, and got to work. Starting off on a high end, I started work on the original Final Fantasy. And since I just started, so far all I've done is text editing. Not too hard, right? Well, my Hex editor decides it doesn't want to find words most of the time. I can search "FIGHTER", and not get any results. But it'll show up when I do a relative search instead of a text search. Sometimes. No matter what, it can't find "Garland", set to ignore capital and lowercase. So did Final Fantasy use some technology that makes Hex editing nearly impossible, or am I just doing something wrong? I've been following this guide. And this video. http://www.youtube.com/watch?v=uzH2sevcCwY&feature=related
I haven't attempted hacking Final Fantasy, but it is possible the text strings are a good amount more complicated than being plain ASCII text. Theoretically you could be dealing with compressed or encrypted text, or text in a font like Shift_JIS, for example. I've been trying to do a Zelda ROM Hack myself, but got stuck trying to figure out how to expand the game a certain way... hm.
Search the RAM when the game is displaying the 'Garland' text. If you can find the word, it's compressed. If not, it's using a different letter storage system, or both. This is purely speculation, however.
Over on Romhacking.net there's a collection of documentation on the data formats used in Final Fantasy, link here. According to the table file included, the text format is rather strange, with some bytes having multi-character meanings, this would explain why a relative search misses some text, as it assumes one byte is one letter of text. From $80, to $C5, the table is single character as expected, however, it also contains values like this: Code (Text): D4=sword D5=hammer D6=knife D7=axe D8=staff D9=nunch It's possible Garland is stored using that second set of values, as some of the entries are as follows: Code (Text): 2F=ar, 3B=nd You should just load the .tbl file in a hex editor that supports it, (which it appears HEXPOSE does), and all the text will appear correctly within the hex editor.
What he meant, was that if the text cannot be located in the ROM, but IS in the RAM at the scene, then it must be compressed within the ROM, and uncompressed into RAM at runtime, making it harder to edit, because that would also involve cracking the compression format.