Mesen - NES Emulator

[NewRisingSun]

After changing the header to say no work ram (I thought a discussion a long time ago had concluded that the internal RAM for this mapper shouldn't be counted in the header? Unsure.)

No, the internal work RAM should be specified, and must be specified for games that battery-back only the internal RAM and use it for save-game purposes, such as Mindseeker. The only time that the internal work RAM is not specified is when there is both internal work RAM and 8 KiB of WRAM and both or neither are battery-backed, to prevent the non-power of two size from having to round up. For all these games, such as Megami Tensei 2, it's also possible to denote the 128 byte of work RAM as non-battery-backed (since the games will not use it for save game data but for sound or not at all, which I verified with every single game), and the 8 KiB of WRAM as battery-backed. And you need to specify the 128 byte of battery-backed EPROM in Mapper 159 as well.

I have modified the N163TEST rom to run from $E000. Mesen's N163 emulation does not seem tor emulate the situation in which only one channel is enabled accurately, though, as I cannot hear anything in that situation.

[gauauu]

I've been getting quite a few crashes on Linux/mono ever since upgrading, to the point where it's pretty unstable. Attached is a sample crash report (this time from me pressing Ctrl-T to reload the game, but I haven't seen a reliable pattern for when the crashes occur).

This is with the 0.9.6 github build.

Thanks!

[Sour]

I have modified the N163TEST rom to run from $E000. Mesen's N163 emulation does not seem tor emulate the situation in which only one channel is enabled accurately, though, as I cannot hear anything in that situation.

Thanks! The sound output was in fact disabled when only 1 channel was enabled - this should be fixed. The test rom appears to work properly now, but I haven't compared with other emulators. I also fixed the crash that the 128 bytes work ram header was causing.

I've been getting quite a few crashes on Linux/mono ever since upgrading

That crash seems to imply that this is caused by Mono crashing while trying to process the regular expressions I use to read the .DBG files, which is very odd. Most of the other threads in the process seem to be paused, so it seems unlikely that they would be causing issues, either.. Can you try disabling the "auto-load .DBG files" option to see if the crashes stop?

I just tried getting it to crash on Ubuntu 18 by power cycling on a ROM with a .DBG file but couldn't. I'm assuming you haven't upgraded mono, either?

[gauauu]

Can you try disabling the "auto-load .DBG files" option to see if the crashes stop?

Yeah, it hasn't crashed since I disabled that.

I'm assuming you haven't upgraded mono, either?

Not that I know of, although I blindly click "update all" when the package manager says there's updates, so....it's possible that I have without noticing.

[Sour]

What version of mono are you running? (I have 4.6.2 on my Ubuntu 18 VM)
How easy is it to get it to crash? e.g if you just keep power cycling the rom with the debugger opened, does it eventually crash?

From what I read, this particular crash seems to be caused by Mono's garbage collector crashing for an unknown reason. It's possible that Mesen's C++ code is somehow corrupting memory and causing Mono to crash, though, but it is somewhat unlikely..

[gauauu]

What version of mono are you running? (I have 4.6.2 on my Ubuntu 18 VM)

Mono JIT compiler version 4.2.1 (Debian 4.2.1.102+dfsg2-7ubuntu4)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. http://www.mono-project.com
TLS: __thread
SIGSEGV: altstack
Notifications: epoll
Architecture: amd64
Disabled: none
Misc: softdebug
LLVM: supported, not enabled.
GC: sgen

How easy is it to get it to crash? e.g if you just keep power cycling the rom with the debugger opened, does it eventually crash?

Yesterday it was doing it every 5th or 6th time I power cycled, and occasionally doing other things. Today (even with re-enabling auto-loading .dbg files) it hasn't crashed while I've done just silly things like spamming the power cycle button. I'll leave it turned back on and see what happens.

[gauauu]

Today I was just clicking around in the CHR tab of the PPU viewer when it crashed. Dump attached. If you'd rather I put these on github, just let me know.

Thanks!

[unregistered]

Sorry gauauu for interrupting your conversation with Sour.

Sour, after installing 0.9.6 the last two trace log files I've made today are extensionless. Why? It was changed from .log to .txt and that was ok, but now, when opening new trace log files, I have to select notepad from a list and resize notepad's window and change the font. Either that or I must type ".txt" at the end of every new trace log filename, I guess; haven't tried that yet. So I was wondering, would it be terrible to add a blank and a .txt and a .log to the empty Save as type: menu that's underneath the File name: menu? It seems to me that Windows 10 can remember Save as type: choices.

I'm asking you that because I don't understand anything about creating programs that run on many different system types.

[Sour]

Today I was just clicking around in the CHR tab of the PPU viewer when it crashed.

This looks like its essentially the same problem (mono crashing while trying to allocate managed objects). Could you try running an older 0.9.5 dev build (e.g one you were using before, or one from the appveyor builds) to see if the crashes really don't happen with it?
Or maybe it only happens when you have specific tools opened? e.g this crash implies you had the PPU viewer opened.

Sour, after installing 0.9.6 the last two trace log files I've made today are extensionless.

I think this is probably because you manually changed the output file's name? It won't add the .txt suffix automatically because the "file type" dropdown is empty. As far as I can tell though, it's been this way ever since I changed it from .log to .txt and let users choose the filename, back in March 2017. It's essentially caused by a typo in the code - the latest commit fixes it.

[unregistered]

Thank you so much Sour!! I guess, I must have done something wrong like you said. The latest commit does add the .txt to the Save as type: menu box!

Now, I know that a "commit" is your AppVeyor release.

edit: note: commit history page click on commit you want, then click on "ARTIFACTS" button to receive download link. (The latest commit is built from the previous successful commit, I think ) Feel free to delete this edit if you want to.

[gauauu]

Could you try running an older 0.9.5 dev build (e.g one you were using before, or one from the appveyor builds) to see if the crashes really don't happen with it?

I've swapped back to the old build and no crashes yet. I'll let you know if that changes.

[geod]

I tested Super Mario Bros with Mesen, run the character at max speed and observed 3,4 screen glitches just in the first level 1-1.
Tested with normal window and 2x scale window. My PC is Virtual Reality Ready. It seems to me that there are frame drop here and there.
Is this Mesen's normal behavior?

[Sour]

I'm not too sure what you mean by screen glitches. If you just mean that some frames are skipped, then yes, that's possible, especially if you don't have vertical sync turned on.

Edit: Also, since the NTSC NES runs at 60.1fps, turning vsync on will still result in a dropped frame every 10 or so seconds under ideal conditions.

[lidnariq]

Maybe you want to emulate the CPU at 341.5*262*4*60 = 21441960 Hz instead of 39375000*6/11 Hz?

[Sour]

There is an option for this already (in the video options), it will run at exactly 60.0/50.0fps when turned on, rather than the standard ntsc/pal frame rates.