It is currently Mon Aug 13, 2018 11:43 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 1451 posts ]  Go to page Previous  1 ... 45, 46, 47, 48, 49, 50, 51 ... 97  Next
Author Message
PostPosted: Fri Sep 14, 2012 5:13 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7380
Location: Seattle
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.


Top
 Profile  
 
 Post subject: Re: new question
PostPosted: Fri Sep 14, 2012 5:17 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10700
Location: Rio de Janeiro - Brazil
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:
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:
   ;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:
;reserve 8 bytes for the table
atttablerownums .dsb 8


Top
 Profile  
 
PostPosted: Fri Sep 14, 2012 9:04 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 908
Location: cypress, texas
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:
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:
   ;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:
;reserve 8 bytes for the table
atttablerownums .dsb 8

tokumaru, you are good at teaching! :D :) : ) Well... I think so. :) Thanks so much! :D


Top
 Profile  
 
PostPosted: Fri Sep 14, 2012 9:50 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10700
Location: Rio de Janeiro - Brazil
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.

Quote:
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.


Top
 Profile  
 
PostPosted: Sat Sep 15, 2012 9:26 am 
Offline
User avatar

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


Top
 Profile  
 
PostPosted: Sat Sep 15, 2012 9:52 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 908
Location: cypress, texas
tokumaru wrote:
Quote:
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:
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:
   ;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:
;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:
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.

Top
 Profile  
 
PostPosted: Sat Sep 15, 2012 10:12 pm 
Offline
Formerly 65024U

Joined: Sat Mar 27, 2010 12:57 pm
Posts: 2262
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. :)


Top
 Profile  
 
PostPosted: Sat Sep 15, 2012 11:20 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10700
Location: Rio de Janeiro - Brazil
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.


Top
 Profile  
 
PostPosted: Wed Sep 19, 2012 4:25 pm 
Offline
User avatar

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


Top
 Profile  
 
PostPosted: Thu Sep 20, 2012 9:38 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 908
Location: cypress, texas
Ok, here is some code I don't know the best way to make it work
Code:
    ;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.


Top
 Profile  
 
PostPosted: Thu Sep 20, 2012 9:59 pm 
Offline
Formerly 65024U

Joined: Sat Mar 27, 2010 12:57 pm
Posts: 2262
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:
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:
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...


Top
 Profile  
 
PostPosted: Thu Sep 20, 2012 10:07 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10700
Location: Rio de Janeiro - Brazil
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.


Top
 Profile  
 
PostPosted: Thu Sep 20, 2012 10:50 pm 
Offline
User avatar

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


Top
 Profile  
 
PostPosted: Fri Sep 21, 2012 8:18 am 
Offline
User avatar

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


Top
 Profile  
 
PostPosted: Fri Sep 21, 2012 2:05 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 908
Location: cypress, texas
Kindof rewrote & corrected this pseudocode again... (sorry about the harsh edits to my last post; I failed yall. :( Please trust me again.)
Code:
  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?


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 1451 posts ]  Go to page Previous  1 ... 45, 46, 47, 48, 49, 50, 51 ... 97  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: Sumez and 1 guest


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