Mesen - NES Emulator

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: Mesen - NES Emulator

Post by lidnariq »

Allow me to rephrase the bug report:

Q: "this romhack is glitchy in Mesen relative to other emulators"
A: "We require evidence of what this romhack does on real hardware."

A flashcart is just another kind of emulator.
kuja killer
Posts: 130
Joined: Mon May 25, 2009 2:20 pm

Re: Mesen - NES Emulator

Post by kuja killer »

yea.. i dont know what it's like on there, for a real mmc3 cart. but if it wiggles and stuff like the original mm3 ...then it just means...wait a couple extra ppu pixels (1 "dummy" NOP/LDA/etc) until it stops.
mkwong98
Posts: 282
Joined: Mon May 30, 2011 9:01 pm

Re: Mesen - NES Emulator

Post by mkwong98 »

I guess the best approach for the problem without a real MMC3 chip would be:
1. Get a debug log from Mesen when the wobbling happens with an unpatched rom.
2. Get a debug log from Mesen when the wobbling happens with an patched rom.
3. Get a debug log from other emulators when the wobbling happens with an unpatched rom.
4. Get a debug log from other emulators where the wobbling is fixed with an patched rom.
5. Compare the log files to see why the wobbling happens
6. Find out how the patch fixes the wobbling in other emulators
7. Find out why the patch doesn't work on Mesen
8. Decide which of the patch or Mesen matches more to known MMC3 behavior
9. Fix the one that dosen't match
kuja killer
Posts: 130
Joined: Mon May 25, 2009 2:20 pm

Re: Mesen - NES Emulator

Post by kuja killer »

im already 1 million percent certain it's just soley because this mesen emulator uses it's own timings for when a IRQ starts officially.
thats how i knew that was the case when checking with nintendulator's debugger, it was about 10-something "ppu pixels" earlier or later than fceux was... "not" the game whatsoever.

And i bet that's precisly the same case with mesen too...just because it starts it's IRQ's later or earlier than the other emu's, and that's why it's emu related, not game related specifically.

All this is about, is just getting those 2005 or 2006 writes within that "ppu pixel 256 to 3xx" (sorry i forget the exact numbers it has to be) area ...and if mesen does the writes before or after, then... that's it.

edit: sorry for long post...here you guys mess with it on mesen. since i cant test.
Edit 7C2E0 in hex editor for stage select (i dont know if mesen has a real-time hex editor like fceux)
default value is "08" which i used. this is the "wait for h-blank loop" ..just keep increasinng it by 1 until the "wiggle" stops in mesen, and there you go.
any lower will make the bottom part of the camera shift up 1 pixel which + make scanline glitch come back which you dont want.
Mesen probably expects an 09 or 0A or something for it's IRQ timing...i dont know.
mkwong98
Posts: 282
Joined: Mon May 30, 2011 9:01 pm

Re: Mesen - NES Emulator

Post by mkwong98 »

It seems to be connected to the "alternate" or "old" behavior mentioned in the wiki
http://wiki.nesdev.com/w/index.php/MMC3
There's a slight discrepancy with what happens when $C000 is set to $00, and so far, two behaviors are known to exist:

All MMC3A's and non-Sharp MMC3B's will generate only a single IRQ when $C000 is $00. This is because this version of the MMC3 generates IRQs when the scanline counter is decremented to 0. In addition, writing to $C001 with $C000 still at $00 will result in another single IRQ being generated. In the community, this is known as the "alternate" or "old" behavior.
All MMC3C's and Sharp MMC3B's will generate an IRQ on each scanline while $C000 is $00. This is because this version of the MMC3 generates IRQs when the scanline counter is equal to 0. In the community, this is known as the "normal" or "new" behavior.
Nintendulator passes the alternate behavior test or MMC3 IRQ Tests by blargg and fails the normal behavior test.
Mesen fails the alternate behavior test even with the MMC3 alternate behavior option selected and passes the normal behavior test.

The test which Mesen fails is this:
3) IRQ shouldn't occur when reloading after counter normally reaches 0
I have fixed this and the wobbling seems to be gone now but the readme with the tests seems to suggest Megaman 3 uses the normal behavior in the first place:
Tests MMC3 revision B differences (tested with Super Mario Bros. 3 and Mega Man 3 boards)
I'll post a test release later.
Fiskbit
Posts: 890
Joined: Sat Nov 18, 2017 9:15 pm

Re: Mesen - NES Emulator

Post by Fiskbit »

Alternative versus normal should not be relevant to this. The difference between these two can change which scanline the IRQ is generated on, not where in the scanline.

This really is quite simple: test the hack on real hardware, with a real MMC3 of the same type as Mega Man 3 (revision and manufacturer). If no one wants to do that, then modify the hack to do the PPU writes in a safer part of hblank (which probably a good idea to do, anyway). Since it sounds like we're dealing with maybe 1 or 2 dots of variance, delaying even 1 CPU cycle should solve the problem across all reasonable emulators. Without real hardware results that contradict emulator behavior or solid research from MMC3 die shots, there is nothing to be done here on the emulator side.
kuja killer
Posts: 130
Joined: Mon May 25, 2009 2:20 pm

Re: Mesen - NES Emulator

Post by kuja killer »

yea what fiskbit said -- just edit 7C2E0 on the hack to control the "wait for h blank" loop ..like i mentioned, just keep increasing by 1 and then it'll be fine for that emu.

i probably picked "08" because it was the very first "ppu pixel" thing in the 256 range that hides the scanline glitch..i can go up to about 0B or 0C i think (i forget sorry)..in fceux before the scanline glitch starts showing up again on the "next" scanline (after it crosses from ppu pixel 340 back to 000)

So probably 09 or 0A would be more safe/compatible most likely.

just a note: original megaman 3 does not have any wait for hblank loops for any of it's IRQ's at all, so i made one of these for every single IRQ for the hack.
i probably used the first known working pixel position after 256, on alot of them like stage select. i did this years ago so dont remember much.
mkwong98
Posts: 282
Joined: Mon May 30, 2011 9:01 pm

Re: Mesen - NES Emulator

Post by mkwong98 »

Yes, you are right, now that I have tested it a few more times the wobble seems to randomly happens. And changing that value you mentioned to 09 fixes it.
mkwong98
Posts: 282
Joined: Mon May 30, 2011 9:01 pm

Re: Mesen - NES Emulator

Post by mkwong98 »

There is a commit in the libretro fork https://github.com/libretro/Mesen/commi ... 4edc8672a7 which is relevant to NovaSquirrel fork too and I want to port it over but can't make a pull request because other commits in libretro fork are incompatible. Is there anyway to fix this?
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: Mesen - NES Emulator

Post by lidnariq »

git cherry-pick ?
mkwong98
Posts: 282
Joined: Mon May 30, 2011 9:01 pm

Re: Mesen - NES Emulator

Post by mkwong98 »

lidnariq wrote: Sun Mar 14, 2021 10:31 pm git cherry-pick ?
Thanks, I'll try that. I haven't use git cli before, hope I won't mess up.
stan423321
Posts: 53
Joined: Wed Sep 09, 2020 3:08 am

Re: Mesen - NES Emulator

Post by stan423321 »

If you're afraid of screwing up with git, my better safe than sorry rebase/cherry-pick routine goes like this:
  • Generate a new temporary branch at the same point where the one you plan to mess with lies and switch to it.
  • git rebase -i --onto newstartpointbranch olddivergencebranch mytemporarybranch
  • Edit the rebase recipe.
  • Resolve conflicts until rebase is done.
  • If everything works, you can e.g. merge the new start point branch into temporary.
If anything goes wrong, just (abort rebase if in progress, then) delete the temporary branch and start again.
mkwong98
Posts: 282
Joined: Mon May 30, 2011 9:01 pm

Re: Mesen - NES Emulator

Post by mkwong98 »

stan423321 wrote: Mon Mar 15, 2021 1:37 am If you're afraid of screwing up with git, my better safe than sorry rebase/cherry-pick routine goes like this:
  • Generate a new temporary branch at the same point where the one you plan to mess with lies and switch to it.
  • git rebase -i --onto newstartpointbranch olddivergencebranch mytemporarybranch
  • Edit the rebase recipe.
  • Resolve conflicts until rebase is done.
  • If everything works, you can e.g. merge the new start point branch into temporary.
If anything goes wrong, just (abort rebase if in progress, then) delete the temporary branch and start again.
Thanks, I made a temp branch as you suggested.
Mattiac
Posts: 22
Joined: Sun Jun 16, 2019 7:00 am

Re: Mesen - NES Emulator

Post by Mattiac »

Furrtek-san reverse engineered MMC3C and maybe that can help you all? http://github.com/furrtek/VGChips/tree/ ... endo/MMC3C
mkwong98
Posts: 282
Joined: Mon May 30, 2011 9:01 pm

Re: Mesen - NES Emulator

Post by mkwong98 »

I'm adding a new condition for sprite tiles. It works like FrameRange but have separate frame counter for each of the 64 sprites in OAM and the frame counters reset when the graphics changes. So you can sync the HD replacement with the sprite animation. But it won't work if the sprites frequently switch location in OAM.
Post Reply