I also see that MMC3 has switching CHR banks of 1KB, while MMC1 4KB. I have not tried the MMC3 yet, so occasionally I will ask if the MMC3 needs to be specially initiated at the beginning of the code? I am talking about switching on a method similar to UNROM.
Last I checked, the biggest advantage of MMC1 (or the similarly capable Action 53 mapper) over MMC3 was that MMC3 needed a more expensive CPLD. Is this still the case?
As for chr, if I was stuck at 4k switch, that would be a pain ^^;;; I use 2k/2k for BG and 1k/1k/1k/1k for sprites but the opposite is possible too.
Tepples mentioned the price but unless you plan to mass produce it and have some kind of super hit or something.. Don't worry about that Most of the time people now run with an emulator and with those flash cartridge, compare to 10+ years ago, the need to make carts is different. But it always depends what is your goal. In my case, I prefer a mapper that offer more flexibility than price since I'm not expecting cart release anyway.
Code: Select all
reset: ; reset routine moved to $E000-$FFFF sei ; ignore IRQs cld ; disable decimal mode ldx #$40 stx $4017 ; disable APU frame IRQ ldx #$ff txs ; Set up stack ; inx ; now X = 0 ldx #$07 loop: stx $8000 lda mmc3tbl,x sta $8001 dex bpl loop sta $A000 ; set vertical mirroring, or use stx for horizontal ; jmp rest_of_reset ; A=$00 and X=$FF at end, so ready for $2000/$2001 writes and TXS stx $2000 ; disable NMI stx $2001 ; disable rendering stx $4010 ; disable DMC IRQs bit $2002 @vblankwait1: bit $2002 bpl @vblankwait1 txa @clrmem: sta $000,x sta $100,x sta $300,x sta $400,x sta $500,x sta $600,x sta $700,x inx bne @clrmem @vblankwait2: bit $2002 bpl @vblankwait2 ;(...) mmc3tbl: .byt 0,2,4,5,6,7,0,1
I want to change the unrom and use a mapper that has WRAM and mirroring control. And the most important thing is to be able to use 512KB PRG (when needed).
I believe that even with the classic iNES header you can specify a mapper 2 ROM with 512KB of PRG-ROM, WRAM and 4-screen. In some cases, 4-screen eliminates the need for configurable mirroring, and it's extremely simple to implement on hardware if you're already using CHR-RAM.
Unrom equires a soldering iron to switch mirroring.
I am currently using UNROM-512. However, I have a project in which I use WRAM, and needs mirroring control.
Somewhere is a diagram on how to connect WRAM to unrom? (If it requires adding something more than the wram itself.)
Although I would rather use a mapper, which is commercial and generally available so that if necessary you do not have to combine too much to write the game on the card. (example: MMC1 when PRG up to 256, MMC3 when 512).
The reason I'm asking is because there's no rule saying that you have to use a particular type of mirroring to achieve a particular type of scrolling... After all, there are games using 2 name tables that scroll in 8 directions just fine without ever changing the mirroring. You may need to use a few tricks to make 8-way scrolling 100% glitch-free, but it's possible.sdm wrote:To control the direction of screen scrolling (H/V).
I also mentioned 4-screen as an alternative to mirroring control. With 4 screens, you can have glitchless scrolling in any direction without tricks, and it's incredibly simple to add to a CHR-RAM cartridge: use a 16KB or 32KB CHR-RAM chip (which are way easier to find than 8KB anyway) and solder a wire to tell the NES not to use its internal RAM for name tables. It's a permanent setting, and the same chip will be used for pattern tables and name tables (4 of them).
You do need a chip to handle the logic of when to enable the WRAM chip. The wiki has a page about this: https://wiki.nesdev.com/w/index.php/PRG_RAM_circuitSomewhere is a diagram on how to connect WRAM to unrom? (If it requires adding something more than the wram itself.)
The MMC3 is a very nice mapper overall, but it may increase manufacturing costs unnecessarily if you you're not using some of its more advanced features, such as the fine CHR switching or scanline IRQs.Although I would rather use a mapper, which is commercial and generally available so that if necessary you do not have to combine too much to write the game on the card. (example: MMC1 when PRG up to 256, MMC3 when 512).
The features you don't use don't increase manufacturing costs, though. If you don't need the IRQ you wouldn't need to accomodate it in the CPLD. If you don't need all the bankswitching register they can be omitted. Etc.tokumaru wrote:The MMC3 is a very nice mapper overall, but it may increase manufacturing costs unnecessarily if you you're not using some of its more advanced features, such as the fine CHR switching or scanline IRQs.
I think some subsets of MMC3 are actually really sensible to build.
The same is true for every mapper: choosing a subset of an existing mapper makes development easier, and hardware cheaper.