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 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.
Why does my MMC1 mapper act like this?
Moderator: Moderators
Re: Why does my MMC1 mapper act like this?
Re: Why does my MMC1 mapper act like this?
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.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.
Re: Why does my MMC1 mapper act like this?
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.
- colinvella
- Posts: 74
- Joined: Sun Jun 05, 2016 1:41 pm
Re: Why does my MMC1 mapper act like this?
I managed to solve this!ArsonIzer wrote:
Mega Man 2 never crashes, the graphics are just f'd up. Here's what happens further into the game:
(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.
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/
Fancy Fish Mod - Minecraft Mod: http://fancyfishmod.weebly.com/
- rainwarrior
- Posts: 8731
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: Why does my MMC1 mapper act like this?
If the mirroring is mapper controlled the ROM header's mirroring setting is irrelevant.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.
- colinvella
- Posts: 74
- Joined: Sun Jun 05, 2016 1:41 pm
Re: Why does my MMC1 mapper act like this?
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.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/
Fancy Fish Mod - Minecraft Mod: http://fancyfishmod.weebly.com/
Re: Why does my MMC1 mapper act like this?
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).rainwarrior wrote:If the mirroring is mapper controlled the ROM header's mirroring setting is irrelevant.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.
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi
Re: Why does my MMC1 mapper act like this?
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.