Re: 8x16 sprite is really a 16x32 pixel image?
Posted: Fri Dec 14, 2012 9:34 pm
Thank you tokumaru and 3gengames!
NES Development Forums
https://forums.nesdev.org/
I was talking about generic register writes, but yeah, since the MMC1 only takes 1 bit of data at a time you have to make multiple writes.3gengames wrote:It's not right, you have to shift and store it 5 times, remember that!
tokumaru wrote:I was talking about generic register writes, but yeah, since the MMC1 only takes 1 bit of data at a time you have to make multiple writes.3gengames wrote:It's not right, you have to shift and store it 5 times, remember that!
I think unregistered is REALLY confused about how bankswitching works... Let me try to explain it. The 6502 can only see 64KB of memory, because it only has 16 address lines (2^16 = 65536). Only half of that is used to access the ROM, because the other half is used to access RAM and internal registers. 32KB of ROM is not much, and as games became more complex they needed more space.
You can't make the NES see more memory than the 6502 allows, but you can mix and match smaller banks of ROM and make them visible in the available memory range. You'll still see only 32KB at any given time, but you can map different parts of a bigger ROM into those 32KB. Each mapper has different bank sizes and different rules, but one thing that doesn't change is that you need to tell the mappers which banks to put where, and you do that by writing to their registers.
When you try to write to PRG-ROM ($8000-$FFFF) the mapper intercepts the writes and redirects them to one of its registers, depending on which address was used for the write. Simple mappers (CNROM, UxROM, AxROM, BxROM, etc.) only have one register, so you can access it by writing to any address between $8000-$FFFF. Mappers with more registers break up that space into multiple ranges where the different registers can be accessed.
Thank you so much tokumaru!!tokumaru wrote:I think unregistered is REALLY confused about how bankswitching works... Let me try to explain it.
If we use mmc4 which registers does a sprite file use? 3 and 4? It wouldn't want to switch between the sprite and the background file when one of the tiles from rows e and d are used, would it? Does 0fd0 - 0fdf refer to row d of the 4k chr file? If we want to use the same chr file in register 1 and tile d1 is read, does it create a problem with latch 0... or does it stay with the same chr file?tokumaru wrote:When you try to write to PRG-ROM ($8000-$FFFF) the mapper intercepts the writes and redirects them to one of its registers, depending on which address was used for the write. Simple mappers (CNROM, UxROM, AxROM, BxROM, etc.) only have one register, so you can access it by writing to any address between $8000-$FFFF. Mappers with more registers break up that space into multiple ranges where the different registers can be accessed.
Thank you 3gengames!3gengames wrote:Pick MMC3 for IRQ's, or MMC1/UNROM and do sprite 0 hit to find where you need to swap the graphics, as MMC4 isn't easy to prototype on as there's only one game that uses it, and you really don't need it's features unless you're making a game like they did. Basically what you do is do a sprite 0 hit or NMI, then switch the graphics to the appropriate bank for the next scanline to use in the status bar or something.
The background can only use tiles from one of the pattern tables at a time... If you need more than 256 tiles for the background you either have to use the MMC5 (not recommended) or split the screen (with an IRQ or sprite 0 hit) and tell the background to start using tiles from the other pattern table.unregistered wrote:1.)If we use 8kb CHR files... how do you select a tile in the second 4kb half?
You should stop thinking about "files". You use files to build the ROM, but once the ROM is ready it's just a bunch of bytes, and the NES has no concept of files whatsoever.When using MMC1 would it be hard (too slow)... for the cpu to use both 4 and 8 kb files?
Yes, I think so. Thanks 3gengames.3gengames wrote:On MMC1 you can just write the lower or higher graphics page register to the 4KB graphic page you want, swapping it all out. And as for no mapper using another tile from the opposite side, you can't on the background. You have to either switch the table the graphics use, or swap in the other graphics. Make sense?
This helped me to better understand what 3gengames wrote! Thanks tokumaru!tokumaru wrote:The background can only use tiles from one of the pattern tables at a time... If you need more than 256 tiles for the background you either have to use the MMC5 (not recommended) or split the screen (with an IRQ or sprite 0 hit) and tell the background to start using tiles from the other pattern table.unregistered wrote:1.)If we use 8kb CHR files... how do you select a tile in the second 4kb half?
Excellent!! Now I'm fixed away from my past thoughts; thank you so much tokumaru!tokumaru wrote:You should stop thinking about "files". You use files to build the ROM, but once the ROM is ready it's just a bunch of bytes, and the NES has no concept of files whatsoever.When using MMC1 would it be hard (too slow)... for the cpu to use both 4 and 8 kb files?
The MMC1 doesn't do anything to help with using more than 256 tiles for the background. It has the capability of bankswitching 4KB or 8KB chunks, but that doesn't affect what the NES can use for backgrounds.
Ok I added this code at the end of my fixed PRG bank:Kasumi[color=#40FFFF], on page 56,[/color] wrote:Look it up by name on the wiki.
http://wiki.nesdev.com/w/index.php/Programming_MMC1
http://wiki.nesdev.com/w/index.php/Programming_UNROM
etc.
Code: Select all
.pad $FFF0
reset_stub:
sei
ldx #$FF
txs ; set the stack pointer
stx $8000 ; reset the mapper
jmp reset ; must be in $C000-$FFED
.word vblank, reset_stub, irq
Code: Select all
.org $8000 ;empty switchable PRG bank
.pad $BFF0
reset_stub:
sei
ldx #$FF
txs ; set the stack pointer
stx $8000 ; reset the mapper
jmp reset ; must be in $C000-$FFED
.word vblank, reset_stub, irq
[color=#00BFFF]([/color][url=http://wiki.nesdev.com/w/index.php/Programming_MMC1][color=#00BFFF]this page...[/color][/url][color=#00BFFF])[/color] wrote:To make sure your code works on all MMC1 revisions, put the following code in the last 16 bytes of each 16384 byte bank. (Barbie uses almost identical code.)Code: Select all
reset_stub: sei ldx #$FF txs ; set the stack pointer stx $8000 ; reset the mapper jmp reset ; must be in $C000-$FFED .addr nmiHandler, reset_stub, irqHandler
Thank you 3gengames!!3gengames wrote:I'd say make it a macro if you can. I myself just made 16 global labels, numbered MMC1Boot00-MMC1Boot15 so it wouldn't duplicate. And you could also make it JMP [$FFFC], just to do it. But that's perfectly fine, but you can either make 16 global labels or a macro, both options will get you around that.
Thanks tokumaru!! I have created my 16 files... each one has that code at the bottomtokumaru wrote:I use temporary labels (add a "+" or "-" to the beginning, depending on the location of the code that uses those labels) for labels I must repeat in various banks.
Code: Select all
;PRG bank 15
.org $8000
.pad $BFF0 ;Fills bank15 with 0s.
reset_stub15:
sei
ldx #$FF
txs ; set the stack pointer
stx $8000 ; reset the mapper
jmp reset ; must be in $C000-$FFED
.word vblank, reset_stub15, irq
Code: Select all
.org $8000 ;empty switchable PRG bank
.include "mmc1_bank0.asm" if switchable bank = 0
.include "mmc1_bank1.asm" if switchable bank = 1
...etc
.include "mmc1_bank15.asm" if switchable bank = 15