It is currently Fri Jul 20, 2018 11:40 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 1451 posts ]  Go to page Previous  1 ... 31, 32, 33, 34, 35, 36, 37 ... 97  Next
Author Message
 Post subject:
PostPosted: Mon Apr 30, 2012 10:27 am 
Offline
User avatar

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


Top
 Profile  
 
 Post subject:
PostPosted: Mon Apr 30, 2012 10:47 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20280
Location: NE Indiana, USA (NTSC)
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.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Apr 30, 2012 11:20 am 
Offline
NESICIDE developer
User avatar

Joined: Mon Oct 13, 2008 7:55 pm
Posts: 1060
Location: Minneapolis, MN
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...


Top
 Profile  
 
 Post subject:
PostPosted: Mon Apr 30, 2012 1:18 pm 
Offline
User avatar

Joined: Wed Apr 02, 2008 2:09 pm
Posts: 1154
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:
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.

Top
 Profile  
 
 Post subject:
PostPosted: Mon Apr 30, 2012 1:18 pm 
Offline
User avatar

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


Top
 Profile  
 
 Post subject:
PostPosted: Mon Apr 30, 2012 1:26 pm 
Offline
User avatar

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


Top
 Profile  
 
 Post subject:
PostPosted: Mon Apr 30, 2012 2:17 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 898
Location: cypress, texas
tokumaru, what do you mean by "you dont have SEI in your startup code"? That's the very first thing.

Code:
.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?


Top
 Profile  
 
 Post subject:
PostPosted: Mon Apr 30, 2012 2:53 pm 
Offline
User avatar

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


Top
 Profile  
 
 Post subject:
PostPosted: Mon Apr 30, 2012 3:36 pm 
Offline
User avatar

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


Top
 Profile  
 
 Post subject:
PostPosted: Mon Apr 30, 2012 3:56 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20280
Location: NE Indiana, USA (NTSC)
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.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Apr 30, 2012 4:27 pm 
Offline
User avatar

Joined: Wed Apr 02, 2008 2:09 pm
Posts: 1154
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.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Apr 30, 2012 5:50 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10612
Location: Rio de Janeiro - Brazil
Please post the contents of "daprg-vblank.asm".


Top
 Profile  
 
 Post subject:
PostPosted: Wed May 02, 2012 3:07 pm 
Offline
User avatar

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


Top
 Profile  
 
 Post subject:
PostPosted: Wed May 02, 2012 3:53 pm 
Offline
User avatar

Joined: Wed Apr 02, 2008 2:09 pm
Posts: 1154
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:
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.


Top
 Profile  
 
 Post subject:
PostPosted: Wed May 02, 2012 4:34 pm 
Offline
User avatar

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


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 1451 posts ]  Go to page Previous  1 ... 31, 32, 33, 34, 35, 36, 37 ... 97  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group