News: 11 March 2016 - Forum Rules

Author Topic: Expanding SNES pointer tables from 2-byte to 3-byte  (Read 4540 times)

gorgyrip

  • Jr. Member
  • **
  • Posts: 46
    • View Profile
Expanding SNES pointer tables from 2-byte to 3-byte
« on: August 05, 2014, 01:33:12 pm »
Please bear with me, i'm a complete noob at this. The game in question it's HIROM and without a header. The rom it's 1,5 mega and i expanded it to 2 mega. I need to have all the text in the expanded area.
The text starts at the adress 07609A.
That makes the pointer 9A60 at the adress 76090, so the pointer table starts at 76090.

I found a document by KingMike. It starts like this:
"Well, first you're going to need to find out if the text routine itself is using absolute (2-byte) or long (3-byte) addressing mode to read your script.
So, use tracing to find out where your script is being read from."

My question: How to do that?


puzzledude

  • Sr. Member
  • ****
  • Posts: 308
    • View Profile
Re: Expanding SNES pointer tables from 2-byte to 3-byte
« Reply #1 on: August 05, 2014, 05:11:44 pm »
-
« Last Edit: August 06, 2014, 07:52:36 am by puzzledude »

Gideon Zhi

  • Discord Staff
  • Hero Member
  • *****
  • Posts: 3535
    • View Profile
    • Aeon Genesis
Re: Expanding SNES pointer tables from 2-byte to 3-byte
« Reply #2 on: August 05, 2014, 05:37:32 pm »
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:
Quote
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.

Quote
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 :)
« Last Edit: August 05, 2014, 05:59:10 pm by Gideon Zhi »

gorgyrip

  • Jr. Member
  • **
  • Posts: 46
    • View Profile
Re: Expanding SNES pointer tables from 2-byte to 3-byte
« Reply #3 on: August 06, 2014, 09:00:41 am »
OK. I started the debugger  and entered a read breakpoint at $C7:6090 (the pointer adress).
Right before the text, the debugger snaps and i get this:
$C7/5869 B7 57       LDA [$57],y[$C7:6090]   A:6090 X:0184 Y:0000 P:envMxdiZc

What should i do next?
The document i'm using mentions this:
Note the [] indicates "long" addressing mode, where the ROM bank is read along with the address. This instruction means a 3-byte pointer to the text is stored at RAM offset $57-59 (+ the value of the D register, in the bank in the DB register)"
How can i find the values of D and DB?

Gideon Zhi

  • Discord Staff
  • Hero Member
  • *****
  • Posts: 3535
    • View Profile
    • Aeon Genesis
Re: Expanding SNES pointer tables from 2-byte to 3-byte
« Reply #4 on: August 06, 2014, 11:02:41 am »
How can i find the values of D and DB?

Uncheck squelch. This is the most pointless option and I have no idea why it's enabled by default.

gorgyrip

  • Jr. Member
  • **
  • Posts: 46
    • View Profile
Re: Expanding SNES pointer tables from 2-byte to 3-byte
« Reply #5 on: August 06, 2014, 11:32:17 am »
Uncked. Thanx. Now I get this:
$C7/5869 B7 57       LDA [$57],y[$C7:6090]   A:6090 X:0184 Y:0000 D:0000 DB:00 S:0187 P:envMxdiZc HC:0998 VC:030 FC:47 I:00
According to the document above, then pointer would be stored at 00:0057.
I assume that's the RAM adress.
What next

Gideon Zhi

  • Discord Staff
  • Hero Member
  • *****
  • Posts: 3535
    • View Profile
    • Aeon Genesis
Re: Expanding SNES pointer tables from 2-byte to 3-byte
« Reply #6 on: August 06, 2014, 11:34:00 am »
Uncked. Thanx. Now I get this:
$C7/5869 B7 57       LDA [$57],y[$C7:6090]   A:6090 X:0184 Y:0000 D:0000 DB:00 S:0187 P:envMxdiZc HC:0998 VC:030 FC:47 I:00
According to the document above, then pointer would be stored at 00:0057.
I assume that's the RAM adress.
What next

Not quite; the pointer to the pointer is stored at 0057. You have to figure out where the game's putting the pointer and how it's using that to access its text.

gorgyrip

  • Jr. Member
  • **
  • Posts: 46
    • View Profile
Re: Expanding SNES pointer tables from 2-byte to 3-byte
« Reply #7 on: August 06, 2014, 12:23:19 pm »
Please teach me how to do that.

Gideon Zhi

  • Discord Staff
  • Hero Member
  • *****
  • Posts: 3535
    • View Profile
    • Aeon Genesis
Re: Expanding SNES pointer tables from 2-byte to 3-byte
« Reply #8 on: August 06, 2014, 01:56:34 pm »
There's only so much I can do; you'll have to learn some 65816 and read the code. But I'll offer a tip.

You've identified where the pointer's being loaded. From there, identify where the actual text is being loaded. At least some if not all of the logic that gets the program from loading the pointer to loading the text is going to be somewhere in between those two loads.

KingMike

  • Forum Moderator
  • Hero Member
  • *****
  • Posts: 7188
  • *sigh* A changed avatar. Big deal.
    • View Profile
Re: Expanding SNES pointer tables from 2-byte to 3-byte
« Reply #9 on: August 06, 2014, 03:08:45 pm »
Uncheck squelch. This is the most pointless option and I have no idea why it's enabled by default.

Maybe made on old PCs that would choke on large text files (but then I assume that's what the Split option was for).
"My watch says 30 chickens" Google, 2018

Gideon Zhi

  • Discord Staff
  • Hero Member
  • *****
  • Posts: 3535
    • View Profile
    • Aeon Genesis
Re: Expanding SNES pointer tables from 2-byte to 3-byte
« Reply #10 on: August 06, 2014, 03:22:22 pm »
Maybe made on old PCs that would choke on large text files (but then I assume that's what the Split option was for).

That's what the Trace Once option is for :/