More MMC1 CHR bankswitching woes (On real hardware)

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

sdm
Posts: 306
Joined: Tue Apr 11, 2006 4:08 am
Location: Poland

Re: More MMC1 CHR bankswitching woes (On real hardware)

Post by sdm » Fri Sep 14, 2018 3:46 am

Thanks for the explanation.

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.

tepples
Posts: 22017
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: More MMC1 CHR bankswitching woes (On real hardware)

Post by tepples » Fri Sep 14, 2018 7:05 am

MMC3 init is 28 bytes and needs to be somewhere in $E000-$FFFF.

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?

User avatar
Banshaku
Posts: 2378
Joined: Tue Jun 24, 2008 8:38 pm
Location: Japan
Contact:

Re: More MMC1 CHR bankswitching woes (On real hardware)

Post by Banshaku » Fri Sep 14, 2018 7:39 am

Well, in my current codebase, after I finish to init the nes, I init my banks because I want to access specific data but except for that, the last bank it set at $E000 and second last bank at $C000 (default setting, it could be at $8000 if you set differently).

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.

sdm
Posts: 306
Joined: Tue Apr 11, 2006 4:08 am
Location: Poland

Re: More MMC1 CHR bankswitching woes (On real hardware)

Post by sdm » Fri Sep 14, 2018 10:57 am

Is it correct?

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

User avatar
tokumaru
Posts: 11755
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: More MMC1 CHR bankswitching woes (On real hardware)

Post by tokumaru » Fri Sep 14, 2018 4:23 pm

Mapper 2 (UxROM) can be extended to 512KB without problems, and WRAM can be added to any cartridge regardless of the mapper. May I ask why you need mirroring control?

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.

sdm
Posts: 306
Joined: Tue Apr 11, 2006 4:08 am
Location: Poland

Re: More MMC1 CHR bankswitching woes (On real hardware)

Post by sdm » Sat Sep 15, 2018 1:53 am

To control the direction of screen scrolling (H/V).
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).

User avatar
tokumaru
Posts: 11755
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: More MMC1 CHR bankswitching woes (On real hardware)

Post by tokumaru » Sat Sep 15, 2018 8:07 am

sdm wrote:To control the direction of screen scrolling (H/V).
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.

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).
Somewhere is a diagram on how to connect WRAM to unrom? (If it requires adding something more than the wram itself.)
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_circuit
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 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.

User avatar
rainwarrior
Posts: 7824
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: More MMC1 CHR bankswitching woes (On real hardware)

Post by rainwarrior » Sat Sep 15, 2018 3:49 pm

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

I think some subsets of MMC3 are actually really sensible to build.

lidnariq
Posts: 9504
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: More MMC1 CHR bankswitching woes (On real hardware)

Post by lidnariq » Sat Sep 15, 2018 3:55 pm

Yeah, it's worth remembering that if you just need an UNROM-like subset of MMC3 ... it will only be roughly as expensive as INL's SNROM repro cart, and the programmer's interface will be nicer.

The same is true for every mapper: choosing a subset of an existing mapper makes development easier, and hardware cheaper.

User avatar
tokumaru
Posts: 11755
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: More MMC1 CHR bankswitching woes (On real hardware)

Post by tokumaru » Sat Sep 15, 2018 7:50 pm

Yeah, if whoever is manufacturing carts for you can customize the mapper yo remove unused features and bring costs down, that's great.

Post Reply