nesdev.com

Will try it in Nintendulator. ...At first after loading and running in nintendulator it stepped on about $C339 and I was thankful. And then after clicking on run and then on step again it was back to the line $8007 and then to $800A and back to $8007.

btw, thank you tepples for your help too. An execute breakpoint; that breaks when something executes... like a subroutine from $800A? Or is it during every branch inside that range $8000-$BFFF?


it's ok, thank you cpow for helping me. This conversation started about 5 posts ago...

If I were investigating it, I'd first look for how many frames it takes to get to $8007, then how many scanlines in that frame. At some point, you'll figure out what's happening just before it gets to $8007.

I'd set an execute breakpoint on $8007, reset, and run. Look at the execution backtrace when the breakpoint hits...

It's not a bug in FCEUX, at least not one in version 2.1.5. I just ran Galaxy NES which is also has only 16 KB prg, and it never executes anything from 8000-BFFF.

BUT... nothing bad also happens if it does. Since the banks are just mirrored (AFAIK) when you have only 16K, it should actually still work fine. I changed Galaxy NES' reset vector to point to reset-$4000 instead of just reset, and it ran in the other bank fine until the first jmp sent it to a $C000-$FFFF where it still continued as normal.



The reason you'd see these over and over again is because you wait for vblank that way. Until $2002 returns a set negative bit, the loop will keep going thousands of times at maximum. That's not a bug, that's how your program is detecting when your frame starts.

What I'd do to avoid these affecting your breakpoint is look for the address of the instruction immediately after that loop, and start stepping from there.

In any case, I haven't read yet if there is an actual problem. Does your program run fine despite the fact that it is in the wrong place? Does your code ever actually run from $C000-$FFFF at all? (Set a breakpoint for that).

If it is running instructions from both $C000-$FFFF AND $8000-$BFFF, that is mighty strange. ctrl+f all the .org statements in your code and see what's up.

But if it doesn't run from both, it might just be something trying to be clever because the banks end up mirrored anyway.

When using WINDOWS FCEUX 2.0.3 how could I tell how many frames have passed?


Ok thanks! The code around $8007 looks exactly like my code at $C007. It's the same reset code... first it waits through two vblanks. That's why all the back and forth happens between those two lines of code I posted.
edit:Kasumi agrees with me!

If you try to step through the code during a wait for Vblank you'll go crazy... The code will loop several thousands of times, it would be insane to do that. Do like Kasumi said: If you hit a loop like this when debugging code, set up a breakpoint for the address that immediately follows the loop and click on "run", then you can continue to step through the code after the loop.

Why the CPU is running code at $8000-$BFFF is still a mystery though... I would probably set up a breakpoint for that range and reset, so that as soon as the first byte in $8000-$BFFF is read I could inspect everything.

What is the value in your IRQ vector? You know, even if you don't intentionally use IRQs, the APU might fire them if it's not properly initialized (and you don't have SEI in your startup code). The BRK instruction also causes an IRQ to happen, and since the opcode for that instruction is $00, it's fairly common for the CPU to interpret some $00 in your ROM as a BRK instruction if some bug cause the PC to run wild.

tokumaru, what do you mean by "you dont have SEI in your startup code"? That's the very first thing.



edit: think I understand now... I have sei in my startup code and so that means the APU wont fire interrupts at me?

No, it doesn't run fine despite the fact that it is in the wrong place.


Thank you, yes it has started running

that code for a long while.


Thanks again , there is only one .org statement in my code.

That happens as soon as the cpu is reset... it goes into $8000 and runs its SEI.





Thanks for this info too!

My bad; I remembered wrong. I thought there was a run 262 lines button, but there isn't; just a 128 lines button. In the debugger, at the lower right, is a display of how far the emulated PPU is down the screen. Three dots make one PPU cycle, and one line is 341 dots.

If your NMI handler is defined in the file "daprg-vblank.asm", are you sure it saves and restores all registers that it uses? Try putting a breakpoint at vblank: and single stepping through that; a stack manipulation problem might cause the program counter to go to hell.

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.

Please post the contents of "daprg-vblank.asm".

On my debugger screen the lower right is blank?




Excellent!!! Thank you so much Kasumi! I really enjoyed your step by step tutorial! My problem was that it stayed on $C000 until reaching a rts and then it switched over to $7xxx. So I opened the file and found the rts and finally noticed that the function was called four times with jmp... not jsr...

Now it stays on $C000-$FFFF. In the debugger it always stops at $C336... that has an rti. Need to think a bit about what to do next... though there's no breakpoint. So why does it pause at $C336? Maybe because that's the last line of code... the rti is after the label irq:...


tokumaru, I don't believe I can do that.

I'm not 100% clear. You're saying fceux's debugger is stopping your code at $C336 despite you not having any active breakpoints? That's pretty strange. Is break on bad opcode checked? That's about my only guess. Are there any problems on a different emulator? Does anything else "run into" that RTI?

Something like:


?

Also: It is much easier to help you when you can post code. I understand the arrangement you've got with your sister, but there's really no way and no reason for us to steal your content by you posting small snippets.

I'd understand protecting your assets like graphics and music, and I understand maybe something totally proprietary like a unique compression scheme. But for what you're doing now, it's all problems a lot of us have faced and solved. So there's no reason for us to steal, and we can probably provide a great deal more help when we're not guessing.

I was only trying to help, I had no intentions of "stealing" anything. You do know that once a ROM is available everyone can see what the program is doing, right? Hiding assembly source code doesn't really protect you of anything.

Anyway, the problem has been found, so there's no need to post anything. RTS without JSR is indeed a nasty bug, you have to be careful about that. If a return address wasn't put on the stack, the RTS will get anything that is at the top of the stack and jump to a bad location.