Why does my MMC1 mapper act like this?

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

User avatar
zeroone
Posts: 929
Joined: Mon Dec 29, 2014 1:46 pm
Location: New York, NY
Contact:

Re: Why does my MMC1 mapper act like this?

Post by zeroone » Sat Jan 17, 2015 11:26 am

ArsonIzer wrote:I tried running the PPU only one cycle per CPU cycle while VBlank is active, i.e. the CPU runs 3 times faster/the PPU runs 3 times slower during VBlank. This does not have any effect on any of the games.
When the PPU is disabled (sprite/background rendering turned off), make sure that the PPU renderer is not modifying the V and T loopy registers; only the CPU should be messing around with them.

ArsonIzer
Posts: 115
Joined: Fri Jul 19, 2013 11:38 am

Re: Why does my MMC1 mapper act like this?

Post by ArsonIzer » Sun Jan 18, 2015 4:35 am

zeroone wrote:When the PPU is disabled (sprite/background rendering turned off), make sure that the PPU renderer is not modifying the V and T loopy registers; only the CPU should be messing around with them.
Yes, I saw your thread about that, but that's not the case with mine. I made a 100% sure that it doesn't touch loopyV and loopyT if it's not rendering. LoopyV and LoopyT updating is probably not the issue.

ArsonIzer
Posts: 115
Joined: Fri Jul 19, 2013 11:38 am

Re: Why does my MMC1 mapper act like this?

Post by ArsonIzer » Tue Feb 03, 2015 2:19 pm

Update: I fixed the bug that makes the emulator pick the wrong pattern table from the CHR data in a rom. This fixes a lot of the wrong graphics, but some MMC1 ROMs still crash (double dragon, abadox), and some still have confusing nametable issues (mega man 2, final fantasy, adventures in the magic kingdom). I'll look into those ASAP.

User avatar
colinvella
Posts: 74
Joined: Sun Jun 05, 2016 1:41 pm

Re: Why does my MMC1 mapper act like this?

Post by colinvella » Sun Jun 05, 2016 2:30 pm

ArsonIzer wrote:
Mega Man 2 never crashes, the graphics are just f'd up. Here's what happens further into the game:


Image

(After pressing start again the stage pick screen is screwed up)
:
:
:

(Stages are graphically completely messed up but still playable as if the game was running completely normally)

Any ideas? The 4 other mappers work perfectly but this one doesn't at all.
I managed to solve this! :)

My own emulator suffered from the same problem until I realised that MMC1, unlike simpler mappers such as NROM, can change the mirroring mode multiple times during the game. I was originally setting the mirroring mode from the cartridge rom property but for MMC1 one must also update it memory mapping whenever a change in the mirroring mode occurs. I fixed this by exposing an event in my Cartridge class that is fired whenever the program writes to the $8000-$9FFF addtress range in MMC1 (the rom's control register range).
Tile IDE and tile engine for XNA: http://tide.codeplex.com/
Fancy Fish Mod - Minecraft Mod: http://fancyfishmod.weebly.com/

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

Re: Why does my MMC1 mapper act like this?

Post by rainwarrior » Sun Jun 05, 2016 3:10 pm

colinvella wrote:I was originally setting the mirroring mode from the cartridge rom property but for MMC1 one must also update it memory mapping whenever a change in the mirroring mode occurs.
If the mirroring is mapper controlled the ROM header's mirroring setting is irrelevant.

User avatar
colinvella
Posts: 74
Joined: Sun Jun 05, 2016 1:41 pm

Re: Why does my MMC1 mapper act like this?

Post by colinvella » Wed Jun 29, 2016 4:05 pm

I managed to solve this! :)

My own emulator suffered from the same problem until I realised that MMC1, unlike simpler mappers such as NROM, can change the mirroring mode multiple times during the game. I was originally setting the mirroring mode from the cartridge rom property but for MMC1 one must also update it memory mapping whenever a change in the mirroring mode occurs. I fixed this by exposing an event in my Cartridge class that is fired whenever the program writes to the $8000-$9FFF addtress range in MMC1 (the rom's control register range).
From the posted Megaman 2 screenshots. That seems to be the problem. MMC1 is typically the first mapper that novice emulator devs implement, that support dynamic mirroring via registers. Simpler mappers like NROM usually specify mirroring once in the ROM file itself.
Tile IDE and tile engine for XNA: http://tide.codeplex.com/
Fancy Fish Mod - Minecraft Mod: http://fancyfishmod.weebly.com/

User avatar
thefox
Posts: 3141
Joined: Mon Jan 03, 2005 10:36 am
Location: Tampere, Finland
Contact:

Re: Why does my MMC1 mapper act like this?

Post by thefox » Wed Jun 29, 2016 4:46 pm

rainwarrior wrote:
colinvella wrote:I was originally setting the mirroring mode from the cartridge rom property but for MMC1 one must also update it memory mapping whenever a change in the mirroring mode occurs.
If the mirroring is mapper controlled the ROM header's mirroring setting is irrelevant.
One additional note: You might want to consider initializing the mapper's mirroring setting from the ROM header's setting to stay compatible with some incorrect ROM headers (e.g. mapper 4 being used for mapper 206 games).
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi

User avatar
Myask
Posts: 965
Joined: Sat Jul 12, 2014 3:04 pm

Re: Why does my MMC1 mapper act like this?

Post by Myask » Wed Jun 29, 2016 4:51 pm

Or mappers where only some of the boards have a mapping register. It doesn't hurt, unless there is a known initial value that software relies on…which is somewhat unusual.

Post Reply