It's know that all MMC1 registers are 5 bits whide.
So the reg3 that swaps the PRG banks is also 5 bits wide, that means it can swap 32 16kb banks or 16 32kb banks, so the total size is 512kb. However, the MMC1 doen't have any A18 outpout, and only DW3 and DW4 (+ other famicom only games) does uses one of the CHR lines to do the main 256kb selection, that's connected to A18.
So it the 5th bit simply unused, or am I misunderstanding something ?
That's the WRAM protection bit, I don't think many games use it.
hap wrote:
That's the WRAM protection bit, I don't think many games use it.
Huh ? WRAM protection, like the MMC5's $5002/$5003 ?
So, if the 5th bit is set, you can neither read or write to the SRAM, so it's content is safe for power-down and it could be safe to turn off the console without having to hold the reset button, right ? (However, the MMC5 allows to read and not write, and I also think that no games uses it, exept before reset).
Heh, I've another MMC1 question. Is there a licenced game that swaps between 32kb and 16kb bankswitching, and/or high/low PRG aera switching ? I would be interessted to see this in pratice. There is a doc explaining that, but it written in a incredibly-heavy way and I din't totally get it.
The hardware is nice and simple. Every time you write to any register, it latches all 5 bits. Let's call the config register CFHMM (ala Kevtris' MMC1 doc)
The two bits that affect PRG banking are:
bank32 = F is zero
prg_xor_a14 = (H is zero) and (F is not zero)
Pretend there are 4 banking registers instead of 3 (chr low, chr high, prg low, prg high, with prg high being all 1's or all 0's depending on which bank is the switchable one) Then we can talk about PRG and CHR behaving mostly the same.
prg latch(x, y)
means to read bit x from latch y
(where latch 0 is switchable, latch 1 is the fixed one, and x from 0..3)
if bank32 then
prg a14 <= cpu a14
prg a17..a15 <= prg latch(3 to 1, 0)
else
prg a14 <= prg latch(0, cpu_a14 xor prg_xor_a14)
prg a17..a15 <= prg latch(3 to 1, cpu_a14 xor prg_xor_a14)
end
same thing for chr, except there is no xoring going on:
chr latch(x, y)
means to read bit x from latch y
(where y is 0..1 and x from 0..4)
if we're in 8 KB mode then
chr a12 <= ppu a12
chr a16..a13 <= chr latch(4 to 1)
else
chr a12 <= chr latch(0)
chr a16..a13 <= chr latch(4 to 1)
end
A few examples:
if you MMC1_write 0x01 to $E000 while in 16 KB banking mode (i.e. config has F=1, H=1, same as after a reset) then you'll access
$8000..$BFFF - second 16 KB of ROM
$C000..$FFFF - last 16 KB of ROM
if you then re-write config to have F=0, H=x (H is ignored when F=0)
$8000..$BFFF - accesses first 16 KB of ROM (a14=0, upper bits = 1&0xE=0)
$C000..$FFFF - accesses second 16 KB of ROM (a14=1, upper bits = 1&0xE=0)
If you MMC1_write 0x13 to $E000 then
F=1, H=1 gives you:
$8000 - 19th 16KB page of ROM
$C000 - last 16KB page of ROM (a14 ^ H = 1's)
if you then write H=0, then
$8000 - first page of ROM (fixed page, but a14 ^ H = 0's)
$C000 - 19th 16KB page of ROM
if you write F=0 then:
$8000 - 18th 16 KB page
$9000 - 19th 16 KB page
if you then write F=1 again:
$8000 - first page of ROM (fixed page, but a14 ^ H = 0's)
$C000 - 19th 16KB page of ROM
(i.e. no data is lost when you start ignoring the low bit for 32 KB mode)
CHR behaves the same way when switching between 4KB and 8 KB mode, just shift all the addresses down by 2 (a14->a12, etc...)
The existing docs were written with emus in mind, not with how the hardware actually works. The latches get written when you write them, and there is a seperate control register that affects how those latches are output on the pins of the MMC1 chip.
This is also true for the SOROM and SUROM boards (and possibly the mythical HVC-SVROM board, if I can ever win an auction for a FF1+2 cart), which use one of the CHR banking output pins to instead control WRAM (SOROM, CHR_a16 -> WRAM_a13), ROM (SUROM, CHR_a16->PRG_a18), or both (SVROM possibly, with CHR_a15 and CHR_a16 used, dunno). So you could theoretically pull some tricks like filling WRAM with different data in the low and high banks and being able to tell when the PPU is accessing $0000..$0FFF or $1000..$1FFF (can't imagine a real use for it tho)
Having said all this, I dunno any games that muck with the control register much, but I haven't really looked either.
Ack, correction to above:
Code:
if we're in 8 KB mode then
chr a12 <= ppu a12
chr a16..a13 <= chr latch(4 to 1)
else
chr a12 <= chr latch(0, ppu_a12)
chr a16..a13 <= chr latch(4 to 1, ppu_a12)
end
Thanks, but I just wanted to know witch games actually used it. All MMC1 games I checked uses only F=1 and H=1 to have a bankswitching similar to UNROM.