Mesen Core

Libretro Cores
#87

@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.

#88

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.

#89

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!

#90

@Sour

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.

#91

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:

1 Like
#92

And now it’s perfect. :slight_smile:

#93

Minor bug report here:

Using the “ram_retain” nes test cart http://forums.nesdev.com/viewtopic.php?t=13334, when RAM init option is set to random creates “random” screen artifacts.

(screenshots later if needed)

#94

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.

#95

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.”

#96

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.

1 Like
#97

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?

3 Likes
#98

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.

#99

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.

#100

works fine here. Did you update your info files?

1 Like
#101

info files?Let me try it.

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

1 Like
#103

Should it be of interest to anyone, I’ve finally gotten around to converting the Nestopia hack for Castlevania 1 (that was released last year by kya over on romhacking.net) to the HD pack format used by Mesen - so you can now play this with the Mesen core.

More info and link here: https://www.romhacking.net/forum/index.php?topic=24125.msg350980#msg350980

5 Likes
#104

Ah, that’s awesome! Way better than needing a hacked emu.

#105

Simply bad ass, I really hope the HDNES pack scene catches on like the MSU stuff for the SNES.

2 Likes
#106

Gall Force on Famicom disk system is constantly inserting/ejecting disks causing the game to pause.
Putting auto-insert to OFF gets around the problem, but just wanting to report it for science.

#107

Thanks - I’ll take a look when I get the chance. Can’t promise I can fix it, though, since the auto-insert feature is essentially a hack that tries to predict what the game is trying to do. Some games might be hard to support if they behave differently from all the others.