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

Re: 8x16 and whatever else unreg wants to know

Post by unregistered »

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
Last edited by unregistered on Thu Feb 12, 2015 3:26 pm, edited 1 time in total.
User avatar
rainwarrior
Posts: 8731
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: 8x16 and whatever else unreg wants to know

Post by rainwarrior »

The FCEUX NL file format is documented here:
http://www.fceux.com/web/help/fceux.htm ... ormat.html

I gave an example that converts ca65 label files into NL with a python script here:
viewtopic.php?f=10&t=11151
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 and whatever else unreg wants to know

Post by unregistered »

unregistered[color=#8080FF], on page 81,[/color] wrote:
Kasumi wrote:
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.
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 sprite is really a 16x32 pixel image?

Post by unregistered »

unregistered[color=#FF0080], on page 46,[/color] 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. :)
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 and whatever else unreg wants to know

Post by unregistered »

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: Select all

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

Re: 8x16 and whatever else unreg wants to know

Post by Kasumi »

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

Re: 8x16 and whatever else unreg wants to know

Post by unregistered »

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

Re: 8x16 and whatever else unreg wants to know

Post by Kasumi »

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.
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: Select all


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: Select all

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.
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: Select all


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

Re: 8x16 and whatever else unreg wants to know

Post by unregistered »

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

Re: 8x16 and whatever else unreg wants to know

Post by unregistered »

Just wanted everyone to know... scrolling left works perfectly today!!! :mrgreen: :D It has been a fantastic learning experience! :D
3gengames
Formerly 65024U
Posts: 2284
Joined: Sat Mar 27, 2010 12:57 pm

Re: 8x16 and whatever else unreg wants to know

Post by 3gengames »

Any updates to this? :)
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 and whatever else unreg wants to know

Post by unregistered »

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

Re: 8x16 and whatever else unreg wants to know

Post by unregistered »

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?! :)
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: 8x16 and whatever else unreg wants to know

Post by lidnariq »

Branches can go between 129 bytes forward and 126 bytes backwards, and 197 bytes forward is out of range.
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: 8x16 and whatever else unreg wants to know

Post by tepples »

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: Select all

  ; 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:
Post Reply