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

lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

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

Post by lidnariq »

That might be a function of the debugger you're using; FCEUX's debugger shows the current value of that memory location, so it will show the old value until you single-step past it.

Or I might be completely misunderstanding; if so, sorry.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: new question

Post by tokumaru »

unregistered wrote:WHY IS $002D AT #$00????????? :shock: :?
What were you expecting exactly? At address $002D you used the .dsb statement, which reserves the specified amount of bytes, meaning you reserved one byte at that location. If your program doesn't store anything there, that memory position will remain undefined (RAM contains unpredictable values on power up). Emulators usually initialize the RAM to $00, $FF, or a mix of both, but on actual hardware the contents are unpredictable.

Now, it seems you are trying to initialize variables in RAM with .db statements. That doesn't work. Assemblers generate ROM code, and ROM files don't contain any RAM information, so you can't possibly ask for the assembler to initialize RAM values. This code:

Code: Select all

atttablerownums: .db $00, $20, $40, $60, $80, $a0, $c0, $e0
...will reserve 8 bytes from $002F to $0036, but it will not initialize the values to the ones you specified. To initialize the memory to those values you'll have to manually LDA + STA the values there, the assembler just can't do it.

You'd need something like this to initialize that table like you want:

Code: Select all

	;copy table from ROM to RAM
	ldx #7
-	lda table, x
	sta atttablerownums, x
	dex
	bpl -

;table somewhere in ROM
table: .db $00, $20, $40, $60, $80, $a0, $c0, $e0
And in RAM you'll just have:

Code: Select all

;reserve 8 bytes for the table
atttablerownums .dsb 8
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 »

Thank you thefox, tepples, and bogax for helping me all of us! :D
rainwarrior wrote:You could implement an assert macro that reads or writes to a specific address, executes a bad opcode, or something else that is not dependent on the program counter. This would let you keep the same "assert" breakpoint from build to build.

Alternatively, you could try to auto-generate the .dbg file FCEUX uses based on compile symbols. This would be better, since you could then have asserts without any extra code in the ROM.
An assert macro? I think I don't understand this. It's ok though. Thanks rainwarrior. :)
tokumaru wrote:
unregistered wrote:WHY IS $002D AT #$00????????? :shock: :?
What were you expecting exactly?
THANK YOU SO MUCH tokumaru!! :D I was expecting exactly what I thought wrong about .db statements... they seem to work correctly in another file... but I guess that file is included into RAM... I think i remember that... :)
tokumaru wrote:At address $002D you used the .dsb statement, which reserves the specified amount of bytes, meaning you reserved one byte at that location. If your program doesn't store anything there, that memory position will remain undefined (RAM contains unpredictable values on power up). Emulators usually initialize the RAM to $00, $FF, or a mix of both, but on actual hardware the contents are unpredictable.

Now, it seems you are trying to initialize variables in RAM with .db statements. That doesn't work. Assemblers generate ROM code, and ROM files don't contain any RAM information, so you can't possibly ask for the assembler to initialize RAM values. This code:

Code: Select all

atttablerownums: .db $00, $20, $40, $60, $80, $a0, $c0, $e0
...will reserve 8 bytes from $002F to $0036, but it will not initialize the values to the ones you specified. To initialize the memory to those values you'll have to manually LDA + STA the values there, the assembler just can't do it.

You'd need something like this to initialize that table like you want:

Code: Select all

	;copy table from ROM to RAM
	ldx #7
-	lda table, x
	sta atttablerownums, x
	dex
	bpl -

;table somewhere in ROM
table: .db $00, $20, $40, $60, $80, $a0, $c0, $e0
And in RAM you'll just have:

Code: Select all

;reserve 8 bytes for the table
atttablerownums .dsb 8
tokumaru, you are good at teaching! :D :) : ) Well... I think so. :) Thanks so much! :D
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

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

Post by tokumaru »

unregistered wrote:I was expecting exactly what I thought wrong about .db statements... they seem to work correctly in another file... but I guess that file is included into RAM... I think i remember that... :)
Yeah, some platforms do copy whole programs to RAM (mostly home computers which had significant amounts of RAM in order to load programs from disks or tapes), and in those cases .db does work for initializing variables... On the NES however, that's usually not the case, since programs run mostly from ROM, so be careful with that.
tokumaru, you are good at teaching! :D :) : ) Well... I think so. :) Thanks so much! :D
Heh, I normally suck at teaching stuff, so I'm glad you can understand my explanations.
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 »

lidnariq wrote:That might be a function of the debugger you're using; FCEUX's debugger shows the current value of that memory location, so it will show the old value until you single-step past it.

Or I might be completely misunderstanding; if so, sorry.
Thanks for your help lidnariq. :) FCEUX's debugger is so great!! :D I think I've learned what step-over and step-out do too!
    • Step-over allows you to run the code that the method jsrs to but skip it entirely; it skips to the next line!
    • Step-out let's you step out of a method and it also skips to the same next line that step-over would have skipped to... that's there for people like me who accidentally press step-into too many times. :)
Now debugging is even easier faster! :D Please correct me on anything I've not described correctly... it's just what I've noticed while debugging.

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 »

tokumaru wrote:
tokumaru, you are good at teaching! :D :) : ) Well... I think so. :) Thanks so much! :D
Heh, I normally suck at teaching stuff, so I'm glad you can understand my explanations.
Your explanations have always worked out excellent, for me at least, because you can answer my questions! :D
tokumaru wrote:Now, it seems you are trying to initialize variables in RAM with .db statements. That doesn't work. Assemblers generate ROM code, and ROM files don't contain any RAM information, so you can't possibly ask for the assembler to initialize RAM values. This code:

Code: Select all

atttablerownums: .db $00, $20, $40, $60, $80, $a0, $c0, $e0
...will reserve 8 bytes from $002F to $0036, but it will not initialize the values to the ones you specified. To initialize the memory to those values you'll have to manually LDA + STA the values there, the assembler just can't do it.

You'd need something like this to initialize that table like you want:

Code: Select all

	;copy table from ROM to RAM
	ldx #7
-	lda table, x
	sta atttablerownums, x
	dex
	bpl -

;table somewhere in ROM
table: .db $00, $20, $40, $60, $80, $a0, $c0, $e0
And in RAM you'll just have:

Code: Select all

;reserve 8 bytes for the table
atttablerownums .dsb 8
Where can I find ROM? I'm extreemly confused. :?

Why does your
table: .db $00, $20, $40, $60, $80, $a0, $c0, $e0
seem so unfair... see I can understand why.... !!!!! OK! :D
So would this work?

Code: Select all

lda #$00
sta atttablerownums+0
lda #$20
sta atttablerownums+1
lda #$40
sta atttablerownums+2
lda #$60
sta atttablerownums+3
lda #$80
sta atttablerownums+4
lda #$a0
sta atttablerownums+5
lda #$c0
sta atttablerownums+6
lda #$e0
sta atttablerownums+7
If that would work then I think I'll be able to understand your code better. :)
Last edited by unregistered on Sat Sep 15, 2012 10:13 pm, edited 1 time in total.
3gengames
Formerly 65024U
Posts: 2284
Joined: Sat Mar 27, 2010 12:57 pm

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

Post by 3gengames »

Yeah, basically. It's just a loop that takes the data from the pointer in your program ROM, and puts those bytes after in to the RAM space that you need. RAM needs to have all the data needed to be there put in to it from program and data tables like that, remember that. :)
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

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

Post by tokumaru »

Yes, that would work fine as well. I just used the loop as an example because with larger tables a long chain of LDA + STA would become impractical.
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 »

YES!!!!!!!!!!!!!!!!!!!!

The attribute tables are looking correct now! :D

3gengames wrote:Yeah, basically. It's just a loop that takes the data from the pointer in your program ROM, and puts those bytes after in to the RAM space that you need. RAM needs to have all the data needed to be there put in to it from program and data tables like that, remember that. :)
Ok... thank you 3gengames! :D
tokumaru wrote:Yes, that would work fine as well. I just used the loop as an example because with larger tables a long chain of LDA + STA would become impractical.
Yes, I agree. Thank you tokumaru! :D
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Back to collision detection...

Post by unregistered »

Ok, here is some code I don't know the best way to make it work

Code: Select all

    ;macro increasesxby2andmaybeby32too h********************************************
	; destroys x... kindof...  X is destroyed and then saved at the very end after it gets it's new incremented value.
	; increments x by 2... 
	; else, increments x by 32 if it becomes a multiple of 32...
	; 
	;***********************************************************
    macro increasesxby2or32 h
	  sta $ff
	  pha ;-------------------->
	  ldx h
	  inx  ;always increment by 2
	  inx  ;<--/
	  txa

	  ;lda h
	  and #00011111b ;and then, if tileNum isn't a multiple of 32
	  bne + ;go and be done
	  
	  clc
	  txa
	  adc #00011110b ;#30
	+ sta h
	  tax
	  pla ;<--------------------
    endm ;end of macro increasesxby2or32
This was rewritten today... moving the 2 inx-es to the top so that it would stop constantly incrementing by 32 everytime. It works correctly now until it reaches its first increment by 32... and then it continues to increment by 32 forever...

I know it needs some check that prevents it from incrementing 32 again. That seems like it could be a lot of code... thought maybe one of you could quickly find a grand solution... something that's easily added... but short and to the point.
3gengames
Formerly 65024U
Posts: 2284
Joined: Sat Mar 27, 2010 12:57 pm

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

Post by 3gengames »

I don't get what that's even doing. Either it needs to be incremented by 2 or 32. If it is by 2, just do INX INX. If not, do:

Code: Select all

PHA
TXA
ASL A
ASL A
ASL A
ASL A
ASL A
TAX
PLA
That will multiply X by 32. If you need to test to see if a value is a multiple of 32 (in the A register), do:

Code: Select all

AND #%00011111
And if the 0 condition code is set (BEQ if true) then it is a multiple of 32.

I'm sorry I can't help with THAT piece of code, but that's the best I can do at this hour to maybe give you better ideas to write it. I don't think that's a macro you should be using to often, it's big and seems weird and complex honestly. :)

ETA: Didn't realize you know how to check for the 32 division thing, good job on that. But honestly I don't see where you'd need a program like this...
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

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

Post by tokumaru »

When there's no need to increment 32, aren't you storing the wrong value into h? A is the altered value you used to check if X was a multiple of 32, why would you want to save that? If I'm reading it correctly, it would just be a matter of transformin + sta h into + stx h moving it to after tax.
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 »

Thank you for replying 3gengames! It's a macro because I want it to be a macro... it is only to be used once, you're right. :)
tokumaru wrote:When there's no need to increment 32, aren't you storing the wrong value into h?
Umm.... well... yes I am. :oops:
tokumaru wrote:A is the altered value you used to check if X was a multiple of 32, why would you want to save that?
No I guess me was confused. :? :arrow: :oops: Thank you for seeing that! :D So glad I asked the question!
tokumaru wrote: If I'm reading it correctly, it would just be a matter of transformin + sta h into + stx h moving it to after tax.
...... give me a min...
edit: I did this and it still keeps incrementing by 32 forever... once it becomes a multiple of 32. Here is my code:

Code: Select all

    ;macro increasesxby2andmaybeby32too h********************************************
	; destroys x... kindof.  X is destroyed and then saved at the very end after it gets it's new incremented value.
	; increments x by 2... 
	; else, increments x by 32 if it becomes a multiple of 32...
	; 
	;***********************************************************
    macro increasesxby2or32 h
	  sta $ff
	  pha ;-------------------->
	  ldx h
	  inx  ;always increment by 2
	  inx  ;<--/
	  txa

	  ;lda h
	  and #00011111b ;and then, if tileNum isn't a multiple of 32
	  bne + ;go and be done
	  
	  clc
	  txa
	  adc #00011110b ;#30
	  tax
	+ stx h
	  pla ;<--------------------
    endm ;end of macro increasesxby2or32
good night yall. :)
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: Back to collision detection...

Post by unregistered »

Good morning NesDev.

After rereading your also helpful post 3gengames I might try using that code... though I think my adding 30 takes less cycles than your x32.

If the code is a multiple of 32 I chose to add 30. Thats after always adding 2 in the front.

edit: ok... kindof rewrote this...

Code: Select all

  dontIncrement32 = true;
  if (!dontIncrement32 && it's a mtple of 32) {
    clc    
    adc #32
    dontIncrement32 = true;
  }
  elseif (dontIncrement32) {
    inx
    inx
    dontIncrement32 = false;
  }
Do you see any assembly problems or ways to improve this?
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 »

Kindof rewrote & corrected this pseudocode again... (sorry about the harsh edits to my last post; I failed yall. :( Please trust me again.)

Code: Select all

  haveAdded2 = false;
  
  if (X is a multiple of 32) {
    if (haveAdded2) {

      txa
      clc    
      adc #32
      haveAdded2 = false;  

    }
    else {
      inx
      inx            
      haveAdded2 = true;
    }
    
  } 
  else {

       inx
       inx
       haveAdded2 = true
  }
  tax
Do you see possible improvments or corrections?
Post Reply