@Storall, your posts regarding the steps you took with this process are clear and helpful! I really appreciate you taking the time to spell things out like this. There are a handful of points I'd like to ask for clarification on. I'd like to understand your process outline more completely before I perform the steps myself.
Here are the points to clarify:
Chicken Knife's new problem is that he doesn't know the procedure of how to convert ROM address to CPU address.
I've actually done a lot of converting ROM to RAM address (which I believe is the same as CPU address since CPU only interacts with RAM other than bank loading / switching) But I'm glad you took the time to discuss this, because it brings up an interesting point:
- CPU $8000-$BFFF: 16 KB PRG ROM bank, either switchable or fixed to the first bank
- CPU $C000-$FFFF: 16 KB PRG ROM bank, either fixed to the last bank or switchable
All the times I've had to calculate RAM address in my work on DQ1/DQ2/DQ3, I've only ever had to use the $8000-BFFF address range, never the $C000-$FFFF range. I'm glad to be reminded that data could also be stored in the $C000-$FFFF range, because I've become so unaccustomed to never dealing with that area. I've mostly dealt with these addresses for the script, and the script seems to never be stored there curiously.
2. Our data is hiding at $8000-BFFF or $C000-FFFF
- 8000+32d4 = b2d4
- c000+32d4 = f2d4
It seems like I had the right idea to search the RAM for the sequential bytes that store monster xp&gold, but where I probably failed was that this data wasn't loaded there yet, even though I was in battle when I checked. I'm guessing that the code executes a bankswitch command at some point just before it actually needs that monster reward data, probably because the rest of the time, the code is pulling from the bank that stores miscellaneous battle text. Therefore when I checked for those bytes, it wasn't loaded yet. But after I set these breakpoints, once I get the hit, if I then go check the RAM data, I should find the bytes there.
- Don't use K==#0 though; that only correctly works when using PC execute breakpoint
You said this in reference to setting the read breakpoint. I'm not sure what K==#0 means and would enjoy some further explanation here.
It might be worthwhile doing this same procedure for Japan also and compare the logs.
I was planning to do this.
One of my tech savvy friends suggested that I could use a text editor compare function that would allow the program itself to compare the two sets of text. That sounds great, but I would probably not be able to achieve perfectly synced timing between the two different versions. I'll do it myself manually, and hopefully I will be able to differentiate between the stuff directly resulting from timing differences.
- Condition: $B2D4==#04
This sounds like a great tip. Thank you! I'll play with setting the condition.
Now I have some questions regarding your diary:
- Noticed it had a rts and stepped out.
I know that RTS is a return from subroutine. Two question, why did you react to that, and what does "stepped out" mean? When I get breakpoint hits, I typically only hit the "run" button to have the game go past the break. I see there are other options involving "stepping" but I don't really understand what those mean.
- Again another rts so I floated out.
Not sure what floated out means.
- Now I turned off the trace logger.
- A new area of code.
Time to think!
- So it had $04 and became $06.
- Interesting weird piece of asm but it looks like our bonus math.
- To test, I left-clicked the address I wanted to nop out.
More specifically, it's that vertical blank column on the left side of address.
Hover your mouse there and it says on bottom:
leftclick = inline assembler
rightclick = hexeditor
- Opened the 'Inline Assembler'. Entered the nop replacement (nop + enter).
When it looked good, I hit 'apply.' Close box.
- note: it's temporary and not permanent to rom.
I get a little lost here unfortunately. So you start off by analyzing the trace log you created for this second section of code that deals with writing the inflated slime exp. When you say you left clicked the address you wanted to NOP out, you are saying that you left clicked that CPU address on the left side of the debugger screen? If so, I didn't realize that I could rewrite code from that screen directly. Vertical blank column in the debugger? I probably need to be home and working with this to potentially see what you are referring to. It sounds like FCEUX actually has an assembler function. Very cool! It sounds like you just replaced existing bytes in the code with the NOP operations, which didn't require any expansion of the code. That sounds easy enough.
Ok, that's it for questions, and hopefully I'll be able to figure out what you covered in the last paragraph just by playing around. I'm pretty excited to try all this now.