It is currently Wed Feb 21, 2018 12:11 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 1417 posts ]  Go to page Previous  1 ... 35, 36, 37, 38, 39, 40, 41 ... 95  Next
Author Message
 Post subject:
PostPosted: Sun May 27, 2012 6:17 pm 
Offline

Joined: Sat Jan 23, 2010 11:41 pm
Posts: 1161
I mostly use that method on another platform where it looks like di:halt (disable interrupts and stop CPU). On the NES there is a problem with IRQ and NMI, indeed - well, if one wants to prevent them, he can use a macro that will disable it before getting into endless loop. Of course this method in general is inferior to emulator-supported breakpoint triggers, but could help in some situations nevertheless.


Top
 Profile  
 
 Post subject:
PostPosted: Sun May 27, 2012 7:14 pm 
Offline
User avatar

Joined: Wed Apr 02, 2008 2:09 pm
Posts: 1090
Quote:
Could I press the Next button with the keyboard some how? Cause then it would be easier to make it through the long loops. Just hold down the button... then it'd go pretty fast, I think. Smile Or maybe I could somehow make it not run loops? Confused

Log, not step. It's a last resort, though. I would try the breakpoint testing first, though.

But, a giant TXT file is created with all the instructions that were run, and you browse that. You can do it with the Trace logger of FCEUX. Log to file. Get the debugger stopped at your reset address. Click start logging on the trace logger. Click run on the debugger. Let it run a couple of frames. Stop logging.

It'll still be trouble getting to the end of loops, but you can page down or use your text editor's scroll bar.

I would ctrl+f $2007 in the log, and see what's being written (if anything). If you can see this code being run, and it updates, I honestly have no idea what's going on. One thing that may be worth trying is either disabling NMI interrupts before writing to $2006, (remember to re enable them), or bit $2002 before writing to $2006.

One other question, do you see your palettes in FCEUX's PPU viewer?


Top
 Profile  
 
 Post subject:
PostPosted: Mon May 28, 2012 10:42 am 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 835
Location: cypress, texas
Kasumi wrote:
One other question, do you see your palettes in FCEUX's PPU viewer?


No... they're just all black... just like the two screens above... just gray.


Top
 Profile  
 
 Post subject:
PostPosted: Mon May 28, 2012 11:33 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10293
Location: Rio de Janeiro - Brazil
Then something is going bad very early on. Put a breakpoint right after the basic initialization (the 2 VBlank wait loops, memory clearing, etc.) and step from there.


Top
 Profile  
 
 Post subject:
PostPosted: Mon May 28, 2012 4:22 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 835
Location: cypress, texas
tokumaru wrote:
unregistered wrote:
Or maybe I could somehow make it not run loops? :?

Make a breakpoint for the address right after the loop, then press "run".

That's brilliant! Thanks so much tokumaru! :D

tokumaru wrote:
Then something is going bad very early on. Put a breakpoint right after the basic initialization (the 2 VBlank wait loops, memory clearing, etc.) and step from there.


Well after doing this I have two ideas.

1.) What does LDA $C3EC,X @ $C3EC = #$00 the = #$00 mean? Does that matter? Sometimes it makes some sense... but lots of times it is just #$00. :?

2.) ... um well I don't remember this o0ne. :( OH NOW I REMEMBER! :D In this code
Code:
                             
0C1CE BD F0 04                  -  lda attributes, x
0C1D1 8D 07 20                    sta $2007
0C1D4 CA                          dex
0C1D5 D0 F7                       bne -
I go through attributes backwards... but I don't care what the attribute bytes say, could be anything. Think I could fix this later? :)


Top
 Profile  
 
 Post subject:
PostPosted: Mon May 28, 2012 4:30 pm 
Offline

Joined: Sat Jan 23, 2010 11:41 pm
Posts: 1161
= $00 is the value that is currently stored at the $c3ec+x.


Top
 Profile  
 
 Post subject:
PostPosted: Mon May 28, 2012 4:35 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 835
Location: cypress, texas
Shiru wrote:
= $00 is the value that is currently stored at the $c3ec+x.
Does is it mean that all the time? STA $2007 = #$00 :) Thanks Shiru!


Top
 Profile  
 
 Post subject:
PostPosted: Mon May 28, 2012 4:37 pm 
Online

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19656
Location: NE Indiana, USA (NTSC)
unregistered wrote:
Shiru wrote:
= $00 is the value that is currently stored at the $c3ec+x.
Does is it mean that all the time? STA $2007 = #$00 :) Thanks Shiru!

That's true for memory (RAM at $0000-$07FF or $6000-$7FFF, or ROM at $8000-$FFFF). But it's not always true for memory-mapped ports where reading has a side effect or ports that can't be read, such as most PPU and APU ports.


Top
 Profile  
 
 Post subject:
PostPosted: Mon May 28, 2012 4:50 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 835
Location: cypress, texas
tepples wrote:
unregistered wrote:
Shiru wrote:
= $00 is the value that is currently stored at the $c3ec+x.
Does is it mean that all the time? STA $2007 = #$00 :) Thanks Shiru!

That's true for memory (RAM at $0000-$07FF or $6000-$7FFF, or ROM at $8000-$FFFF). But it's not always true for memory-mapped ports where reading has a side effect or ports that can't be read, such as most PPU and APU ports.

But is it true for STA $2007 = #$00? Oh maybe thats a PPU port that can't be read... :? So then what does the = #$00 mean for those types? :)


Last edited by unregistered on Mon May 28, 2012 4:56 pm, edited 1 time in total.

Top
 Profile  
 
 Post subject:
PostPosted: Mon May 28, 2012 4:54 pm 
Offline
User avatar

Joined: Wed Apr 02, 2008 2:09 pm
Posts: 1090
It means the designer of the debugger didn't want to make special cases for all those addresses.

It tells you what's in A in the column to the right.

Code:
A:40 X:00 Y:01 S:FC


That's what being written, and what you should pay attention to. I personally ignore the "= whatever" in most cases. It doesn't help when I load. Whatever was loaded is in A in the next row. It also doesn't help when I store. Because I know what I stored, it's in one of the registers, and listed in that column.

Edit: I guess it helps for bit test, and bitwise instructions, but that's pretty rare.

_________________
https://kasumi.itch.io/indivisible


Top
 Profile  
 
 Post subject:
PostPosted: Mon May 28, 2012 5:16 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 835
Location: cypress, texas
Kasumi wrote:
It means the designer of the debugger didn't want to make special cases for all those addresses.


Oh ok thanks Kasumi! :) ...and thank you tepples! :D

Kasumi wrote:
It tells you what's in A in the column to the right.

Code:
A:40 X:00 Y:01 S:FC


That's what being written, and what you should pay attention to. I personally ignore the "= whatever" in most cases. It doesn't help when I load. Whatever was loaded is in A in the next row. It also doesn't help when I store. Because I know what I stored, it's in one of the registers, and listed in that column.

Ooooooooh, I thought it might be writing the $00's instead of what the accumulator had. This is good to know! :D

color of text added in edit


Top
 Profile  
 
 Post subject:
PostPosted: Wed May 30, 2012 3:38 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 835
Location: cypress, texas
When storing the attribute table does each write to $2007 automaticly increment the $2007 write-to counter?


Top
 Profile  
 
 Post subject:
PostPosted: Wed May 30, 2012 3:46 pm 
Offline

Joined: Sat Jan 23, 2010 11:41 pm
Posts: 1161
Autoincrement is for VRAM access in general, it doesn't do distinction between nametable, attributes, palettes or patterns.


Top
 Profile  
 
 Post subject:
PostPosted: Wed May 30, 2012 3:51 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 835
Location: cypress, texas
Shiru wrote:
Autoincrement is for VRAM access in general, it doesn't do distinction between nametable, attributes, palettes or patterns.


Thank you Shiru! :D


Top
 Profile  
 
 Post subject:
PostPosted: Thu May 31, 2012 12:48 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 835
Location: cypress, texas
unregistered wrote:
Kasumi wrote:
One other question, do you see your palettes in FCEUX's PPU viewer?


No... they're just all black... just like the two screens above... just gray.
tokumaru wrote:
Then something is going bad very early on. Put a breakpoint right after the basic initialization (the 2 VBlank wait loops, memory clearing, etc.) and step from there.


What could be going bad? It just ran through the code once and then it started the MainLoop again and is back to the same part of the loop... it'll keep going and going and going and going... :?


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 1417 posts ]  Go to page Previous  1 ... 35, 36, 37, 38, 39, 40, 41 ... 95  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: tepples and 6 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