The consensus on nesdev and other sites like Kevtris' is that all MMC1 variants boot with the last 16kb bank fixed to C000.
I've made a MMC1 ROM with 32kb PRG, and the reset code only in the last part. It works in every emulator, including fceux and nintendulator, yet I got a report it black-screens on a SLROM board. The board itself was confirmed working with another ROM.
Has anyone seen if the currently-in-production MMC1 chips act differently?
There are multiple revisions of the MMC1, some may start in a predictable state, others do not. Notice how every single MMC1 game has the boot code near the end of each bank. (except maybe the games with hardwired fixed 32K prg) You also usually see the game title right before the boot code.
So I don't know where you heard the consensus, but they don't start in a predictable state.
Edit: reply is to OP, Dwedit posted while I was typing.
Is that really consensus? I was always under the impression that it was standard for MMC1 games to have a reset stub in every bank.
I think emulators might be powering on like that because of SEROM / SHROM / SH1ROM, which were assigned to mapper 1 despite having no PRG banking. (Compatibility for these games with minimal effort.)
In cases like this where the power-on state is inconsistent / undefined, emulator authors often still want a consistent startup state, so they make an arbitrary choice. Setting the high ranged bank to the last bank (and the low ranged bank to the first bank) seems to be a common arbitrary startup choice for many mappers / emulators.
It is not consensus at all. At least MMC1 and MMC1A are known to not necessarily boot in 16+16F mode.
Dwedit wrote:
There are multiple revisions of the MMC1, some may start in a predictable state, others do not. Notice how every single MMC1 game has the boot code near the end of each bank. (except maybe the games with hardwired fixed 32K prg)
Final Fantasy (both Japan and US versions) and Final Fantasy II don't.
Indeed, Final Fantasy 1 does not put the boot code at the end of every bank. It also uses the MMC1B on SNROM.
Maybe it's a board revision thing. SLROM-03 uses MMC1A, and SLROM-04 and higher use MMC1B or MMC1B2.
All MMC1 versions have slightly different default values and fixed page values and such. MMC1B2 should have that last page fixed IIRC. MMC1 and MMC1A do not AFAIK. I have the concrete information on the forum, somewhere.
Doesn't Super Mario Bros + Duck Hunt + World Class Track Meet use the original MMC1? Yet the rom doesn't have entry points on every page.
Here's a rather old thread where Blargg surveyed his collection of MMC1 carts and found that all revisions powered up with the final PRG bank switched into the upper quarter of CPU memory space.
And yet ... here we have evidence that this is not always true. I have no idea what's going on.
(re: Dwedit:
SMB/DH/WCTM NesCartDB entry; vectors are present in MMC1 banks 0,1,3,5, and 7)
calima wrote:
yet I got a report it black-screens on a SLROM board
Let's get the first question out of the way: Was this a Nintendo board, or a repro board?
I can confirm for sure that at least one MMC1A MMC1B2/SNROM cart I have does boot in random 32kB banks. I made my own multicart with it long ago, it's just some selected NROM games and my menu + CHR loader in the last bank only. Sometimes it will boot into the menu, sometimes it won't. I can keep cycling the power and watch it boot into various banks somewhat randomly (doesn't seem like it would boot into every possible bank, IIRC), running the games with uninitialized CHR-RAM until it eventually catches the menu bank. The cart was originally Ultima Exodus.
Memblers wrote:
I can confirm for sure that at least one MMC1A/SNROM cart I have does boot in random 32kB banks. I made my own multicart with it long ago, it's just some selected NROM games and my menu + CHR loader in the last bank only. Sometimes it will boot into the menu, sometimes it won't. I can keep cycling the power and watch it boot into various banks somewhat randomly (doesn't seem like it would boot into every possible bank, IIRC), running the games with uninitialized CHR-RAM until it eventually catches the menu bank. The cart was originally Ultima Exodus.
Interesting, considering
Ultima: Exodus is labelled MMC1B2. I think odds are in this case there are multiple revisions floating around with different MMC1 revs.
Ah, I figured I'd better open it up and check (after all, it was like 16 years ago when I last looked at the board), and it looks like I remembered wrong, it actually is MMC1B2. With the S on it (Sharp?), code 8952 5 AA. So it is still MMC1B2, but is a different manufacturer than the one in the database, maybe that matters.
Yeah, I was referring to that blargg thread. And here too people mention ROMs that don't put the reset vec in every 16kb bank.
In one of the MMC1 threads here, a test ROM was mentioned. I'll see if I can track that down, perhaps it will tell me what kind of MMC1 I'm dealing with.
Quote:
Was this a Nintendo board, or a repro board?
A new repro board.
The MMC1 test ROMs were by 3gengames, but all links are dead, and nothing in archive.org. @3gen, did any of them show the bootup state for an arbitrary MMC1?
Yeah, they all showed initial boot state of the mapper like WRAM enabled, banks accessible, etc. Here's the ROM from archive, should be most recent AFAIK:
https://drive.google.com/open?id=0B1laU ... WxfMDg1MVkIt should give you the info you want. Turn power off for a little while, turn it on, and if it boots in random banks, it'll change. Like I said, IIRC MMC1B2 iss the only one I remember always booting in the last bank. MMC1 and MMC1A all boot randomly, if I remember correctly. If you want the source, I'll put it on Github.
Thanks, will report back. Looks very useful, why not post it to a permanent location and link from the wiki?
calima wrote:
Why not post it to a permanent location
This forum is a pretty good place to upload it.
It was a Retrostage board, and it consistently booted in 0f / the last bank.
Now I'm completely out of ideas. Why would a MMC1 ROM work in emulators but not in hw, if the init code is correctly reached?
Have you made sure to initialize all mapper registers?
Is it possible that their MMC1 implementation is somehow incompatible? (There are some minor details that one might get wrong, like the ignoring of double-writes and the fact that only the address of the last write determines the target register. Whether this would be an issue depends on how your program uses MMC1, though.)
Make sure the pointers for NMI and such in the last bank 0F point to the upper region and not the lower one? Maybe it's made to assume two boot banks in order and it is booting into the lower bank instead of the upper, which still fails. My test program there always boots to the upper bank and all the code is there, too.
Yes, the init code is in the upper bank, starting at 0xFEDA.
This is the MMC1 part:
Code:
; MMC1 init
lda #$80
sta $8000
lda #$00
sta $e000
sta $e000
sta $e000
sta $e000
sta $e000
sta $8000
sta $8000
sta $8000
sta $8000
sta $8000
NMI shouldn't matter, since interrupts are disabled when in there.
edit: I wonder if Retrostage is a member here?
@3gengames
So the test ROM couldn't detect booting to an odd bank?
One last dumb idea:
NES consoles are finicky in general about cartridges. Clean it and blow on it?
It will detect booting in an odd bank because the odd bank will appear in the last bank and be booted from. That's what the bank booted in will tell you, what bank appeared in the upper region at first.
Try burning an appropriately sized Holy Diver Batman ROM to the cart.
Also put this in the last 15 bytes of all banks (starting at base + $3FF1):
Code:
entry_fff1:
sei
lda #$FF
sta entry_fff1+2
jmp reset_handler
.assert reset_handler >= $C000, error, "reset handler must be in the fixed bank"
.addr nmi_handler, entry_fff1, irq_handler
"Why write $FF over $FF? I thought MMC1 didn't have bus conflicts."
It doesn't. I designed this code to work not only on MMC1 but also on AOROM, BNROM, and the mapper 180 variant of UNROM.
Retrostage wrote:
My mapper is based off of the MMC1B, which during power-on will default to a 16Kb banking and PRG-RAM enabled state. $C000-$FFFF is fixed on power-up.
Mystery continues as time allows.