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

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! Thank you for all of your help Kasumi! 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!!!

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!

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.

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 currScreensta 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.

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 #$FFsta $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 thelda currScreensta cmpicode, 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.

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 currScreentolda currScreensecsbc #$01sta currScreen

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

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 #$00sta $80;It may break here

lda #$08sta $80;It will never break hereinfiniteloop: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 #$08sta $80;It will never break here

;Add these following two lineslda #$42sta $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 $2FCondition: $2F < $30

Try this:

Code:

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

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

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

Now try this condition on the same code:Break on writes $2FCondition: 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.

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 currScreentolda currScreensecsbc #$01sta 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!! I must go now and finish lumosity for today... thank you for helping me to better understand debugging with conditional breakpoints! Bye Kasumi! (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! )

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! 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! Thank you for asking 3gengames!

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?! :)

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.

Who is online

Users browsing this forum: No registered users and 10 guests

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