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.

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.

I think unregistered is REALLY confused about how bankswitching works... Let me try to explain it.

Thank you so much tokumaru!!

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?

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.

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!

---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?

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?

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.

Quote:

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.

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?

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.

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!

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:

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.

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!!

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!! I have created my 16 files... each one has that code at the bottom

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.

Who is online

Users browsing this forum: No registered users and 5 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum