Author
|
Topic: SNES ROM Expansion and Moving Pointer Tables. (Read 2 times)
|
DarknessSavior
Guest
|
 |
« Reply #15 on: August 16, 2007, 01:09:12 pm » |
|
You're confusing NES and SNES.
$1AD09, huh?
You need to know if your ROM has a header and if it's a LoROM or HiROM game.
ZSNES or SNES9X will tell you when booting up if it's Lo or Hi.
If the game has a header, subtract $200 from the header. Otherwise, skip this step.
Now, if it's a HiROM, just drop all but the last four digits. Go to the next step.
If it's a LoROM (likely for games under 2MB), you still drop all but the last four digits. But now you need to make sure the remainder is between $8000 and $FFFF. (just $8000 if it isn't).
So, it looks like we should have $AD09 (assuming no header).
Reverse the bytes, so we get 09 AD.
Yeah, RedComet made me realize I was confusing the two. Problem being, I got the right pointer (09AD, as you did), but I still couldn't find the pointer table (though there were several instances of 09AD). I've found the pointer table for CT (with a little help) and FE before. Is there something else that could be a factor in this? ~DS |
|
|
|
|
RedComet
Guest
|
|
« Reply #16 on: August 16, 2007, 01:33:45 pm » |
|
Did you test each instance of 09AD? If so and you got nothing, try searching up for just 09.
|
|
|
|
|
Gideon Zhi
Guest
|
|
« Reply #17 on: August 16, 2007, 01:52:53 pm » |
|
To make working with the ROM easier?
Much easier. It's a five-second task to add or remove a header, and even if it takes half that to process the addition or subtraction of $200 from every pointer you're dealing with or every piece of code traced at execution or every assembly file you're writing, so long as you're going to be dealing with more than four such addresses, suddenly you're saving time  |
|
|
|
|
DarknessSavior
Guest
|
|
« Reply #18 on: August 16, 2007, 01:58:49 pm » |
|
Did you test each instance of 09AD? If so and you got nothing, try searching up for just 09.
So it's possible for a pointer to be one-byte instead of two? O.o I didn't test the pointers, but I kept note of the patterns to see if any of them looked like a pointer table. There was one particular pattern that kept repeating, 09AD and another two-byte entry, I'll re-do it and check at home. I guess the only way to find out is to change them by one and hope for the best. =D ~DS |
|
|
|
|
Nightcrawler
Guest
|
|
« Reply #19 on: August 16, 2007, 03:27:07 pm » |
|
To make working with the ROM easier?
Much easier. It's a five-second task to add or remove a header, and even if it takes half that to process the addition or subtraction of $200 from every pointer you're dealing with or every piece of code traced at execution or every assembly file you're writing, so long as you're going to be dealing with more than four such addresses, suddenly you're saving time Uhh.. use Lunar Address then. Time is is in milliseconds for both. Probably even nanoseconds. I have never in my entire 10+ years of ROMhacking had any added work time due to working with headered or non headered ROMs. It's immaterial when it comes to hacking. They're interchangeable. They're interchangeable in xkas, interchangeable in Lunar Address. Hell, they're practically mentally interchangeable. Besides, you can't calculate anything much past standard Hi-ROM conversions in your head anyway. Please explain to me how it can possibly make hacking 'Much easier'? Where are you saving time and how much are you saving? I want to know where I've gone wrong all these years.  You can have your preference and your opinion on using headered or unheadered ROM. That's fine. But now you've brought in productivity and really, where's the productivity difference? Being consistent on which you use saves you more time than anything else. Using absolute SNES addresses in your notes rather than hex offsets also comes in to play being that those are correct regardless. [/end of the cranky old dinosaur's rant] |
|
|
|
|
Disch
Guest
|
|
« Reply #20 on: August 16, 2007, 04:23:57 pm » |
|
I guess the only way to find out is to change them by one and hope for the best. =D
You are familiar with these tools called "corruptors", right? They pretty much do exactly that, but automated and quick. |
|
|
|
|
DarknessSavior
Guest
|
|
« Reply #21 on: August 17, 2007, 01:50:44 pm » |
|
Well, I've heard of them, but I've never used them. I kinda thought that it just changed random bytes though; I didn't know you could set them to change specific ones.
Also, I checked all of the instances of 09AD, changing the 09 to 10 (hoping for "Item" to change to "tem"), and I got nothing. So I started checking just 09 by itself, and I still didn't find anything (though, I didn't check all of them, I went about $2000 worth of space before being driven crazy by the monotony). However, I did find that a bunch of the 09's I was changing did some interesting things, mostly bugs, but one of them made the Worldmap Location-name boxes expand. O.o
I'm unaware if I'll be able to use that to my advantage or not, but I'll mess with that at a later date. I doubt it'll be of any use, though.
In any case, I'm going to download a few corruptors and see if I can mess around with those to get results. Any other suggestions?
~DS
|
|
|
|
|
RedComet
Guest
|
|
« Reply #22 on: August 17, 2007, 02:05:56 pm » |
|
Trace the routine and find out where the pointer is being loaded from.
|
|
|
|
|
DarknessSavior
Guest
|
|
« Reply #23 on: August 17, 2007, 02:14:57 pm » |
|
I had asked about this before. Would I, for example, set up a read breakpoint for the menu's SNES address?
~DS
|
|
|
|
|
RedComet
Guest
|
|
« Reply #24 on: August 17, 2007, 02:28:05 pm » |
|
Let's look at it this way. What do you know? The string you're looking for is at $1AD09 and you know whether the game is LoROM or HiROM. Feed Lunar Address the address and get the SNES address. Set a READ breakpoint for that. Then when the breakpoint is triggered, you'll have more information at your hands, specifically how it's reading the string. What address mode is it using? LDA ($xx),Y or LDA $xxxx,X or something else?
Let's assume its using the Indirect,Y method. That tells us one very important thing: $xx is where the pointer is stored. Check what value is there, then find out how that specific value ends up there. That means, exit the menu (if that's what we're using; either way you need to "rewind" so the code you're interested in is executed again) and then re-enter with your new breakpoint set (a write breakpoint for $xx). How's the value getting there? Is the value being written the correct value? So on and so forth.
If you run a trace log, you can take the PC address you get from these breakpoints and have a better idea of what's going on. From there you make a couple of hypotheses and then test them out with your debugger. If I change the value at address N in RAM is a different string loaded? Does Mario come screaming across the screen on the back of a donkey instead of Yoshi? Repeat until you have a full understanding of how the code works.
All of that takes time. A LOT of time. Especially if it's your first time. I've told you this before, but it took me a couple months to really understand how DBZ1's text read routine worked. So don't go into this thinking you have to figure it out in an hour or else you'll walk away disappointed. There's a lot of abstract crap you have to wrap your head around and that is the most time consuming part of learning ASM, if you ask me. What the instructions do is one thing, but learning what they do in context is another thing entirely.
|
|
|
|
|
DarknessSavior
Guest
|
|
« Reply #25 on: August 20, 2007, 01:02:53 pm » |
|
Well, over the weekend I decided to take a look. I set a read breakpoint for the menu ($1AD09). Here's what I got. $00/9E67 A7 17 LDA [$17] [$03:AD09] A:0020 X:0000 Y:001C D:0000 DB:00 S:1FE4 P:envmxdiZcHC:0790 VC:088 00 FL:48268
- Direct Indirect Long address mode.
Now, supposedly that means I'd find the address by taking the direct page address (which in this case is $0000), adding the
LDA number ($17), and taking the first three bytes I find there ($0017), and reversing them.
Problem is, that in the ROM (via Geiger) the lowest number it goes to is $008000. Am I missing something?
The next place it goes is to $000017. But technically, I can't access that either. O.o
$00/9E69 E6 17 INC $17 [$00:0017] A:AD88 X:0000 Y:001C D:0000 DB:00 S:1FE4 P:eNvmxdizcHC:0878 VC:088 00 FL:48268 There's more code, but I want to try and understand what I'm missing for the first instruction. ~DS EDIT: DarknessSavior needs to learn about linebreaks. |
|
|
|
« Last Edit: August 20, 2007, 08:45:15 pm by Nightcrawler »
|
|
|
|
RedComet
Guest
|
|
« Reply #26 on: August 20, 2007, 01:08:03 pm » |
|
Insert a couple of line breaks, skippy.
EDIT: To answer your question, $17 is RAM, not ROM.
|
|
|
|
|
DarknessSavior
Guest
|
|
« Reply #27 on: August 20, 2007, 01:14:18 pm » |
|
*linebreaks inserted* How did you know it was RAM? Is there something in the code to tell, or is it just the only portion of the game that you have access to $000017? Edit: Forgot to add this before. Y'know, I'm thinking that perhaps the pointers may be somehow related to the control codes to start a new message box. Here's why. Take a look at all the two-byte control codes I get: 00=[end]
01=[nextline]
02=[end2]
05=[closeboxfade?]
08=[end3]
0D=[end?]
1A00=[newbox]
1A0B=[anothertextbox]
1A1B=[textbox]
1A31=[textbox]
1A81=[textbox]
1A82=[textbox2?]
1A84=[textbox]
1A85=[textbox]
1A86=[textbox]
1A87=[textbox]
1A8A=[textbox]
1A8E=[textbox]
1A8D=[textbox]
1B00=[newbox2?]
1B1C=[newbox]
1B2E=[newbox]
1B81=[newbox]
1B82=[newbox3]
1B84=[otherwindow2]
1B86=[anothernewindow]
1B89=[newwindow] Is that NORMAL!? ¬.¬ (Just so there's no confusion, anything that says "textbox" is to start a conversation, any "newbox" or "anotherwindow" is to have a second person get involved in the conversation.) ~DS |
|
|
|
« Last Edit: August 20, 2007, 01:20:03 pm by DarknessSavior »
|
|
|
|
RedComet
Guest
|
|
« Reply #28 on: August 20, 2007, 01:23:11 pm » |
|
*linebreaks inserted*
How did you know it was RAM? Is there something in the code to tell, or is it just the only portion of the game that you have access to $000017?
Still way too much side scrolling going on, but I digress. The reason I know it's RAM is because I win at the internets. |
|
|
|
|
DarknessSavior
Guest
|
|
« Reply #29 on: August 20, 2007, 01:28:22 pm » |
|
Apparently I lose at the internets. -.-
*points upward* Can you explain the weird control codes? Might that have something to do with the mysterious pointers? It seems like almost every dialogue section has it's own control code to open a conversation.
~DS
|
|
|
|
|
|
