Author
|
Topic: A little 6502 help? (Read 2 times)
|
Alexcalibur
Guest
|
 |
« on: May 24, 2008, 04:10:15 pm » |
|
Simple question.
Not so much how it works, but say I were to find some code that I know is executed. I found it through corruption, but the part I'm interested in comes in right after a RTS (60).
I don't know where it is in ram, so I can't use the debugger, and I don't really know how to follow where the 60 goes. Any help? I understand the opcodes, I'm just pretty new at piecing together code. So this may be something I should know how to understand but don't.
|
|
|
|
|
Lenophis
Guest
|
|
« Reply #1 on: May 24, 2008, 04:21:29 pm » |
|
60 - RTS (Return from subroutine)
Something JSR'ed into needs an RTS, so if you know what calls the routine with the RTS, go back to that after the JSR call.
|
|
|
|
|
Alexcalibur
Guest
|
|
« Reply #2 on: May 24, 2008, 04:22:25 pm » |
|
60 - RTS (Return from subroutine)
Something JSR'ed into needs an RTS, so if you know what calls the routine with the RTS, go back to that after the JSR call.
But that's what I don't know. I don't know what called it. Sorry if I phrased my question wrong. |
|
|
|
|
BRPXQZME
Guest
|
|
« Reply #3 on: May 24, 2008, 04:50:59 pm » |
|
The RTS jumps somewhere else entirely.
-If the code you want to look at comes after the RTS physically, you’re barking up the wrong tree; the execution of the RTS will likely not be to the very next line.
-If it’s executed after an RTS jumps to the spot, it doesn’t really matter because you’re looking at the right code anyway.
-If you want to know where the code is that is executed after an RTS jumps there, you need to know what’s on top of the stack; the RTS instruction jumps to the address stored on the top of the stack.
|
|
|
|
|
Alexcalibur
Guest
|
|
« Reply #4 on: May 24, 2008, 04:59:17 pm » |
|
The RTS jumps somewhere else entirely.
-If the code you want to look at comes after the RTS physically, you’re barking up the wrong tree; the execution of the RTS will likely not be to the very next line.
-If it’s executed after an RTS jumps to the spot, it doesn’t really matter because you’re looking at the right code anyway.
-If you want to know where the code is that is executed after an RTS jumps there, you need to know what’s on top of the stack; the RTS instruction jumps to the address stored on the top of the stack.
It's the last one. I know how the RTS works (with my exception of that stack part). But I found this part of the code in the romfile, and I know it's it because the game freezes at the expected point if I change it. I can understand any ASM I find, and I've even modified some of the game's orginal, but I just want to get to where this code returns to. So since you said check the stack, I need to use a debugger, right? Maybe it's my debugger skills that need work, but I don't really know how I would do that. I'm getting better with the debugger, and I've followed routines before, but I don't know how to determine where this code is (in relation to where I found it in the romfile). How would I find it in the debugger? EDIT: Curse my lack of communication skills. Here's an example. I found this code. It's in hex, since I don't really think in opcodes. C9 EF F0 0B "blah blah filler stuff that's 0B long" 60 I understand the code: compare to EF, if equal branch forward 0B I just need to know where that 60 goes. And if I'm right about the debugger, some help using it. Thanks for help so far and any further help I might get. |
|
|
|
« Last Edit: May 24, 2008, 05:15:11 pm by Alexcalibur »
|
|
|
|
Gideon Zhi
Guest
|
|
« Reply #5 on: May 24, 2008, 05:41:01 pm » |
|
Well, the trick is that if you know where the address is in the ROM, and you know how to convert ROM to machine addressing, you already know where the address is in RAM. Since the only game I know you're working on is Fire Emblem, I'm going to assume that this is the NES we're dealing with - convert the address of the RTS into a pointer for your game, then set the debugger to snap on execution for that value. If that doesn't work, add/subtract 0x4000 to/from the value and try again.
|
|
|
|
|
Sliver X
Guest
|
|
« Reply #6 on: May 24, 2008, 05:45:46 pm » |
|
Debugging is an art of its own, but it's not very hard.
Since this is the NES, FCEUXD (Or FCEUXD SP) are what you want to use. If I were in your situation, I would do the following:
Since you've already located the subroutine, look back until you see another #$60: This is a surefire indicator that you've hit the beginning of the routine (The preceding #$60 is for another routine, though, so don't mess with it).
Copy a string of bytes from the beginning of the routine, and look for this in RAM via the Hex Editor: Set an EXECUTE breakpoint at the first byte of the routine once you find it, and it should trip the debugger when it's run. Now simply use the Step Into function, and when you step it to the RTS it will return to where it was called. There's your next routine being run.
*edit* Oh, and you can right click any address in the RAM view of the hex editor and click "Go to here in ROM file" and it will take you there for editing, whatever.. Well, assuming it's a ROM mapped address in RAM (> $7FFF?).
|
|
|
|
|
BRPXQZME
Guest
|
|
« Reply #7 on: May 24, 2008, 05:51:40 pm » |
|
Please, learn how the stack works! It is a friend, not an enemy! The value could have been “pushed†onto the stack anywhere. In fact, it is not all that uncommon to see a value pushed onto the stack right before an RTS instead of being an RTS proper. Unfortunately, if this is not the case... then if you’re just looking at the code, you’ll need to know where the subroutine begins in order to know where it is being jumped to from, because that’s where it will return to. But if you’re debugging, you just need to know where the top of the stack is. “SP†(the stack pointer) holds the key to the stack’s location. When it is empty, its value is $00. With each “push†on top of the stack, $01 is subtracted (so when it has 1 element, SP is $FF, when it has 2, SP is $FE, when it has 5, $FB... and so forth). The actual location of the value in the stack will be held at $01xx, where xx is the value of SP. I have no idea what kind of debugger you’re using or how it works (hell, I never used a 6502 debugger before; I’ve only ever written 6502 code willy-nilly, not read it!), but if you get it to break at the RTS, you can either check the stack yourself, or step-by-step and see where it goes (i.e. let the computer do it for you). |
|
|
|
|
Sliver X
Guest
|
|
« Reply #8 on: May 24, 2008, 05:55:48 pm » |
|
Yeah, the Stack is something I very rarely use: I think the only times I really do are PHA/PHY/PHXing registers (And pulling them back) before jumping to new routines I write by inserting JSR hooks.
|
|
|
|
|
tomaitheous
Guest
|
|
« Reply #9 on: May 24, 2008, 08:10:21 pm » |
|
I just need to know where that 60 goes. Like what others have written, get familiar with a debugger. It's as simple as trapping on the address of that RTS and just single stepping on the return. |
|
|
|
|
Alexcalibur
Guest
|
|
« Reply #10 on: May 24, 2008, 10:30:03 pm » |
|
Thanks alot for the answers, I think I got it now.
Would've thanked you all sooner, but Indiana Jones was beckoning.
Gideon had already told be about the stepping in on the debugger, and I don't think I ever thanked him, so thanks. He also guessed right, its fire emblem NES, not a secret-I just didn't think to mention it. I guess there's alot on the debugger I don't understand yet.
Thanks for all the tips, lots of methods I can try now, and I'm sure they will work. I kind of understood how the stack works, but I don't think I'll be messing with it. I've only stored the X register on it, and I don't really want to mess with it more.
I do know what kind of pointers fire emblem uses though, and that sounds the simplest, so I think I'll try that first.
Thanks again.
|
|
|
|
|
|
RHDN Forum Archive
