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 »

Thank you tokumaru and 3gengames! :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 »

3gengames wrote:It's not right, you have to shift and store it 5 times, remember that!
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.

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.
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:
3gengames wrote:It's not right, you have to shift and store it 5 times, remember that!
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.

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.
Ttokumaru, thanks so much for all this info! I can't reply more until Monday.

edit: Sorry tokumaru.
Last edited by unregistered on Mon Dec 17, 2012 10:11 pm, edited 1 time in total.
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:I think unregistered is REALLY confused about how bankswitching works... Let me try to explain it.
Thank you so much tokumaru!! :D
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.
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?
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 »

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.
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 »

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.
Thank you 3gengames! :D

---
Ok here are 2 more questions:
1.)If we use 8kb CHR files... how do you select a tile in the second 4kb half? NESst uses 00 for the first tile of both A and B.
2.)When using MMC1 would it be hard (too slow)... for the cpu to use both 4 and 8 kb files?
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 »

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? :)
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:1.)If we use 8kb CHR files... how do you select a tile in the second 4kb half?
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.

Sprites can use patterns from both pattern tables if they're set to the size of 8x16 pixels.
When using MMC1 would it be hard (too slow)... for the cpu to use both 4 and 8 kb files?
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.

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.
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 »

How am I to use the 16kb prg switching part of the memory managenent controller successfully? I understand how the switching works thanks to Matthew J. Richey's document! I am missing knowledge of how to create my .nes rom file program to use a MMC. How do I prepare my code to be used in bank 2 or bank 3?
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 »

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? :)
Yes, I think so. Thanks 3gengames. :)
tokumaru wrote:
unregistered wrote:1.)If we use 8kb CHR files... how do you select a tile in the second 4kb half?
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.
This helped me to better understand what 3gengames wrote! :D Thanks tokumaru! :D
tokumaru wrote:
When using MMC1 would it be hard (too slow)... for the cpu to use both 4 and 8 kb files?
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.

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.
Excellent!! Now I'm fixed away from my past thoughts; thank you so much tokumaru! :D
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 »

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.
Ok I added this code at the end of my fixed PRG bank:

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
and it built my nes file... but, then I tried to add the switchable PRG bank to my code:

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
but it, asm6, told me that "...g.asm(596): Label already defined." (Line 596 of that ...g.asm file is simply "reset_stub:".) I do understand what the error asm6 was talking about. :) But, I don't understand how too prevent that error when I am told to: :?
[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
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'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. :)
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 »

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.
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 »

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. :)
Thank you 3gengames!! :D
tokumaru 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.
Thanks tokumaru!! :D I have created my 16 files... each one has that code at the bottom

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
Hope that could work. Will try to build my nes file after lunch! :)

edit: Lunch was nice. :) So I've made 16 files... but how do I include each file? Do I need to write code like this

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
How could that be done? :?[/color]
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 »

You don't have to write various reset stubs with repeated code. That's redundant and prone to errors. You can make an include file with the stub, and call the label -reset_stub, so that the assembler doesn't complain about repeated labels, and then for the vectors you can just use .word vblank, -reset_stub, irq, still inside the include file, to completely get rid of redundancy. Just include that file at the end of every bank.
Post Reply