Mesen Core


I would expect those to be patch files, as well. You could try opening one with a hex editor and see if it has any headers, etc. that are human-readable. Otherwise, I think IDA uses dif for patches, so you might be able to use one of the patching utilities that’s compatible with that format.


Issue: image is not resized to correct aspect when returning to Auto in quick menu > options > Region:

What happens: When starting the core with Region in Auto, (for example an NTSC content is loaded), moving to PAL/Dendy changes aspect as well as timing as its suppose to. But when returning to Auto, only timing is restored, but not the aspect. Similar thing will happen if you move to PAL/Dendy and press START to restore default value(Auto in this case) will only restore timing, but not aspect-have to press Auto again(while in Auto) to restore original rom timing/aspect.


@Sour, I did. :+1:t2:


As tatsuya pointed out - When the NTSC filter is enabled the overscan cropping feature is only cropping the bottom/right hand sides, so the junk that should be cropped on the top and left is still visibile.



@Tatsuya79 @Typhon @butanebob Thanks for the reports, the overscan issue with the blargg NTSC filter should be fixed in the next build.

@wertz Thanks, this should be fixed too.

@SigmaVirus I took a quick look at puNES’ code, it looks like the .dif files are in a custom format. Essentially, it’s just a list of modifications done to the original file, 1 byte at a time. It would take some effort to convert them since they seem to be applied to the FDS file after the emulator parses it into multiples disk “sides”, rather than on the original .fds file itself (i.e it doesn’t work the same way as Mesen/Nestopia do)


@Sour I noticed a visual glitch when using the Mega Man 3 Improvement hack that happens in Mesen but not Nestopia. On the stage select and sometimes when you bring up weapon select (like in Snake Man’s stage) the bottom 1/3rd of the screen jitters up and down. I think it’s due to this fix mentioned in the hack’s readme:

** Scanline glitch fixed on Weapon Menu screen, Stage Select (on Shadow Man picture), Wily Machine battle, Wily-Gamma battle, Game Ending (Right side of grass field)

Curious if it’s just an issue with the hack not being tested on hardware or not. On the patch page’s change history, kuja killer mentions someone wanting to put it on a real NES cart and doing some updates.


It’s hard to say for sure, puNES/Bizhawk don’t appear to have the issue either, but Nintendulator behaves like Mesen. All 4 emulators (excluding Nestopia iirc) pass all of the MMC3 IRQ tests blargg created some years ago. This is probably a case of being 1 PPU cycle (1/3rd of a cpu cycle) too early or too late on a CPU write that must occur before/after a certain point in the PPU’s execution. Without testing on an actual MMC3 chip (i.e not a powerpak/everdrive), it’s impossible to know which one of the 2 behaviors is correct. And that would require removing the chips from a real MMC3 cart and replacing them with something that can be reprogrammed, so not something that’s easy to do, unfortunately.


Interesting. Well, until someone with the hardware confirms the correct behavior, I guess it’s not enough of an issue to dissuade me from using the hack. Thanks for looking into it!



Thanks for looking into it!

It’s a shame really, I got literally perfect saves in puNES and I got no way of passing them over to Mesen or Nestopia.

This kind of dilemma makes me wish even more that all NES/FC/FDS emulators had the ability and option to write directly to the .fds disk dump. If that had been the case all I could do is to copy my .fds games and load them with the saves.


This core is already near flawless. As is, it is already my go to NES emulator. I didn’t even know about it a couple weeks ago. Amazing work. :slight_smile:


And now it’s perfect. :slight_smile:


Minor bug report here:

Using the “ram_retain” nes test cart, when RAM init option is set to random creates “random” screen artifacts.

(screenshots later if needed)


That’s not an actual bug, as far as I know. The sprite ram is not initialized by the ROM, so it keeps the random values. On a NES, sprite ram decay would probably make it so that the sprites don’t actually show up (and in fact the sprites disappear if you turn on sprite ram decay emulation in the standalone build). And sprite ram’s boot state may not be quite as random on a NES as what this option makes it out to be.


What is Mesen’s sample rate for the libretro core? It seems a lot of cores hardcode to 44.1khz but 48khz is the default windows and retroarch sample rate. The sameboy dev recently did this to improve audio quality, I’m curious if other cores do anything like this to reduce resampling

“Just pushed a commit that redid the way the libretro port did audio. Audio is now sent to libretro at 384KHz, which is then resampled by RetroArch to whatever rate the user configured. This should greatly improve audio quality on the RetroArch port, which by this commit should sound even better than the standalone versions.”


It’s set to 48khz at the moment, but it’s an arbitrary limit - the code supports 96khz, too, and adding higher sample rates is trivial. Since RetroArch may do its own resampling, I can see how that could help improve sound quality. I’ll see about raising it and whether or not it affects performance (probably not much at all) - technically the NES’ sample rate is the CPU’s clock rate, but that would probably be a bit overkill.


Setting the sampling rate in the core to be 384KHz results in a ~2% slowdown, it’s relatively negligible, but not ideal considering it’s already the slowest NES core (and slower CPUs with less cache, etc may be affected more severely). Maybe an option for this would make sense?


I’m not really sure if it should be an option or not but I’d definitely check it out if it was. 48khz as the default should work for the far majority but maybe the option could help others. I just wanted to make sure 44.1 wasn’t the default. It’s nice to know what the performance hit is for it though.

Thanks for doing such a great job on the port and already including retroachievements.


Did anyone test the X64_86 version of LINUX?It looks like it can’t work. When the.Nes file is loaded on the Linux x64_86 version, the core of the Mesen does not appear at all.


works fine here. Did you update your info files?


info files?Let me try it.

After upgrading to the latest version, the problem is solved! Thank you for the help of hunterk!