unregistered wrote:
No, it doesn't run fine despite the fact that it is in the wrong place.
Okay. What goes wrong?
Also, do the following:
Open FCEUX's debugger, Add an execute breakpoint for $8000-$BFFF.
Go to Debug, Trace Logger. Log last 10,000 instructions. Check "Automatically update Window While Logging".
Press "step into" a single time on the debugger.
Go to NES, power.
Press "start logging" on the Trace Logger.
Press "run" on the debugger.
Press "step into" once after the break.
This will log the last 10,000 instructions before your code mysteriously ends up in $8000-$BFFF. Check the very last few instructions in the Trace logger to see the address where the code that's causing you to end up in $8000-$BFFF is. Find out what's going wrong using that.
You have a listing file. So when I end up with a bug like this, I look at the trace logger to find jmp/bpl nearest to the problem. Then I look the address that was bpl/jmp'd to to find where in the code the problem is occurring.
Edit: Wait... this happens immediately on reset? And you have one .org statement? How does your assembler set the vectors? Have you checked the actual rom's vectors and not just the listing file? I couldn't tell from your last post on the subject.
Debug, Hex Editor, view, rom file. ctrl+g 400A. What are the six bytes starting there? If it's something like: 9E 82 00 80 37 83, then somehow your listing file doesn't represent what's actually in your rom. If it's like: 9E C2 00 C0 37 C3, and you're still ending up at $8000 on reset I would just be really confused. But with my confusion, I would follow the above instructions and see how it ends up at $C000-$FFFF if it starts on $8000. Find out when it changes, either from $8000 to $C000 or $C000 to $8000.