8x16 and whatever else unreg wants to know

Are you new to 6502, NES, or even programming in general? Post any of your questions here. Remember - the only dumb question is the question that remains unasked.

Moderator: Moderators

unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Post by unregistered »

cpow wrote:
unregistered wrote:I havent used FCEUX for Windows very much... but I tried to set an execute break point on $8000-$BFFF. The game continues to run these two lines over and over:

Code: Select all

00:8007:AD 02 20  LDA $2002 = #$00
00:800A:10 FB     BPL $8007
Maybe a bug in FCEU debugger if your ROM is 16KB? Try it in some other debugging-capable tool.
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. :D An execute breakpoint; that breaks when something executes... like a subroutine from $800A? Or is it during every branch inside that range $8000-$BFFF?
cpow wrote:EDIT: Many apologies if my response is way off the mark. I just realized I stepped into this thread on page 33!
it's ok, thank you cpow for helping me. :) This conversation started about 5 posts ago...
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples »

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.
User avatar
cpow
NESICIDE developer
Posts: 1097
Joined: Mon Oct 13, 2008 7:55 pm
Location: Minneapolis, MN
Contact:

Post by cpow »

tepples wrote: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...
User avatar
Kasumi
Posts: 1293
Joined: Wed Apr 02, 2008 2:09 pm

Post by Kasumi »

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.
unregistered wrote:The game continues to run these two lines over and over:

Code: Select all

00:8007:AD 02 20  LDA $2002 = #$00
00:800A:10 FB     BPL $8007
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.
Last edited by Kasumi on Mon Apr 30, 2012 1:19 pm, edited 1 time in total.
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Post by unregistered »

tepples wrote:If I were investigating it, I'd first look for how many frames it takes to get to $8007
When using WINDOWS FCEUX 2.0.3 how could I tell how many frames have passed?
tepples wrote:, then how many scanlines in that frame. At some point, you'll figure out what's happening just before it gets to $8007.

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! :o
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru »

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.
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Post by unregistered »

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

Code: Select all

.org $C000

reset:  sei
	cld
	; Wait two VBLANKs.
-	lda $2002
	bpl -
-	lda $2002
	bpl -

	; Clear out RAM.
        lda #$00
        ldx #$00
-       sta $000,x
        sta $100,x
        sta $200,x
        sta $300,x
        sta $400,x
        sta $500,x
        sta $600,x
        sta $700,x
        inx
        bne -

	; Reset the stack pointer.
edit: think I understand now... I have sei in my startup code and so that means the APU wont fire interrupts at me?
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Post by unregistered »

Kasumi wrote:Does your program run fine despite the fact that it is in the wrong place?
No, it doesn't run fine despite the fact that it is in the wrong place.
Kasumi wrote:Does your code ever actually run from $C000-$FFFF at all? (Set a breakpoint for that).
Thank you, yes it has started running

Code: Select all

00:C096:9D 00 02  STA $0200,X @ $024C = #$00
00:C099:E8        INX
00:C09A:D0 FA     BNE $C096
that code for a long while.
Kasumi wrote: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.
Thanks again :) , there is only one .org statement in my code.
:?
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Post by unregistered »

tokumaru wrote: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.
That happens as soon as the cpu is reset... it goes into $8000 and runs its SEI.
tokumaru wrote:What is the value in your IRQ vector?

Code: Select all

vblank: inc FRAME_CNT
        .incsrc "daprg-vblank.asm"
irq:    rti
tokumaru wrote: 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.
Thanks for this info too! :D
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples »

unregistered wrote:
tepples wrote:If I were investigating it, I'd first look for how many frames it takes to get to $8007
When using WINDOWS FCEUX 2.0.3 how could I tell how many frames have passed?
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.
User avatar
Kasumi
Posts: 1293
Joined: Wed Apr 02, 2008 2:09 pm

Post by Kasumi »

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.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru »

Please post the contents of "daprg-vblank.asm".
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Post by unregistered »

tepples wrote:
unregistered wrote:
tepples wrote:If I were investigating it, I'd first look for how many frames it takes to get to $8007
When using WINDOWS FCEUX 2.0.3 how could I tell how many frames have passed?
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.
On my debugger screen the lower right is blank? :?

Kasumi wrote:
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.
Excellent!!! Thank you so much Kasumi! I really enjoyed your step by step tutorial! :D 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... :oops:

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 wrote:Please post the contents of "daprg-vblank.asm".
tokumaru, I don't believe I can do that. :(
User avatar
Kasumi
Posts: 1293
Joined: Wed Apr 02, 2008 2:09 pm

Post by Kasumi »

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:

Code: Select all

NMI:
   ;NMI code here, without an rti
IRQ
   RTI
?

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.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru »

unregistered wrote:
tokumaru wrote:Please post the contents of "daprg-vblank.asm".
tokumaru, I don't believe I can do that. :(
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.
Post Reply