It is currently Wed Oct 18, 2017 1:35 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 1378 posts ]  Go to page Previous  1 ... 85, 86, 87, 88, 89, 90, 91, 92  Next
Author Message
PostPosted: Thu Feb 12, 2015 1:33 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 799
Location: cypress, texas
tepples wrote:
To enable symbolic debugging, you need to make a .nl (name list) file. There should be tools to turn the list of exported symbols produced by an assembler into a .nl file; if not, you could always whip one up in JScript or Python.
Ok, so I went back and reread that "Symbolic Debugging" part again and I noticed, thanks to you, the nl link and I clicked it and read it and now I have 17 extra .nl files. It said to make one for each bank and our game has 16 banks... and then there is the ram nl file... I must be going insane... it's just too many files. But, they are created now and when I right click and type "a" all the text gets highlighted and nothing happens again. And, I shut down fceux and reopened it all over again and I'm still confused. :? Do I have to get an nl file created by a tool?

edit: I think I should add that I've worked myself out of ideas to try... other than creating my nl files with a tool. And I also want to add rainwarrior's link from
rainwarrior, here, wrote:
2. Conditional breakpoints.

This lets you set a breakpoint that also has a condition.
See: FCEUX debugger guide


Last edited by unregistered on Thu Feb 12, 2015 3:26 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Thu Feb 12, 2015 3:07 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5718
Location: Canada
The FCEUX NL file format is documented here:
http://www.fceux.com/web/help/fceux.html?NLFilesFormat.html

I gave an example that converts ca65 label files into NL with a python script here:
http://forums.nesdev.com/viewtopic.php?f=10&t=11151


Top
 Profile  
 
PostPosted: Mon Apr 06, 2015 3:42 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 799
Location: cypress, texas
unregistered, on page 81, wrote:
Kasumi wrote:
Quote:
I recieved the exact same answer though without that and #00000111b


Indeed, you don't need "and #00000111b" at all. If I have a byte like this: "76543210" and my goal is to get this from it "21000000", the asl instructions alone will do that. bits 7, 6, 5, 4, and 3 will be shifted out so it doesn't matter what they are. 0s will be shifted in.
Your mind is much better than mine... but mine is being trained at lumosity.com and it will get better. :)
Now I understand this well... lumosity.com, indeed, has helped my brain! :mrgreen: Thank you for all of your help Kasumi! :D I've been working on the game like it's my job... at least six hours a day four days a week while slowly moving away from Schizophrenia. Recently, I've made much progress not asking questions and attempting to solve things myself. Now there is much improved character movement... perfect scrolling right... once I finish working on the character movement it will be time to attempt scrolling left. It's growing!!! :D :mrgreen:

edit.


Top
 Profile  
 
PostPosted: Sat Apr 25, 2015 4:53 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 799
Location: cypress, texas
unregistered, on page 46, wrote:
tokumaru wrote:
Every time you use the debugger with a game an annoying .deb file is created. I find that really annoying when I'm developing, so I added a command to delete .deb files in the batch file that assembles the project.
Shiru wrote:
The same here.
Ha ha. That's brilliant! :D
Um well, I downloaded the most newest FCEUX program a few days ago and I just discovered that there is a box that's checked now next to "deb files" at the bottom of the debugger screen. So maybe that will solve the problem Shiru and tokumaru. Just wanted to let yall know. :)


Top
 Profile  
 
PostPosted: Tue Jun 16, 2015 5:18 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 799
Location: cypress, texas
Ok yall I need some debugging help...

I've been using FCEUX 2.2.2 for debugging for a while now... today I created a breakpoint for writes to CPU memory $0047 with a condition $47 != $64. So far I've figured out that writes do not include dec $0047 or inc $0047. WHY NOT??!? :? :( And it didn't even break when I turned around and headed left and $0047 decreased instantly from 5 to 2. ... ok $0047 is currScreen and $0064 is cmpi... and that will help you with this code I added to the very beginning of my game loop...
Code:
lda currScreen
sta cmpi

That code runs every frame... this was my solution because the condition $47 <> $64 didn't work... it was an "invalid" condition. (You can visit page 56 of this thread to see what <> means. :)) Please help me if you can... I'm really confused... I just want to find out why currScreen decreases instantly from 5 to 2. :?


Top
 Profile  
 
PostPosted: Wed Jun 17, 2015 5:13 am 
Offline
User avatar

Joined: Wed Apr 02, 2008 2:09 pm
Posts: 1019
A break on writes does include dec and inc. (At least in my admittedly old version of FCEUX.) Try it without the condition first to see if this is true.

The condition applies before the write takes effect, as far as I can tell.

I have a break on writes on $6F, with the condition that $6F == #FF. $6F is made #$00 right when the game starts. Later in my code, I have this:

lda #$FF
sta $6F.

When the debugger breaks, $6F is ALREADY equal to #$FF. It doesn't break when $6F still has a value of #$00, and this code makes it #$FF.

In your case, this means the write that causes $47 to be different from $64 will not be caught. If there's another write AFTER that, that one will get caught. Probably leaving you with the wrong impression. If there is only ever one update to currScreen between the
lda currScreen
sta cmpi
code, it's impossible for it to break using that condition.

That's admittedly really, really annoying if you do use dec to change it. What I typically do is break on writes with the value I know to be wrong in A, X, or Y. In your case, you want to know how currScreen becomes 2.

So normally I'd do break on writes for currScreen, A == #02 || X == #02 || Y == #02

This works even though the break is BEFORE that value is written. Because you're checking the value to be written instead. So if currScreen is #05, and it breaks on sta currScreen that means running that STA will cause currScreen to be #02, because #$02 is what's in A. Again, know that you'd never catch that write with the condition currScreen == #02, because that will never break when currScreen was something different than #02 before the write happened.

If it is a dec that's causing your problem, you could break on the value above the wrong one.

break on writes currScreen, currScreen == #03.

If it breaks on a dec, that means currScreen is about to be #02.

or

break on writes currScreen, currScreen == #01

to catch an inc that might be responsible. Or convert all your
dec currScreen
to
lda currScreen
sec
sbc #$01
sta currScreen

just for this check.

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


Top
 Profile  
 
PostPosted: Wed Jun 17, 2015 6:53 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 799
Location: cypress, texas
Kasumi wrote:
A break on writes does include dec and inc. (At least in my admittedly old version of FCEUX.) Try it without the condition first to see if this is true.
I can't do that because every time draw_RAMbuffers runs it stores the x register into currScreen. And draw_RAMbuffers runs each time left or right is pressed on controller 1. So without the condition it would break every time I pressed left or right... which would be all the time since I'm trying to complete scrolling left successfully right now.

...I'm going to try to understand the rest of this post... not understanding it much right now. I'm sorry this reply is so late today. Well... here I go...
Kasumi wrote:
The condition applies before the write takes effect, as far as I can tell.
Ok... well, I gather this is the central point of your post... but, I disagree because - well, I haven't experienced a problem with this condition... it breaks every time valid_left becomes less than visible_left (valid_left and visible_left come from tepples at the bottom of page 69)... the condition is $2F < $30... and it works... every time valid_left becomes less than visible_left, it breaks. So maybe your theory only applies to == and != conditions... or maybe I still am not understanding what you said. I can't spend much more time with this tonight... I'm done with my 6 hours right now... must go play the rest of my lumosity for today. Thank you so much for your response... hope to understand your theory better sometime tomorrow. Goodnight Kasumi. :)
Matthew

p.s. I'll finish this reply sometime tomorrow.


Top
 Profile  
 
PostPosted: Wed Jun 17, 2015 7:59 pm 
Offline
User avatar

Joined: Wed Apr 02, 2008 2:09 pm
Posts: 1019
unregistered wrote:
I can't do that

Sure you can! It says try just that first because it lets you see for yourself whether dec/inc really will cause a break. If it does work for that, the problem is your condition. (That must be why it wasn't breaking for inc/dec, but why take my word for it?) It's part of a process. Always break the thing not working as expected to the smallest possible piece.

Quote:
Ok... well, I gather this is the central point of your post... but, I disagree because - well, I haven't experienced a problem with this condition... it breaks every time valid_left becomes less than visible_left (valid_left and visible_left come from tepples at the bottom of page 69)... the condition is $2F < $30... and it works... every time valid_left becomes less than visible_left, it breaks. So maybe your theory only applies to == and != conditions... or maybe I still am not understanding what you said.

I have no information about valid_left and visible_left or how you're using them, but what I stated is provably true. Try this:

Break on writes $80. Condition: $80 == #08
Code:

reset:
;Intialization junk. Or not! Shouldn't matter just for this test.

lda #$00
sta $80;It may break here

lda #$08
sta $80;It will never break here
infiniteloop:
inc $00;This allows you to see whether it has broken or not with the hex editor.
;if you see the value spinning, it hasn't broken.
jmp infiniteloop


IRQ:
NMI:
rti
.org $FFFA         
.dw NMI            
.dw reset   
.dw IRQ   


Now try this small change:

Code:
lda #$08
sta $80;It will never break here

;Add these following two lines
lda #$42
sta $80;It will always break here

infiniteloop:
inc $00;This allows you to see whether it has broken or not with the hex editor.
;if you see the value spinning, it hasn't broken.
jmp infiniteloop


I did try this exact code on FCEUX 2.2.2, and it works exactly as stated. This is what I mean by it will only pick up the second write. It's made zero in the beginning. Then it is changed to #$08, the value you are actually checking for. This is the first write. This write is not broken on. Only a write when the variable ALREADY HAS the value you're checking for will be detected with that particular method.
Quote:
the condition is $2F < $30... and it works... every time valid_left becomes less than visible_left, it breaks.

I can write some code where it doesn't break when valid_left is less than visible_left. Or at least, doesn't break like I think you're expecting it to.

Break on writes $2F
Condition: $2F < $30

Try this:
Code:

lda #$80
sta $30
sta $2F;won't break because they're equal.


lda #$00
sta $2F;0 < 128, but it won't break here for the reason I stated.

lda #$FF
sta $2F;It would break here, though.


Now try this condition on the same code:
Break on writes $2F
Condition: A < $30

That condition will break when I think you'd want it to.

So if you haven't experienced a problem, it's either that I'm misunderstanding what you're expecting from these breakpoints, or the breaks you're getting are actually not the writes that are making the changes you're looking for.

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


Top
 Profile  
 
PostPosted: Thu Jun 18, 2015 7:21 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 799
Location: cypress, texas
Kasumi wrote:
What I typically do is break on writes with the value I know to be wrong in A, X, or Y. In your case, you want to know how currScreen becomes 2.

So normally I'd do break on writes for currScreen, A == #02 || X == #02 || Y == #02

This works even though the break is BEFORE that value is written. Because you're checking the value to be written instead. So if currScreen is #05, and it breaks on sta currScreen that means running that STA will cause currScreen to be #02, because #$02 is what's in A. Again, know that you'd never catch that write with the condition currScreen == #02, because that will never break when currScreen was something different than #02 before the write happened.

If it is a dec that's causing your problem, you could break on the value above the wrong one.

break on writes currScreen, currScreen == #03.

If it breaks on a dec, that means currScreen is about to be #02.

or

break on writes currScreen, currScreen == #01

to catch an inc that might be responsible. Or convert all your
dec currScreen
to
lda currScreen
sec
sbc #$01
sta currScreen

just for this check.
Ok I agree with you, now, I see that break on writes to currScreen using a condition currScreen == 2 will only break on a write when currScreen is already 2 (before the write)... and then breaking on writes to currScreen with the condition A == #02 || X == #02 || Y == #02 will break when currScreen is about to equal #02 because A, for instance, is already equal to #02. That makes sense to me... now I'm going to check to see if I'm correct... yeah, I think I got it now... I'm going to reread your post following this one again.... yes, THANK YOU SO VERY MUCH KASUMI!! :D I must go now and finish lumosity for today... thank you for helping me to better understand debugging with conditional breakpoints! Bye Kasumi! :D (Oh yes... valid_left and visible_left are both from a post by tepples on page 69 of this thread... you know, if you wanted to understand what I'm using them for. They are really helpful for me! :))


Top
 Profile  
 
PostPosted: Fri Sep 11, 2015 4:32 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 799
Location: cypress, texas
Just wanted everyone to know... scrolling left works perfectly today!!! :mrgreen: :D It has been a fantastic learning experience! :D


Top
 Profile  
 
PostPosted: Sat Oct 10, 2015 10:53 pm 
Offline
Formerly 65024U

Joined: Sat Mar 27, 2010 12:57 pm
Posts: 2257
Any updates to this? :)


Top
 Profile  
 
PostPosted: Tue Oct 20, 2015 9:30 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 799
Location: cypress, texas
3gengames wrote:
Any updates to this? :)
Yes ok well yeah there have been updates to this... I'm working on character movement again right now... it's going good... redoing what I did before; it's a slow process but I think I'm almost done! :mrgreen: And do not worry, if this fails to work it is easy to return to a backup. I had this idea and it seems to be a good idea so far... the character is kind of hard to control right now but I think it will improve! My brain is doing better these days! Lumosity score is improving! :mrgreen: Thank you for asking 3gengames! :D


Top
 Profile  
 
PostPosted: Mon Mar 20, 2017 1:21 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 799
Location: cypress, texas
I'm using asm6 and trying to build our nes file, but there's an error "*** Branch out of range." underneath my bpl @end at address 0C301. @end is at address 0C3C5. How is that out of range? The assembly listed for 0C301 is 10 C2. That's correct... 0C303 + C2 == 0C3C5. I bet that error is there because of something else in my code; y'all have solved this problem before for me, I think... and I bet someone will ask for a piece of code. Sorry, I promised my sister to not post code anymore. I'll figure this out myself... maybe asm6 needs upgrading?! :)


Top
 Profile  
 
PostPosted: Mon Mar 20, 2017 1:35 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6277
Location: Seattle
Branches can go between 129 bytes forward and 126 bytes backwards, and 197 bytes forward is out of range.


Top
 Profile  
 
PostPosted: Mon Mar 20, 2017 1:51 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19096
Location: NE Indiana, USA (NTSC)
That's 129 bytes forward or 126 bytes backward from the address of the branch instruction's opcode. The apparent imbalance is because the offset is actually measured from the address of the opcode that would be executed if the branch were not taken, and it has the typical range of an 8-bit signed integer: 127 bytes forward or 128 bytes backward.

The usual way to work around the 6502 branch distance limit is to use the opposite branch across a JMP.
Code:
  ; This produces a range error.
  bpl @toofar
  ; 190+ bytes of whatever
  @toofar:

  ; But this works.
  bmi @no_toofar
    jmp @toofar
  @no_toofar:
  ; 190+ bytes of whatever
  @toofar:


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 1378 posts ]  Go to page Previous  1 ... 85, 86, 87, 88, 89, 90, 91, 92  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 9 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