PSX script insertion - pointer values increasingly off by 8 somehow

Started by LiquidDivide, December 01, 2022, 04:12:44 PM

Previous topic - Next topic


Hello everyone. I've been meddling around with translations for a while, but have made significant progress on my first real translation hack. I have the script dumped and translated. I know where pointer table is and how to modify it to point to the right places after inserting my text. I'm now trying to automate this process. I can do it by hand, but that will take forever and would be error-prone.

I've tried using the Pointer Tables utility I found here by rveach. It extracts the script perfectly and everything looks great. Once I modify it with my translated text, the insertion gets messed up. Every pointer value is off by a factor of 8, and it compounds for each pointer.

So, my first pointer has the correct pointer value (0x5cc9)The next pointer it creates is (0xB4C9)It should be (0xACC9) (0xB4 - 0x8 == AC)The next pointer value it creates is (0xE4C9)It should be (0xD4C9) (0xE4 - 0x10 == D4)
Does anyone know how to get this tool to calculate the pointer value correctly? I've tried messing around with the XOffest parameter some, but it doesn't seem to matter what the value is.

I'm also open to learning different / better tool(s) with good documentation. Any recommendations there? I did look at Atlas and Cartographer, but they just looked too difficult to learn when this other one looked so simple.

I'm just running out of ideas here. I could write my own custom inserter, but I feel like there's got to be a better way


Careful using words like factor in the future -- there is such a thing as shifted pointers/size values for some setups, and others using upper bits as indicators (32 bits is 4 gigabytes of byte addressable space, 31 then being 2 gigabytes but maybe a compression, subdirectory or whatever) that might see you multiply.

However what you have is called relative pointers. General calculation for them is of the form "take address of pointer, add value contained at pointer itself to get final result".
Theoretically you can have relative offset where you get address and add value at it and still be a fixed value out like some things start counting at the start of the text section but eh.

Relative jumps and pointers are a far more common thing on older systems (if you have only got 8 bits, possibly less, to play with then adding to current location might be better than always starting at zero, even more so in assembly coding for jumps) but I have seen them on newer systems than the PS1 as well. There are some perks and reasons for doing it on more modern stuff as it can simplify lookup a tiny bit but the ROM hacker's lot is to reason why but also deal with the results, or go through the annoyance of redoing the code to work another way (very little benefit in doing that here, or indeed in essentially anything).

I don't know what atlas+cartographer have to handle this, or kruptar7 ( ) and oriton if you prefer the other big popular tool.
When I have encountered it in the past it was only on small puzzle games with a few dozen lines of text and I believe they also had nice end of section indicators (search for end of section indicator, dump list of them with hex editor, can do the rest with a spreadsheet if you want -- be it by calculating it or by having an increasing pattern in another column and taking that from things as well).


Alright, I'll keep that in mind. I was struggling coming up with an accurate way of describing the problem. I'll take a look at kruptar. It sounds promising from the quick peek I took.

These pointers aren't hard to calculate. You add an offset to the location of the start of the string, drop the leading byte (so your down to 4 bytes again) and then swap the two byte pair positions. I have calculated them manually to make sure I know what's going on and just threw them in the rom, and it works fine. I think I just need a tool that provides me with the right options to calculate it.

Thanks again for the help. Much appreciated.


Okay, I spent a little bit taking a look at the other tools and you're right, they just aren't going to be able to calculate these pointers correctly, or at least I don't know how to get them to do it from the documentation I read. I actually don't even know how the first tool I used was getting so close to calculating it correctly in the first place. Kind of crazy, really, considering there was no way to specify the pointer offset that has to be added to calculate it. At any rate, I was able to get a spreadsheet to calculate it for me, so I really just need to convert the string output of that to binary and dump it to a file. Then I can just use windhex (or write a script or something) to overwrite the pointer table altogether. Thanks again for the help.