Speaking with some uncertainty..
1. Even if you find-replace all found in the image, some of them may technically be split between sectors (there is cd format stuff entered for each sector and this can break the sequence)
2. If you happened to only check by loading the save state, it could very well load that memory area from the save state and never load it from the modified image.
3. In general the all-purpose tool is a debugger emulator.. if you don't mind reading asm a bit. The code of course knows what it does with any numbers you have found.
1. That's unfortunate, and I don't know what I'd do if that were the case.
2. The save state is prior to the area with the dialogue I'm looking at. I've modified the text within existing space constraints successfully, so I know that the changes take in the save state.
3. I've looked through the disassembler in psxfin, but asm means nothing to me. I found a list of the codes, but I still don't really know what they're doing. I think I've figured out that 0xXXXX0009 denotes an instruction to jump to 0xXXXX. And I think that 0xXXXXXX0F is jump and link to an offset >0x04000000 or something near that, and 0xXXXXXX0E is JAL to one less than that. So by looking at these jump instructions, could I figure out the base address?
So for example, at 0x001BDA34, I have 0x7BFC0009. This is in little-endian, so the instruction is 0x0900FC7B, and in assembly that's jump to 0x0403F1EC. Is their some way to use this info to get the base address?
Also, I'm not sure how it goes from pointer to address. There are a couple jump commands above this one. One is 0x0900FCAC, or jump to 0x0403F2B0. But these don't have the same additive relationship. FCAC - FC7B = 31, while F2B0 - F1EC = C4. So is there some other method being used to get from a pointer to an address?
I was thinking one of these sets of jump commands were the right ones, because there are two closely grouped sets of 3 just a short ways above the text, but they're not quite in ascending or descending order, and none of the differences match up with the offset difference between the lines of text themselves. But if it's not simply adding or subtracting, maybe they still are?
EDIT: Scratch the second half of bullet 3, the 0x0090 just means the first two bytes of the target are 0x0403. I have no idea how it know it's a jump command. That still leaves the inconsistent translation issue.
EDIT 2: If it's helpful to figure out the sort of operation it's doing, I found this. It clearly has some sort of byte-by-byte pattern, but I'm not really sure what it means:
0f0a003c: jal 0x042800f0
0f0a003d: jal 0x042800f4
0f07003e: jal 0x041c00f8
0f07003f: jal 0x041c00fc
0f070040: jal 0x041c0100
0f000000: jal 0x04000000
0f0e0042: jal 0x04380108
0f110043: jal 0x0444010c
Seems like an increment of one in the second byte on the left is an increment of 4 in the second byte on the right. Same sort of situation for the last byte. Also, both 0x00 and 0x40 equate to 0x00, and looking at the first entries in the list, 0x30 should equate to 0xc0. I think both the second and last byte follow this pattern. The second to last byte is 0x00 if the counting for the last byte started at 0x00, and 0x01 if it started at 0x40. Presumably it would be 0x02 if the counting on the last byte started at 0x80. I also found later that for the first byte, 0x0c equates to 0x00, so the first byte is a 1:1 increment starting at 0c I think.
Is this some kind of compression algorithm? And if so, does anyone recognize it/know a good way to go between the compressed and decompressed bytes? And also which one is compressed? And will any of this help me find those pointers?
EDIT 3: Looking at more examples, the pattern actually seems to be more complicated than this, and follow different rules in other situations, where, say, the first byte on the right column is 0x00, meaning it's 0x0c on the left. It's a little confusing because 0x04 = 0x10, which is normal, but I saw 0x00 = 0x02, 0x01, or 0x03 when the first byte was 0x0c, which does not fit the pattern.
EDIT 4: I think the basic j jump command may be more straightforward, where everything on the right is 4 times the corresponding byte on the left, with the first byte starting at 0x08 = 0x00, which I might note is 4 less than the 0x0c = 0x00 starting point of the jal command.
It should also be noted that both these patterns break down utterly in a different section of the memory, so I have no idea about anything at all anymore.
Maybe you use the pattern to make the conversion, and then have to add an offset?