Initial state of PRGbanks with MMC1?
Moderator: Moderators
Initial state of PRGbanks with MMC1?
I am not sure if there's an answer for this but.. Which PRG-banks are actually "in place" during power-up, without any kind of MMC1-initialization code running? Is it random? Haven't seen this in the Wiki..?
Re: Initial state of PRGbanks with MMC1?
I have personally observed one MMC1 initialization state:
* First 16K of PRG-ROM into 8000, Last 16K into C000
* First 8K of CHR-ROM into CHR 0000
* Single Screen Mirroring
There's a neat story behind this one. It involved a platoon WR speedrun attempt, and the game booting straight to a glitched ending.
But this initializtion state is not guaranteed to be consistent across MMC1 cartridges. Because any bank could theoretically be mapped at C000-FFFF, every single PRG bank needs a boot stub to reset the mapper, then jump to the real boot code.
---
Example of boot code to include at the end of every bank:
* First 16K of PRG-ROM into 8000, Last 16K into C000
* First 8K of CHR-ROM into CHR 0000
* Single Screen Mirroring
There's a neat story behind this one. It involved a platoon WR speedrun attempt, and the game booting straight to a glitched ending.
But this initializtion state is not guaranteed to be consistent across MMC1 cartridges. Because any bank could theoretically be mapped at C000-FFFF, every single PRG bank needs a boot stub to reset the mapper, then jump to the real boot code.
---
Example of boot code to include at the end of every bank:
Code: Select all
FFF4:
INC $FFFC
jmp EntryPoint
FFFA: .dw xxxx (NMI vector)
FFFC: .dw $FFF4 (Reset vector)
FFFE: .dw xxxx (IRQ vector)
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
Re: Initial state of PRGbanks with MMC1?
The INC works as an MMC1-reset?
Thanks.
Thanks.
Re: Initial state of PRGbanks with MMC1?
INC works here because the byte in ROM at FFFC is "F4", or the low byte of the reset vector (FFF4). Because the high bit (80) is set, it's treated as a mapper reset.
---
Aside Note (Double writes to MMC1 from Read-Modify-Write instructions)
Use care when doing Read-Modify-Write instructions for MMC1 registers. A Read-Modify-Write instruction does two consecutive writes:
The MMC1 happens to ignore the second write. So it will only see the *Unmodified Value* getting written. Some emulators may not do this properly, and may only pass the modified value instead. The game "Bill and Ted" relies on using INC with a value of FF to reset the mapper. The instruction causes an FF write, then a 00 write immediately after. But the mapper only sees the FF write, and not the 00 write. Some emulators get this wrong, and will only pass the 00 write onto the mapper. Then the game doesn't boot.
In our case with the example code, our value to increment is "F4". This causes the values "F4" and "F5" to be written to the MMC1, and the MMC1 ignores the "F5" value. A less-accurate emulator could write both "F4" and "F5", or just "F5", but since both are reset commands, it should be fine.
---
Aside Note (Double writes to MMC1 from Read-Modify-Write instructions)
Use care when doing Read-Modify-Write instructions for MMC1 registers. A Read-Modify-Write instruction does two consecutive writes:
Code: Select all
1 PC R fetch opcode, increment PC
2 PC R fetch low byte of address, increment PC
3 PC R fetch high byte of address, increment PC
4 address R read from effective address
5 address W write the value back to effective address,
and do the operation on it
6 address W write the new value to effective address
In our case with the example code, our value to increment is "F4". This causes the values "F4" and "F5" to be written to the MMC1, and the MMC1 ignores the "F5" value. A less-accurate emulator could write both "F4" and "F5", or just "F5", but since both are reset commands, it should be fine.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
Re: Initial state of PRGbanks with MMC1?
Nintendo's leaked MMC1 datasheet says that the banks are unknown on powerup. We've had people both report random power-up banks and reliable power-up banks. Several games include multiple reset vectors, not relying on any one memory layout being reliable enough. Lots of commercial games do not successfully boot if the MMC1 powers up in "fixed bank at $8000, switchable bank at $c000" mode.
-
- Posts: 1510
- Joined: Thu May 19, 2005 11:30 am
Re: Initial state of PRGbanks with MMC1?
It's never been explained why one would need an INC instruction rather than a simple STA instruction to write a byte with bit 7 set. The datasheet just tells one to do that, but several games, including Nintendo's own games (Kid Icarus), don't follow that advice and use a normal STA. Is it to save PRG ROM space?
And at least two commercial games differ in that regard between revisions: "Tecmo Bowl" and "The Untouchables" fail to boot if starting with PRG mode 2 in their rev0, and succeed at booting if starting with PRG mode 2 in their rev1 (and rev2, in the latter game's case).Lots of commercial games do not successfully boot if the MMC1 powers up in "fixed bank at $8000, switchable bank at $c000" mode.
Re: Initial state of PRGbanks with MMC1?
Using INC means you don't need to set register A, saving 2 bytes.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
Re: Initial state of PRGbanks with MMC1?
Out of curiosity, could it happen that the same bank appears at both $8000 and $C000 at powerup?
-
- Posts: 1510
- Joined: Thu May 19, 2005 11:30 am
Re: Initial state of PRGbanks with MMC1?
This could happen if the MMC1 powered on in PRG Mode #2 (Inverse UxROM) with the fixed bank #0 and the switchable bank also happening to be #0, or in PRG Mode #3 (UxROM) with the fixed bank #15 and the switchable bank also happening to be #15. It could not happen if it powered on in 32 KiB PRG mode.