This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

Difference between MMC3 revisions

Difference between MMC3 revisions
by on (#47746)
Do anybody knows if there is a specific init sequence that you have to do for the MMC3A?

I made a dev cart that uses an MMC3A, CHR-ROM/WRAM. The original game works fine. I always test a different game to make sure the board is fine. When I did, I only saw a gray screen. When I putted back a copy of the original PRG-ROM only for testing if the game at least boot, no problem, it does (of course with the garbled CHR-ROM from the previous game).

What I'm concerned now is that I may need some specific init code to make it work properly with my own code. I didn't have time to test my own code but I will try to test it tomorrow.

When I tested my MMC3B with CHR-RAM/WRAM, there was no issue with other games or my own code. I even tested another MMC3A game but still a gray screen.

Any information about the MMC3A will be appreciated. If I find anything myself, I will update this thread.

by on (#47747)
There is no known difference yet (according to the wiki), but the game may require proper data to be in the CHR-ROM for whathever reason (security checks, sprite zero hits or just data stored here) so it's a good idea to always keep your CHR-ROM in sync with the corresponding PRG-ROM when reprogramming your EPROMs.

by on (#47749)
Bregalad wrote:
There is no known difference yet (according to the wiki), but the game may require proper data to be in the CHR-ROM for whathever reason (security checks, sprite zero hits or just data stored here) so it's a good idea to always keep your CHR-ROM in sync with the corresponding PRG-ROM when reprogramming your EPROMs.


The first game that used a different MMC3 was in sync (didn't boot), the second game was not. The original game was not in sync but booted.

I now just did a quick test with my own code and it ran (chr-rom not in sync but that part I didn't mind).

Hmm.. If my code is running I don't care much if other games doesn't run since it not a repro anyway. I'm just curious why it failed. Usually I test a japanese game but this time I tested an American one. I don't think the game does anything with the CIC for security or something?

by on (#47758)
Interesting, maybe you could mention the game that didn't boot so emulator authors could see if it does a particular security check or if it relies on a special MMC3 revision and post it on the wiki.

Also it really doesn't matter if you used ROM data from an american or japanese game. Both are NTSC, and there should be no way for the programm to tell if it runs on a NTSC Famicom or NTSC NES (or if there is a way it should be something absolutely insane about the controllers and no commercial games did that).

by on (#47776)
I was going to test some nes game that never came out in Japan that I had in the past. The first one I tested was Contra Force, MMC3B. Gray screen, doesn't run. Took the PRG chip and put it into my MMC3B CHR-RAM and the game booted well. So that game is not a case of PRG/CHR in sync. Then I tested back original PRG (wizardry) with the contra CHR and the PRG was booting.

Then I tested River city ramson/shadow gate (MMC3A) but only PRG rom and it failed. I should try to test it back in sync.

Bregalad wrote:
Interesting, maybe you could mention the game that didn't boot so emulator authors could see if it does a particular security check or if it relies on a special MMC3 revision and post it on the wiki.


Before asking any emu author, I should make more test to make sure there is no issue with my current dev cart. There is still a possibility that I made a mistake while making it. Once I can at the least make an MMC3A game run then we can try to figure out the difference.

by on (#47787)
Sorry for the double post.

Here's my finding. After testing a MMC3A game and it didn't work, I knew something was wrong. First, my devcart had an intermittent short causing some program not to work. After fixing this, things started to work normally.

Results:

- MMC3B games can works on MMC3A

MMC3A
- If you forget to init the mapper, the program won't run
- If you don't set the CHR bank, the last bank seems to be the one loaded

MMC3B
- If you forget to init the mapper, the program still run
- For CHR banks with CHR-RAM, bank 0 was loaded

This is the only differences I found so far. It seems to be mostly related to the init process. They may have changed it a little bit to help debugging when you did something wrong in the init phase (just guessing thought).

One thing I saw in both case is if you forget to init the sprites, you will get some garbage on the screen. Seems to react the same in both case.

by on (#47789)
Banshaku wrote:
MMC3A
- If you forget to init the mapper, the program won't run

By "init the mapper" do you mean load something into registers 6 and 7 (PRG bank 8/C and PRG bank A), or something else?

by on (#47790)
tepples wrote:
By "init the mapper" do you mean load something into registers 6 and 7 (PRG bank 8/C and PRG bank A), or something else?


I just realized that it's not that clear unless I explain what I mean by init. Here's what I did (wrong) the first time I used an MMC3:

Code:
   ldy #$06
   sty MMC3_CTRL
   lda #4                  ; The 4th 16k bank
   asl                     ; MMC3 supports 8k one so we must find the right location by converting the number
   sta MMC3_PAGE
   
   iny                     ; Then $A000

   sty MMC3_CTRL
   ora #1            ; select next bank
   sta MMC3_PAGE
   
   
   ; Then set vertical mirroring
   lda #MMC3_MIRROR_V
   sta MMC3_MIRROR
   
   ; Disable IRQ
   lda #0
   sta MMC3_IRQ_DISABLE


The first time I used an MMC3B with CHR-RAM, I only set the prg banks, mirroring and disabled the IRQ but forgot to set the CHR ones.

If I skip (by accident) to do any setting on the MMC3 registers like written above on a MMC3A, the program will not run. On the other hand, it did run on a MMC3B.

by on (#47791)
Well, it's impossible for the MMC3 to stop the NES' CPU. All it does its bankswitching PRG and CHR high adress, and generating IRQs.
It should have bankswiched the wrong PRG bank or something like that for it "not to run".

by on (#47792)
Bregalad wrote:
Well, it's impossible for the MMC3 to stop the NES' CPU. All it does its bankswitching PRG and CHR high adress, and generating IRQs.
It should have bankswiched the wrong PRG bank or something like that for it "not to run".


I guess I'm tired right now so my explanation are quite vague, sorry about that. I will explain what my code does in my test sample. I have a NMI routine that increase a counter and update the music. In the main loop, based on the counter, I check if I need to process the next key or not so I know if I can scroll, change music etc. I didn't do any setting on any of the MMC3 registers by accident.

With MMC3A, the NMI doesn't seems triggered at all but it should. No music is played and I cannot scroll anything. In the case of MMC3B, everything was fine. In both case the CHR banks were wrong since I didn't set them.

In the emulator, the code ran fine, banks properly selected for both PRG/CHR without any init code.

All the code is located in the last bank at E000 so it should at worked in both case since E000 is fixed to the last bank.

Interesting behavior but I don't know how much value it add. It only does that when you don't set anything on the MMC3. Once set, everything is fine.

by on (#47795)
Isn't there a register that enables or disables WRAM that behaved differently on different MMC3 versions? I imagined that a game that requires WRAM could just not run if it's not present.

by on (#47805)
tokumaru wrote:
Isn't there a register that enables or disables WRAM that behaved differently on different MMC3 versions? I imagined that a game that requires WRAM could just not run if it's not present.


That could be an interesting test to do someday but both dev-cart have WRAM so I cannot test it yet. For now I tested mixed CHR-ROM, CHR-ROM games on CHR-RAM cart and all of them started without fail.

by on (#47807)
- What about Low G Man with $FF on 6000-7fffh on startup?

by on (#47809)
Fx3 wrote:
- What about Low G Man with $FF on 6000-7fffh on startup?


ah... Low g man. That's an interesting test to do! I will try it tonight and let you know the results.

by on (#47821)
Fx3 wrote:
- What about Low G Man with $FF on 6000-7fffh on startup?


Sorry for the double post again. Fx3, Is it supposed to freeze at start up only or later during the game? Because right now the game is running and I already passed level one.

The only thing different from an emulator is maybe that the cart already contains data from the previous game but since the issue was about writing data and checking if it's the same after, the bug should have triggered already.