Thanks tokumaru! Let's say I've chosen a mapper... how can I use it? Is there something I could read to explain this?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.
8x16 and whatever else unreg wants to know
Moderator: Moderators
-
- Posts: 1318
- Joined: Thu Apr 23, 2009 11:21 pm
- Location: cypress, texas
Re: 8x16 sprite is really a 16x32 pixel image?
Re: 8x16 sprite is really a 16x32 pixel image?
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 wrote:Let's say I've chosen a mapper... how can I use it?
-
- Posts: 1318
- Joined: Thu Apr 23, 2009 11:21 pm
- Location: cypress, texas
Re: 8x16 sprite is really a 16x32 pixel image?
Ok..well...the PRG has 16 k banks... . 1KB = #$400 right? So then #$1000 = 4KB right? (Pretty sure that's correct!) ...Sorry ok, back to my PRG banks being 16KB... well, nevermind... um.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).
Code: Select all
+---------------+
| { -1} |
+---------------+
Re: 8x16 sprite is really a 16x32 pixel image?
That syntax was invented by Disch for his mapper documentation. He used "{-1}" to mean "the last bank".unregistered wrote: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}.Code: Select all
+---------------+ | { -1} | +---------------+
Re: 8x16 sprite is really a 16x32 pixel image?
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.
-
- Posts: 1318
- Joined: Thu Apr 23, 2009 11:21 pm
- Location: cypress, texas
Re: 8x16 sprite is really a 16x32 pixel image?
Thank you lidnariq and thank you so much tokumaru!
---
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!
And thanks Kasumi! I don't know how you found those pages; they are helpful in my quest to understandsome a few of Disch's notes.
edit.
That's brilliant!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.
---
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!
And thanks Kasumi! I don't know how you found those pages; they are helpful in my quest to understand
edit.
-
- Posts: 1318
- Joined: Thu Apr 23, 2009 11:21 pm
- Location: cypress, texas
Re: 8x16 sprite is really a 16x32 pixel image?
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.
edit.
unedit.
Last edited by unregistered on Tue Dec 04, 2012 9:56 am, edited 2 times in total.
Re: 8x16 sprite is really a 16x32 pixel image?
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.
-
- Posts: 1318
- Joined: Thu Apr 23, 2009 11:21 pm
- Location: cypress, texas
Re: 8x16 sprite is really a 16x32 pixel image?
Thank you tepples! 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. I didn't know this was so old ...my other textbook from this class was copywriterighted 2004... and it is so much better, IMO. I don't know what MIPS was.
Re: 8x16 sprite is really a 16x32 pixel image?
Appropriately short quotations are considered "fair use of a copyrighted work".
-
- Posts: 1318
- Joined: Thu Apr 23, 2009 11:21 pm
- Location: cypress, texas
Re: 8x16 sprite is really a 16x32 pixel image?
tepples wrote:Appropriately short quotations are considered "fair use of a copyrighted work".
Thanks tepples.
-
- Posts: 1318
- Joined: Thu Apr 23, 2009 11:21 pm
- Location: cypress, texas
Re: 8x16 sprite is really a 16x32 pixel image?
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?unregistered wrote:This is so excellent and helpful to me too tokumaru... THANK YOU!!!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.
Re: 8x16 sprite is really a 16x32 pixel image?
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.
-
- Posts: 1318
- Joined: Thu Apr 23, 2009 11:21 pm
- Location: cypress, texas
Re: 8x16 sprite is really a 16x32 pixel image?
Um... so are we susposed to declare low values before high values?? Why is position_hi before position_lo?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):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.)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
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
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