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 sprite is really a 16x32 pixel image?

Post by unregistered »

tokumaru wrote:... My advice is: don't chose a mapper just because of WRAM. Any cart, even NROM ones, can have WRAM. If you're gonna use a mapper, pick the simplest one that has the features you need.
Thanks tokumaru! :D Let's say I've chosen a mapper... how can I use it? Is there something I could read to explain 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 »

unregistered wrote:Let's say I've chosen a mapper... how can I use it?
The first thing to do is adjust your iNES header to specify that you're using the mapper (also change other fields in the header that might have something to do with the mapper, such as mirroring and CHR-RAM). Then you adjust your PRG and CHR (if any) banks to reflect the configuration(s) the mapper allows. This includes setting up a fixed bank, making all banks the correct size (PRG banks can be 8KB, 16KB and even 32KB depending on the mapper). Then you have to modify your initialization code to also initialize the mapper (things like setting the mirroring, the size of the banks, switching in the initial banks, etc.). Finally, you should code the routines that will make use of the mapper hardware, so you can call them whenever they're needed.
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: Then you adjust your PRG and CHR (if any) banks to reflect the configuration(s) the mapper allows. This includes setting up a fixed bank, making all banks the correct size (PRG banks can be 8KB, 16KB and even 32KB depending on the mapper).
Ok..well...the PRG has 16 k banks... . 1KB = #$400 right? So then #$1000 = 4KB right? :) :D (Pretty sure that's correct!) ...Sorry ok, back to my PRG banks being 16KB... well, nevermind... um. :?

Code: Select all

      +---------------+
      |     { -1}     |
      +---------------+
What does ^ mean? I spent time reading reading about some of Nintendo's mappers. ...MMC1 is crazy and cool with 5bit registers that can only be written to by writing each bit... 5 writes bit-by-bit I think. ...I also think that I couldn't find the explianation of { -1}.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

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

Post by lidnariq »

unregistered wrote:

Code: Select all

      +---------------+
      |     { -1}     |
      +---------------+
What does ^ mean? I spent time reading reading about some of Nintendo's mappers. ...MMC1 is crazy and cool with 5bit registers that can only be written to by writing each bit... 5 writes bit-by-bit I think. ...I also think that I couldn't find the explianation of { -1}.
That syntax was invented by Disch for his mapper documentation. He used "{-1}" to mean "the last bank".
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 »

The { -1} is indeed a little weird, but I guess the idea is that -1 in binary is always all bits set, so no matter how many bits you use to represent numbers and no matter how many banks there are, -1 is always the highest possible number, and thus, the last bank.
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 lidnariq and thank you so much tokumaru! :D
tokumaru wrote:The { -1} is indeed a little weird, but I guess the idea is that -1 in binary is always all bits set, so no matter how many bits you use to represent numbers and no matter how many banks there are, -1 is always the highest possible number, and thus, the last bank.
That's brilliant! :D
---
Disch must have been an nes game developer... right lidnariq? :) I mean how could someone figure out all Disch's notes? He could have found them in some Nintendo documentation... MMC1 is just insane! :o :shock: :D

And thanks Kasumi! :D I don't know how you found those pages; they are helpful in my quest to understand some a few of Disch's notes.

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 »

Isn't the 6502 a RISC machine? "... an important aspect of RISC machines is that they overlap the execution of instructions." My textbook notes that one of the important aspects of RISC machines is that they overlap the execution of instructions...Mm My textbook is introducing us to Branch Delay Slots. Does the NES have those? :? : )

edit.
unedit.
Last edited by unregistered on Tue Dec 04, 2012 9:56 am, edited 2 times in total.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

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

Post by tepples »

Some RISC architectures have delay slots after load and branch instructions because these instructions send data several stages back in the pipeline, and reordering instructions was believed to be too expensive at the time. But 6502 has no branch delay slots, and neither does ARM. Instead, these architectures stall until the load or branch is complete before beginning the next instruction. Your textbook may be old, and that statement may have been written back when MIPS was the new hotness.
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 tepples! :D Wow it is copywriterighted 1993. And I'm not allowed to quote this text... so... well, I'll have to edit my earlier quote away... somehow. Boooo to them not allowing anyone to quote this book without the pr5ior written permission of the publish-people. :x I didn't know this was so old :shock: ...my other textbook from this class was copywriterighted 2004... and it is so much better, IMO. I don't know what MIPS was. :oops:
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

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

Post by tepples »

Appropriately short quotations are considered "fair use of a copyrighted work".
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 »

tepples wrote:Appropriately short quotations are considered "fair use of a copyrighted work".
:oops:
Thanks tepples. :)
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 wrote:
tokumaru wrote:What tepples said. We only have 10 different digits for representing numbers (0 to 9) but that doesn't mean it's impossible to count to 10: if we use more places for digits, we can represent bigger numbers.

With one digit we can only represent 10 different numbers (0 to 9), but with one more digit we have a total of 100 combinations (0 to 99: each new digit multiplies the number of possible combinations by 10). With bytes it's the same thing. A single byte can only represent 256 different numbers (0 to 255), but if we use a second byte we get a total of 65536 possible combinations (0 to 65535: each new byte multiplies the number of possible combinations by 256).

16, 32 and 64-bit CPUs make the whole thing easier (and faster) by manipulating multiples bytes at a time, while 8-bit CPUs have to do it byte by byte, but they can still perform math with big numbers.
This is so excellent and helpful to me too tokumaru... THANK YOU!!! :D
Well... so now I am wondering how I could use a number like 425? I am trying to make it clear that I want nametable $2000 to be replaced when I reach the last 3rd of the second nametable $2400. Can I use the number 425 for that? :? I'm confused because I don't understand how our 8bit NES could think like a future 16bit machine would... you know? :? :?
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 »

An 8-bit CPU can do anything a 16-bit CPU can, it will just do it less efficiently (i.e. slower and with more instructions, because you have to handle 1 byte at a time). 425 in hex is $01A9, so $01 is the high byte, and $A9 is the low byte.
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 »

tepples wrote:You can't fit a 16-bit number in one byte, but you can fit it in two. Here's how to do 16 bit addition, using the example of 508 + 8 = 516 ($01FC + $0008 = $0204):

Code: Select all

position_hi = $0701
position_lo = $0700

  ; set the position to $01FC
  lda #$01
  sta position_hi
  lda #$fc
  sta position_lo

  ; now add eight ($0008) to this position
  clc
  lda #$08  ; add the low byte first
  adc position_lo
  sta position_lo
  lda #$00
  adc position_hi
  sta position_hi
When you add two 8-bit numbers and the result is more than 256, the CPU subtracts 256 and turns on the carry flag. The carry flag tells the CPU to add one extra the next time it adds anything, just as you'd carry the 1 when adding multi-digit base 10 numbers in first grade. Most of the time, an addition will start with the carry off; that's what the clc does. (Clearing a flag means turning it off; setting means turning it on.)
Um... so are we susposed to declare low values before high values?? Why is position_hi before position_lo?

I'm under some trouble with this code...

Code: Select all

;6502 Simulator
 .START $1000
 .ORG $0000
 
  .DB "ABC"

position_lo .DS 1
position_medium .ds 1
position_medihi .DS 1
position_hi .ds 1
oX .ds 4

 
 .ORG $1000
 
    

  ; set the position to $01FC
  lda #$01
  sta position_hi
  LDA #$01
  sta position_medihi
  LDA #$00
  sta position_medium
  LDA #$02
  STA position_lo
  
  LDa #$01
  STa oX+3
  LDa #$01
  STa oX+2
  lda #$00
  sta oX+1
  lda #$02
  STA oX+0
    

  ; now subtract eight (#$0008) from this position
  sec 
  lda position_lo  ; subtract from the low byte first
  sbc #$08
  sta position_lo
  LDA position_medium
  SBC #$00
  STA position_medium
  LDA position_medihi
  SBC #$00
  sta position_medihi
  LDA position_hi
  sbc #$00
  STA position_hi
  
  ; now subtract eight (#$0008) from this position
  sec 
  lda oX+0  ; subtract from the low byte first
  sbc #$08
  sta oX+0
  LDA oX+1
  SBC #$00
  STA oX+1
  LDA oX+2
  SBC #$00
  sta oX+2
  LDA oX+3
  sbc #$00
  STA oX+3
Ok well that is my code I've explored in the 6502 Simulator from tokumaru. The only thing is that at the top of it I had to reverse this code.

position_hi .DS 1
position_medihi .ds 1
position_medium .DS 1
position_lo .ds 1


I started with that because tepples made his code up there very tricky... I think... :? because he started with

Code: Select all

position_hi = $0701
position_lo = $0700
and that has been confusing me. Should position_lo be above position_hi? :? :) It's ok, cause I feel that position_lo is above position_hi. I want to help others not to have the confusion that I had. : )
Post Reply