Mesen - NES Emulator

[unregistered]

To be honest, I'd rather not needlessly increase the complexity of the trace logger just to fix a couple of whitespace issues, though :p
I'll most likely add some code to trim the whitespace at the end of lines, just to avoid making the logs larger than they need to be, but beyond that, if you're using these in the middle of the line (like the default format), you will want to use [Align] to keep things aligned in a readable manner, anyway, so it shouldn't really matter much at all.

^Brilliant, thank you so much! Sour, I guess it's apparent, but I'm not one who thinks of everything relevant. You are extremely great at doing that! (I totally forgot about Align.)

[GradualGames]

Hmm, I wanted to use mesen to debug some mmc3 irq splits, but instead I got a surprise. Never saw this glitch before (big yellow rectangles).

trophy_001.png (4.02 KiB) Viewed 3282 times

Let me know if I could privately supply a ROM or anything of that nature. Don't see this on fceux, nestopia, nintendulator, NES or AVS.

[Sour]

Is this with 0.9.5 or one of the recent appveyor builds? If 0.9.5, Mesen is pretty mean on state initialization for MMC3 and that might be your issue. If it's a recent build, it mimics FCEUX for its default initialization (mostly because some MMC3 clones appear to expect that state at power on) but adds an option to randomize the mapper's state at power on (in Emulation->Advanced).

Either case, it could very well be an issue with Mesen (e.g maybe some heuristic is detecting the game incorrectly) - feel free to PM (or e-mail) me the ROM and I can take a look on my end.

[GradualGames]

Is this with 0.9.5 or one of the recent appveyor builds? If 0.9.5, Mesen is pretty mean on state initialization for MMC3 and that might be your issue. If it's a recent build, it mimics FCEUX for its default initialization (mostly because some MMC3 clones appear to expect that state at power on) but adds an option to randomize the mapper's state at power on (in Emulation->Advanced).

Either case, it could very well be an issue with Mesen (e.g maybe some heuristic is detecting the game incorrectly) - feel free to PM (or e-mail) me the ROM and I can take a look on my end.

I think I may have inferred what could be going on. It appears as though in some cases the game is behaving like it is in vertical mirroring mode, however the game exclusively uses horizontal mirroring. I realized my game never writes to $A000 with a "1", yet it has been working just fine in several emulators, NES and AVS despite this (not counting other bugs I'm looking at right now).

[GradualGames]

Is this with 0.9.5 or one of the recent appveyor builds? If 0.9.5, Mesen is pretty mean on state initialization for MMC3 and that might be your issue. If it's a recent build, it mimics FCEUX for its default initialization (mostly because some MMC3 clones appear to expect that state at power on) but adds an option to randomize the mapper's state at power on (in Emulation->Advanced).

Either case, it could very well be an issue with Mesen (e.g maybe some heuristic is detecting the game incorrectly) - feel free to PM (or e-mail) me the ROM and I can take a look on my end.

I think I may have inferred what could be going on. It appears as though in some cases the game is behaving like it is in vertical mirroring mode, however the game exclusively uses horizontal mirroring. I realized my game never writes to $A000 with a "1", yet it has been working just fine in several emulators, NES and AVS despite this (not counting other bugs I'm looking at right now).

Bam, that was it. I wrote a "1" to $A000 and Mesen is happy now.

[Sour]

Yea, that's the behavior I would expect if you don't initialize $A000. Other emulators might be defaulting to the mirroring flag you set in the header - that flag is completely ignored for MMC3 as far as Mesen goes.

Are you testing on an authentic MMC3 chip (e.g not a repro of sorts), or on an Everdrive/Powerpak? I don't believe the MMC3 gives any guarantees as to its power-on state as far as mirroring goes (at least, the wiki says nothing about its power on state)

[GradualGames]

Yea, that's the behavior I would expect if you don't initialize $A000. Other emulators might be defaulting to the mirroring flag you set in the header - that flag is completely ignored for MMC3 as far as Mesen goes.

Are you testing on an authentic MMC3 chip (e.g not a repro of sorts), or on an Everdrive/Powerpak? I don't believe the MMC3 gives any guarantees as to its power-on state as far as mirroring goes (at least, the wiki says nothing about its power on state)

I have been testing with a PowerPAK, but never observed this issue, so I wonder if it is reading my iNES header like an emulator might? I mean I guess it must be in order to program the mapper before booting the game.

This was my first time trying Mesen this evening, and I just learned how to import ca65 debug files. Um...

THANK YOU.

[Sour]

No problem - that's what it's there for :p

Also, if you haven't noticed it already, there's a "Source View" toggle in the right-click options in the code, which should allow you to debug the original source code rather than the disassembly.
If you're trying to debug the timing of PPU writes, the "Event Viewer" might be useful too, if you haven't looked at it yet.

[UltraEpicLeader100]

ok but is it compatable with gamepads?

[NewRisingSun]

It might be desirable to explicitly define in NES 2.0 whether for boards with mapper-controlled mirroring, the iNES header's Mirroring bit is supposed to be ignored or is supposed to denote the initial mirroring state.

[lidnariq]

header's Mirroring bit is supposed to be ignored or is supposed to denote the initial mirroring state.

I really want to believe that we won't find two otherwise-identical variants of hardware that do that.

[tokumaru]

Yeah, I'm pretty sure that this information can be inferred from the mapper...

[NewRisingSun]

Somebody must be thinking otherwise, because a great number of Mapper 4 ROMs out there are set to Vertical Mirroring (the "bit set" setting), and I'm not talking about Mapper 206 games that are still set to 4.

[tepples]

I can think of one physically motivated interpretation of the iNES mirroring bit on carts with mapper controlled mirroring:

• If the chips used for this game came from a batch where the mapper register happened to default to vertical mirroring, set it to vertical.
• If the chips used for this game came from a batch where the mapper register happened to default to horizontal mirroring, set it to horizontal.

[lidnariq]

Somebody must be thinking otherwise, because a great number of Mapper 4 ROMs out there are set to Vertical Mirroring (the "bit set" setting), and I'm not talking about Mapper 206 games that are still set to 4.

Do you have evidence that there are two different classes of games that rely on this difference? I'm not asking about whether people put a thing in the headers, but instead whether the information is relevant.