nesdev.com

The debugger is very nice (though a bit slow on my old comp). Thank you.

Is this the most accurate nes emulator?

Whats the bsnes of the nes world?

_________________
...

There isn't one best-of-breed NES emulator.

I'd say you'd be pretty well off with any of Nestopia, Nintendulator, puNES, or Mesen.

Although to be quite honest, if you're not doing development, FCEUX is plenty accurate.

Mesen right now finishes all those emulator test ROMs perfectly that others don't. Stock Nintendulator, thought of being the most accurate of the older emulators, still has CPU/PPU synchronization very slightly off. Don't know about puNES.

It's hard to say what's the "most accurate" - the reality is that many have similar accuracy and will run the majority of licensed titles without any issues (arguably, a lot of them might have "bsnes-level" accuracy in terms of NES emulation). For NES development, I try to make Mesen as "mean" as possible so that game devs can at least feel relatively confident that their code should work on a real NES, too.

As far as test roms, Mesen passes more or less all of them - but that doesn't mean it's "perfect". There are definitely a number of things (e.g stuff that no game would ever rely on) it doesn't simulate anywhere near perfection. Trying to emulate every single detail would incur too much loss of performance to the point where some older computers might have trouble running it (esp. with the debugger tools active). At this point, I try to limit any "improvements" to accuracy to either things that have little to no performance cost or things that actually matter in real games (licensed or not)

Hi Sour.

I'm not familiar with Mesen. I'd like to trace Rc Pro-AM II and compare the log with my emulator. This game is unplayable in RockNES. How do I generate a trace log?

Open the debugger (Tools->Debugger) and then the trace Logger (Tools->Trace Logger).
There are a few options to configure what's shown in the log (if you're using one of the latest dev builds you can customize the format).

Just press "Start Logging" to select a file & create a trace log.

I don't know if it's different in the latest dev build, currently using Mesen Version: DevWin-0.9.5.139, but, to open the Trace Logger I always had to click Debug>(the only option) to then click the Trace Logger icon inside of the Debugger that opened.

But, after clicking Options>Preferences and checking the last box, under General, "Enable developer mode",

then you just simply reopen Mesen, click Debug>"Trace Logger" and have fun trace logging.


My penultimate post in this thread, I think, holds my current "Format: Override" line, if you are interested.
edit: Sorry, it's in the second post from the top of page 26. Just want to correct my mistake. : )

final edit.

I will now post in this thread since it is related to emulator specifically. For now I'm not able to make it work on mac yet. With wine bottler 2.0, it can start but the screen shows nothing. I still think is my computer that is missing something so I will try to test more and share my results.

One question I have is I was able to test the debugger, which is nice when you load the symbols from the dbg file but I don't seems to find anything that show the current sprite, pattern table etc. Either I missed a menu or mesen doesn't have that yet?

There is a display bug on linux, text gets overlapped for the imported symbols. I will share a screenshot once I have the time to test it again.

Thanks for the effort in trying to get it to work on macOS - I'm definitely interested in figuring out a viable way to run it (whether it's Wine or Mono). I'll try to make a SDL build for Windows (I should be able to reuse most of the Linux code for this) - that might help fix the display issues (e.g by taking DirectX out of the equation).

The debugger needs a monospaced font to display properly (this is probably what's causing the issues on your end) - under Linux it should usually try to install and use that one by default, but this might not work for all setups. You can manually select a monospaced font in Options->Font Options->Select Font, which should solve the display issues (you will have to select the font separately for each debugging tool)

There are a bunch more tools (documentation is available here) beyond the main debugger available in the debugger's "Tools" menu. You can also make them available in the main window by turning on "developer mode" in Options->Preferences (from the main window). The PPU viewer is used to show the PPU's nametable/chr/sprite/palette.

Edit: On macOS, are there any errors shown in Tools->Log Window after you try to start a game?

I knew I saw them somewhere! My bad, I think I need to learn to read the manual As for the display issue, yep, it was the font. The default set on my distribution was deja vu sans so once I selected my favorite mono font everything was fine. There is so many new options now with the developer mode, I feel like a kid at a candy store



I didn't check that since I Was not aware of that option. For now I only tested with wine (3.0 with brew/2.0 wine bottler) if I could start it on not. Bottler with some .net framework did start but no screen. Now with all the new developer options, I really need to put more time to figure out the cause. I will share the logs once I can access my home computer tonight.

So I did a bit of Wine testing on my Ubuntu 18 VM using Wine 3.0 (32-bit mode) and .NET 4.6 (installed by using winetricks).
Mesen 0.9.5 runs - sound is fine, graphics are scaled incorrectly (~80% of the viewport is black - potentially a Wine DX11 bug?)

I also built a (terrible) 32-bit SDL2 windows build that still uses DirectX for gamepad input, but uses SDL2 for the graphics/sound.
This one shows the video properly, but the sound seems sort of broken (it's a VM though, so that could potentially be a part of the problem). You can grab this build here if you want to see if it works any better than the DX11 build on your end.

In both cases, though, the debugger window seems to be somewhat sluggish (at least, compared to using Mono on the same VM) - hopefully this might be partially caused by the VM rather than Wine. The emulation itself is running around the same speed as when I run the same SDL build directly on windows 10, though.

This what the issue I had with wine on 18, the graphics were not scaled properly. As for debugging, I remember being sluggish even on a i5 8th gen 4 core so maybe it was not the VM but wine per se. I will re-test the debugger with mono then wine and see how sluggish they are. But since I never really tested on windows with the same specs, it's hard for me to judge how they are supposed to be when they are working properly.

I will test this build and see how it goes.

edit:

Maybe I should try this build on osx too?

edit2:

I did some quick tests during lunch and:
- the original build is fast with mono
- the original build when launched with wine, is horridly slow
- the sdl build when launched with wine is horridly is slow too

I will test both build on the mac to see if they have performance issues.

Edit3:

I'm starting to do some test on the Mac. With Mono 5, for now it fails so more research is necessary. I tried it on windows and the speed is light and day, even on a 10 years old computer so now I can confirm that there is some performance issue with mono, except that it is still usable. Some of he pop-up that shows information are a sluggish but usable. The debugging itself is fine for now but like I mentioned it, I was testing it on a recent computer so maybe I should try on that same 10 years old computer with linux and see the performance impact on older machines.

I will try to do more research for mac. For now I cannot confirm if the cause is my configuration or the emulator with wine/mono that have issue yet.

Edit4:

Was able to install .net 4.5 with wine 3 but after starting, wine fails. I think I will try to reinstall wine 3 since I was never able to use winetricks with the UI properly anyway.

For wine 2, this is the error:
D3D11CreateDeviceAndSwapChain() failed - Error:-2147467259

For sdl version I have a different error. It says something when launched (screenshot):


The application launch after but it doesn't do anything when you load a rom. With the normal version, at the least the sound is working. Both have this issue when launched (maybe this is nothing):


Now it's 2h in the morning and I need to work tomorrow so I think I should go to bed and continue testing another day

I'm assuming this might just be because that version of wine does not support DX11 properly?
This one's a bit odd. InitDll is a function that was added relatively recently (but it should be present in the SDL build). At least, as far as I can tell, the SDL build works properly in both 32-bit and 64-bit environments on my end (I'm assuming you're running Wine in 32-bits?)
That doesn't sound too good - Mesen's .exe contains an embedded .zip file which contains a number of resources/DLL files. It looks like the code is crashing while attempting to extract data from the zip file.

Thanks for taking the time to test all of this. If you can't get Wine 3 to work, it might be worth trying to get the native Mono+Linux+SDL build to compile on macOS (e.g by running make). The only major issues that should exist are 1) the code in FolderUtilities.cpp that uses the experimental filesystem API (which isn't available in the version of clang macOS currently ships with) and 2) the code to handle gamepads (which relies on Linux-specific stuff). Both of these are pretty easy to remove.

Also, I'll try to profile the code when it's running under Wine to see if I can find any obvious performance bottlenecks that I could work around.

Wine's DX11 support is still very beta and still only marginally useful. :/

I was testing with a 32-bit profile because I think you mentioned something about it. I can redo the test with a 64-bit one.

I will try to reinstall wine3 to see if I have any better luck with it. As for dx11, what feature of dx11 does mesen uses? Is there a way to do a quick test with a lower one to see if it does any difference on the mac with wine? If not then that's ok too.

As for compiling, I can see once I can find the time. Regarding clang, if it does require a newer version, it may be possible to install it with brew.