Okay, this is mostly wrong. I'll elaborate but I wanted to get this out there ASAP so nobody went and took it as gospel. I'll immediately be editing this post with clarifications.
What you want to do depends greatly on the game, depends on how much text you're talking about in the grand scheme of things, depends on how much text gets accessed using a particular printing routine.
You CAN change a 2-byte pointer into a 3-byte pointer, but it requires some assembly-level hacking. It's one of the simplest hacks though (and was one of my very first) so it's a good first learning step. However, if there's not much text it might make more sense to move the pointer table somewhere else and deal with bank restrictions as puzzledude says.
There are a few points here that are 100% wrong, that I want to lay out immediately:
1: JSL operations have *nothing* to do with text addresses, barring whatever may end up stashed in various registers or RAM locations prior to the JSL.
2:
So if 7609A is the start of text, then 9A 60 C7 is a 3byte pointer. If there is no C7, it is a 2byte pointer. But C7 is somewhere (or at least the game knows of it). Or the game knows a 70000 address and looks a 9A 60 offset from it.
The above is *ONLY* true (the C7 bit) if your game is HiROM. If it's a LoROM, then you have an entirely different kettle of fish to deal with. Rather than explaining (I'm somewhat short on time) I'll just prompt you to download Lunar Address and use that to do your file address->snes address map calculations.
3: HiROM banks are 64K in size, not 32. You have 0x10000 addresses to work with in that case, not 0x8000.
4: If you do change your pointer table from 2 bytes to 3, you have to change *every* pointer associated with that particular load, otherwise the game will break when it tries to load one.
This doesn't necessarily just include the text referenced by that particular pointer table: if there are other bits of data the same loading routine uses, their pointers will need to be changed too. Conversely, if you move the data (and its pointer table) out of its originating bank and the game expects to use the same routine
and the same bank number to load other things in that bank, you're going to have a bad time. (This is probably what happened with puzzledude's game "just [giving] up for no reason."
Here's what you want to do.
1: Figure out whether your game is HiROM Or LoROM. There are a number of ways to do this; snes9x tends to tell you when you load a ROM into it.
2: Convert your text's file address to an SNES HiROM or LoROM address.
3: Load up your game in Geiger's SNES9x and set a read breakpoint for your string's pointer and for the first byte of your string. When the debugger snaps first, it'll have snapped on your pointer load; you can then tick the "CPU" check box in the tracing menu and it'll start logging opcodes until it hits another breakpoint, until you close the emulator, or until you untick the check box.
There's a fairly good chance that you won't have your text's bank byte load in your log; it very well might happen before the actual pointer load. But it'll give you a good starting point, and you can get to a point where your game is about to load text but hasn't yet, enable CPU tracing, trigger the text, and turn off CPU tracing when it's on-screen. The whole thing will have (or at least should have) ended up in your trace log in this case; from there it's just a case of reading backwards from where you found your text load.
How you approach this is up to you. You might decide to move the data, you might decide to go with a 24-bit routine. The latter is more useful if you cannot fit all of your text in an entire LoROM/HiROM bank, but the former is probably easier.
The text starts at the adress 07609A.
That makes the pointer 9A60 at the adress 76090, so the pointer table starts at 76090.
This tells me that your game is probably HiROM. That means you have 64K of space per bank to work with, not 32
Topic: Expanding SNES pointer tables from 2-byte to 3-byte (Read 4178 times)