Mesen - Emulator

[raousoft]

Thank you Sour for all the efforts you are doing despite your lack of time.
I am working on a translation for the emulator (almost done), just for fun and enjoying opening those avalonia views :3

[007]

@sour one more small bug this time nes.

Launch a nes game

Set filter to ntsc bisqwit first then go tonoverscan and use up down arrows to set over scan areas. Crash.

Work around is for user to set this with filter off then turn on for now.

*** fixed latest dev build

[007]

One more small bug i noticed.

NTSC biqwit is nes only.

It can only be used on nes.

So load nes rom.

Exit

Load lets say pce rom.

Now NTSC bisqwit is greyed out however it is selected and active.

Would it be possible to maybe have mesen store per core filter options?

[Sour]

I noticed one of the recent commits was related to DPI-related crash. Maybe it's relevant that I'm running at 150% scaling? I'll give it a try at 100%.

I'm running at 150% DPI and don't get either issue on my end, so it's probably not DPI-related. Did you get a chance to check if you have similar issues on your other PC?

In this case I'm using the llvm-mos compiler. I don't know if it's llvm-mos-specific or if it's a general llvm thing, but the compiler emits the full range for functions, presumably assuming tools would handle them gracefully.

It seems like in this case, instead of using it to generate labels for every instruction, Mesen could use it to mark regions as code.

The multi-byte labels in .mlb files (and the debugger) aren't really intended to be used to define anything other than data arrays at the moment. So llvm-mos probably shouldn't be exporting functions as multi-byte labels in its .mlb export, but rather a 1-byte label at the address the function starts (especially since overlapping labels aren't allowed, meaning any jump label inside the function would be lost if you had a multi-byte label overlapping the entire function)

1941 SGX first level water is missing level looks black

Thanks! A small fix I did a few weeks ago had broken SGX games. Thanks for the other reports, too.

Now NTSC bisqwit is greyed out however it is selected and active.

Would it be possible to maybe have mesen store per core filter options?

This is the intended behavior atm - when bisqwit's filter is selected, it defaults to using blargg's filter instead when running games on other platforms (since bisqwit's can't be used). Having console and/or game-specific settings has been requested in the past, it's something I might add in the future, but not a priority at the moment (allowing this without duplicating a lot of configuration in the UI and/or making it less intuitive to use is a bit of a challenge)

[007]

@Sour thanks for all the fixes and everything!

The NTSC seems to stick in Bisqwit and not flip back to Blargg


I thought I remembered it flipping before. Like it shows selected even though not selectable.

That old behaviour i believe the selection would show it moved to blargg.

And you are welcome, Im only reporting in hopes that it helps. Im a big fan of your work.

Also tiny request, maybe add commit next to build info in help about?

[007]

@sour


Noticed another small bug in nes under the gui

Emulation setting nes

Default power state for ram.

Random is listed at default. (And I believe this would be most accurate)

However on a fresh install fresh run the default is set to 0.


To be clear i think the default value is wrong by mistake. Or if it is all zero on purpose the word default needs to move

[DoctorMikeReddy]

Any chance of getting this to work with Alchemy65 for debugging? Am using the MacOS build and getting Lua and timeout errors when trying to launch from VSCode

[007]

attached is a image of where i see mesen listing a default but then selecting a different default

[gzip]

Hey Sour,

Glad to see that you're still checking in here and plugging away on github, even if it's a bit slower than you'd like. I updated a few weeks back and have been running into a minor bug so thought I'd report it...

In Memory Viewer under the File menu, Save ROM is listed as Ctrl+S but using that key combination actually opens a Save As dialog for a DMP file.

Ah, just noticed that the File menu also lists Export as Ctrl+S first, so that's what's winning. Not sure that Export really needs a keyboard shortcut but maybe it could change to Ctrl+X.

[Sour]

That old behaviour i believe the selection would show it moved to blargg.

As far as I know, it's always been this way. I'd rather it not flip back to blargg when loading a non-NES game, since then you'd have to re-select bisqwit's filter the next time you load a NES game.

Also tiny request, maybe add commit next to build info in help about?

This is probably a bit more effort than it's worth, since it would require changing build scripts and the like. The build's date/time should generally be enough to know what commit it was done on.

Random is listed at default. (And I believe this would be most accurate)

The problem here is that different cores have different defaults, but they all share the same texts. NES defaults to 0 at power on (because that's what the behavior was before I introduced that setting a long time ago in mesen), while everything else defaults to random ram, I think. I'm aware of the issue, but haven't really decided what the best fix would be yet, and it's not too much of an issue (a user that's not a homebrew/romhack dev shouldn't be changing any of these settings in the first place)

Any chance of getting this to work with Alchemy65 for debugging? Am using the MacOS build and getting Lua and timeout errors when trying to launch from VSCode

I know changes were done in the Mesen-X fork to the Lua api to support this extension, but I was never involved in its development and the v2 Lua api might be slightly different/incompatible with what this extension expects (I don't know, I've never used it or looked at its code). It's not something that I'm planning on adding support for, at the moment.

In Memory Viewer under the File menu, Save ROM is listed as Ctrl+S but using that key combination actually opens a Save As dialog for a DMP file.

I think you might have edited the shortcuts on your end and set Save ROM to be Ctrl-S? There is no default shortcut for save rom in the code, so there shouldn't be any conflict when using the default settings.

[DoctorMikeReddy]

I know changes were done in the Mesen-X fork to the Lua api to support this extension, but I was never involved in its development and the v2 Lua api might be slightly different/incompatible with what this extension expects (I don't know, I've never used it or looked at its code). It's not something that I'm planning on adding support for, at the moment.

I’ve forked both and will have a look at the diffs and the Lua incompatibilities. First off, socket generation seems to be the initial obstacle. I’ll see if I can fix it

[007]

@sour if thats the case with random vs 0 why not just remove the text claiming default? It will prevent confusion for ppl not reading this

[gzip]

I think you might have edited the shortcuts on your end and set Save ROM to be Ctrl-S? There is no default shortcut for save rom in the code, so there shouldn't be any conflict when using the default settings.

Yep, that was it. I brought over my previous settings when I updated and forgot that Debugger has more shortcuts in it's settings panel. I was able to remove the export shortcut to get the behavior I was looking for.

[NovaSquirrel]

I'm currently experiencing a bug in the tilemap viewer on Windows 10, where hovering over a tile will cause the emulator to immediately lock up when it tries to open up the tooltip, resulting in a rectangle that appears but is just blank (sometimes it does work for a brief moment). Looks like this was previously reported but I noticed that it only seems to happen in certain circumstances so I can write about that:

It's happening consistently for SNES mode 7 maps, but not mode 0, 1, 2, 3, or 4. It's also happening on PC Engine, but not Game Boy or NES. Using the tilemap viewer on an NES game before the SNES or PC Engine game prevents the lockup.

[Sour]

First off, socket generation seems to be the initial obstacle. I’ll see if I can fix it

Sockets should be working normally - but you need to turn on an option for it. I've disabled some portions of Lua by default in an effort to avoid potentially malicious scripts from having too much of an impact (access to the disk & network are disabled by default). This might be why you're having issues?

Frequent crashes when the tilemap window is open, triggered by mousing over the window.

This should (hopefully) be fixed now - I was able to reproduce the issue thanks to Nova's post above and made a fix that appears to fix it both on my PC and Nova's.