Mesen - NES Emulator

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

Sour
Posts: 891
Joined: Sun Feb 07, 2016 6:16 pm

Re: Mesen - NES Emulator

Post by Sour »

mkwong98 wrote:No, I'm asking for some way to compare the h/v flip of the two tiles in the spriteNearby condition, not just the relative x/y position
So basically you want to be able to apple the spriteNearby/spriteAtPosition conditions only when the target sprite (e.g the one at the specified location) is mirrored horizontally or vertically? I'll try to figure out the best way to get this done (in terms of hires.txt specs).

For the rest, it should all be taken care of:
-The bg priority sprite bug should be fixed (but the behavior is still different compared to what it was before - it should allow your use case & kya's use case to both work properly).
-All conditions can be prefixed by ! to invert their meaning. e.g: [!hmirror]<tile>[...] This works for user-defined conditions, too
-I added Y/N flags for mirroring to the sprite copy feature
mkwong98
Posts: 282
Joined: Mon May 30, 2011 9:01 pm

Re: Mesen - NES Emulator

Post by mkwong98 »

Thank you very much! Can you give me a download link?
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Mesen - NES Emulator

Post by rainwarrior »

Now that I'm finishing up with the project that has consumed the last few years of my life, I've been getting used to some new things and trying out Mesen more. I really like it a lot, and I might even jump ship from FCEUX for my daily use. The main noticeable practical difference for me at this point is just that it seems to use about 3x the CPU power as FCEUX in my measurements, but that's still a pretty acceptable level of performance. (I'm a heavy laptop user, though, so battery consumption and fan noise make CPU usage a bigger deal for me than most people, probably.)

One request:

The Famicom input options don't let you replace the standard controller. Is there some reason this is restricted? The AV famicom had detachable controllers with the standard NES plugs, and there are some potentially useful combinations of that with the expansion port (e.g. Family BASIC keyboard + SNES mouse).

Conversely the NES does have an expansion port that is largely compatible with Famicom peripherals with some trivial rewiring. Is there a need to disable the expansion port option for the NES setting?


Second question:

Is there an easy way to download the documentation for offline use? (Similar reason about the laptop above, I'm often offline.)
Sour
Posts: 891
Joined: Sun Feb 07, 2016 6:16 pm

Re: Mesen - NES Emulator

Post by Sour »

mkwong98 wrote:Can you give me a download link?
I'll try and make a build tonight.
rainwarrior wrote:seems to use about 3x the CPU power as FCEUX
Is that with the New or Old PPU? With Mesen's debugger opened or closed?
3x seems like a lot - in my experience, FCEUX's New PPU seems to run roughly at the same speed as Mesen (e.g at 100% CPU usage I get about 350 FPS in Zelda 2), but maybe there is something about my computer that is making FCEUX slower than it should be.

To (mostly) remove the restriction on P1/P2, you can turn on "Use HVC/NES-101 behavior" in Emulation->Advanced (this allows the Mouse+Keyboard combos for example). There is no way to turn on the expansion port for NES though. The UI is mostly built this way for the sake of reducing the number of options for most users (NES users) and having proper open-bus behavior (i.e you can use tepples' allpads test and have it display every type of NES/Famicom by changing the settings) - Code-wise there is no huge reason for the restriction, though, I could probably lift them when "Developer Mode" is turned on or something akin.

For the documentation, there's no way at the moment - I'll have to take a look. (Just copying the files to a disk doesn't work properly due to absolute paths being used in the HTML output)

Edit: Btw, are you using 0.9.4 or the latest build I posted in the debugger feedback thread? Or did you build it yourself?
Bananmos
Posts: 552
Joined: Wed Mar 09, 2005 9:08 am
Contact:

Re: Mesen - NES Emulator

Post by Bananmos »

I've just discovered the ability to rewind/fast-forward, and the debugger. Just wow...

UndoDB here in Cambridge has built a whole company around the reversible debugging story, so it's not a feature I'd expect to see in a NES emulator*. But I'm loving it already! I've had quite a few bugs in the past that were tricky to reproduce and this will help a lot. Fast-forwarding/re-winding is also a nice way to look closer at movements and animations.

One thing that annoys me though: I haven't figured out a way to quickly reload the last ROM. So at the moment I go to recent files, and I then have to CTRL+R to make it start. Would be great if there was a quicker way to do this with a single button hotkey, that could be mapped to my joypad as well. (maybe there already is and I'm just being blind here)

* And yes, I know the NES being more memory-constrained can make the implementation simpler than a reversible gdb on x86. But it's still no less amazing to see it in action.
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Mesen - NES Emulator

Post by rainwarrior »

Sour wrote:
rainwarrior wrote:seems to use about 3x the CPU power as FCEUX
Is that with the New or Old PPU? With Mesen's debugger opened or closed?
Old PPU New PPU. No debuggers open, just started up in both cases. Edit: was wrong about this.

Yeah, I also gauged it roughly by using the fast forward features. With the limit taken off on Mesen, on the same ROM I was seeing a little under 400 fps on Mesen in fast forward, and about 1300 fps on FCEUX, pretty consistently.

On a more coarse level, measuring the same game running in attract mode on both, which probably more fairly takes into account rendering and everything else, the CPU usage is around 2.2% for FCEUX, and on Mesen it varies more but averages around 4%, so it seems to be a bit closer in more general usage (though fast forward is one of those 'constant use' debugging features for me). CPU usage with the debugger open seems significantly higher, though (~6% in Mesen, whereas in FCEUX it doesn't significantly affect performance).

Still pretty much double for me in that more fair condition, but it's still very reasonable CPU load. Probably not enough of a difference to keep me using FCEUX, I only really mentioned it because it's one thing that does stick out to me a bit. (How often a program makes my laptop fan speed up is a real metric for me. ;P)

Aside from that the only glaring difference seems to be the TAS editor, but while I use the movie playback feature a lot in FCUEX, TAS editor I only used very seldom. I really love that you have an input override in the debugger itself; that's really cool.

Similarly there's a "text hooker" feature which is really good if you're trying to translate something, but not really of use otherwise. If I was doing translation work (which I am not, normally), I expect this feature would keep me bound to FCEUX.

Also, I like that you mention open bus behaviour, since that's one area where FCEUX has no configuration (just outputs 0 at any out of bounds memory access) and kinda sucks.

The anti-aliased font rendering in the debug disassembly sticks out to me as well, but only because I disable AA wherever I can, so any non-native rendering is really glaring. Not a big deal for the disassembly part because the font is big and legible, but the small labels lose legibility very quickly if I make the text any smaller than the default. The option to view PRG address shrunken and below makes this a problem... I do want to be able to see both that and the CPU address more or less constantly, but it's a lot of vertical space to give up, and shrinking it makes it too hard to see. (Putting it on the left might be nice, but that in itself takes a lot of horizontal space in this font... FCEUX did a nicely compact hybrid address with a 'bank' prefix but it's annoyingly hardcoded as 16k banks, which sucked.)

In the memory view, would be nice to be able to e.g. right click and jump to the same location in PRG ROM and vice versa, or jump to it in the debugger disassembly (or vice versa). Having options like this on a right click and the ability to jump around quickly between address spaces would help with getting around a lot.

Could really use PC in the debugger's "go to" menus. That's the place I most often need to recentre the debugger on.

The debugger has keys that conflict with other things, e.g. F5 to resume conflicts with savestate stuff, which is a bit of a hazard. Wondering why Esc for pause isn't also resume in the debugger? As well, none of the debug keys seem to be in the shortcuts configuration?

These are all pretty nitty picks, none of them are even close to dealbreaking.
rainwarrior wrote:Edit: Btw, are you using 0.9.4 or the latest build I posted in the debugger feedback thread? Or did you build it yourself?
0.9.4 from the website.

Anyhow, still getting used to it, but I am really liking it. Thanks for making such a good debugging emulator!
Last edited by rainwarrior on Fri Mar 02, 2018 6:28 pm, edited 1 time in total.
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Mesen - NES Emulator

Post by rainwarrior »

Is there any way to customize the default set of debug register labels? I'm thankful that there's at least an address suffix on them but in general I find these make the disassembly harder to parse, visually.

I found the option to disable them, but I really love that you can put hover comments on the labels, so I actually like that part of them but... the names really get in the way for me. Would try to name them as just, e.g. "$2000" but apparently I can't start a label with a $ for some reason? (Still, even if renamed, they're just going to revert back to the default names the next ROM I open.)

Also the default names for the square registers both start with "Sq1" rather than being Sq0/1 or Sq1/2. (Famitracker users would probably be used to calling them pulse 1 and 2, but I'm sure many prefer 0 and 1 -- customizable default names would accommodate both.)

Going further down the wishlist hole, though, would be the ability to add new labels to the default set that are included automatically only if they match a specific mapper. You could document all the registers, have easy access to breakpoints, etc. all of that automatically without having to manually set up every time you open a ROM.
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Mesen - NES Emulator

Post by rainwarrior »

Re: debugging and CPU usage... it actually gets pretty bad for me if my laptop is not in full power mode.

Without the debugger open it's using about 50% of a core, and with any debug windows open it goes over 100% (with slowdown) and the audio becomes unlistenable (latency not a factor here, it's CPU bound). I could turn the audio off if I don't need it for debugging, but it's still maxing out the CPU core anyway. (I can debug with FCEUX with ~30% of a core at the same power settings.)

So... I guess for me the CPU usage does matter significantly when I'm on battery. :( No problem at all when powered or on desktop though. I really like Mesen otherwise though, will probably end up using both, FCEUX for when on battery. (For comparison, the non-debugging fast forward FPS is like 90fps Mesen vs 350fps FCEUX on battery.)

This is not a request to make if faster, BTW, just trying to measure and describe the situation as it exists for me. Optimize only if it's important to you. (All of my suggestions above are just suggestions, Mesen seems pretty good to me with or without future improvement.)
Sour
Posts: 891
Joined: Sun Feb 07, 2016 6:16 pm

Re: Mesen - NES Emulator

Post by Sour »

mkwong98 wrote:Can you give me a download link?
Here's a build with the HD Pack changes: download
Bananmos wrote:I've just discovered the ability to rewind/fast-forward, and the debugger. Just wow...
There's also a "Step Back" option that rolls by the execution by a single instruction, if you didn't notice it.
Bananmos wrote:One thing that annoys me though: I haven't figured out a way to quickly reload the last ROM.
Power Cycle reloads the ROM from the disk - you can map this to any key/button combination. I'm not sure why you need to reset after opening from the recent files, though? Does it not work properly otherwise?
rainwarrior wrote:[...]
Thanks for the feedback! Trying to respond to everything, but if I miss something important, let me know:

You probably should use the latest build (download), it does have a large number of additions/improvements (especially in the debugger, e.g syntax highlighting, the new code scrollbar, code preview in the tooltips, event viewer tool, etc.) compared to 0.9.4. (if you have negative/positive feedback on the differences with 0.9.4, let me know)

I guess there must be something with my FCEUX configuration that is causing it to be abnormally slow.
Opening the debugger in Mesen does impact performance a lot - this is because it turns on a lot of stuff (trace logger, profiling, CDL logging, access counters, etc.). This is why you can open the trace logger and immediately see the execution's history (vs needing to start it beforehand in FCEUX, for example). It's a bit of a compromise between usability & performance. It might be possible to add option to disable some of these to improve performance a bit - I'll see if it makes a noticeable difference. I might also be able to move the processing for some of these to another thread, but Mesen already uses 2+ threads for the emulation itself, and a lot of the debugger runs in other threads, so arguably might not make too much of a difference on a dual core CPU.

TAS Editor/Text Hooker - Yea, these are more or less the last 2 tools that are missing. I do want to get to those eventually, but a TAS Editor, in particular, would probably take a lot of planning to get right. Fun fact: you can play .fm2 & .bk2 (bizhawk) movie files in Mesen (the UI doesn't tell you this, but it will accept the file if you select one). FCEUX movies tend to desync most of the time, though.

To go to the PC, you can double-click the top of the callstack or use "Show Next Statement" (Alt+*).

The shortcut keys for the debugger are a UI-side feature, while the rest of the shortcuts are a C++-side thing integrated with the emulation core. Ideally, I do want to add the ability to customize them, though. The keybindings at the moment are mostly meant to mimic's Visual Studio's default keybindings for C#.

The code window (and a lot of other things) all use GDI+ (this is what most .NET drawing routines use), maybe GDI+ doesn't respect Windows' own anti-aliasing settings? There is also a .NET function to draw strings with GDI instead of GDI+, but it is slightly slower according to the tests I've done, which is why I've stuck to GDI+ so far. Maybe there is a simple way to make fix the anti-aliasing, I'll check.

Memory Viewer navigation: Should be easy to add those.

PRG ROM display: I'm not sure what to suggest here - a bank number is vague in a lot of situations. Do you need this information to always be visible? Or would it being shown in a tooltip be sufficient? (e.g on mouse-over on the cpu address?)

Customizing the default labels: That might be nice, though it might be a pain to edit them in the UI. Maybe allow a simple XML file to be put in Mesen's debugger folder to configure the default workspace on a per-mapper basis? Labels can't start with $ because it would just be confusing when trying to parse what's under the mouse. Ideally, would need to allow the label to be blank (this is possible to define comments in the code) and allow the comment to show in the tooltip for an address that has a comment (it doesn't at the moment).

Performance: At the moment, Mesen is more or less optimized to the limits of my ability (I've spent dozens of hours profiling & optimizing the emulation core) - at this point, making the core any faster would probably require attempting to reduce cache misses, etc. (And I've already stopped myself from making some accuracy-related improvements because they would essentially yield no benefits, and drop performance by another 20-40%). The debugger side of things might still have a bit of room for improvements, though. What CPU does your laptop have? It would at least let me compare with the ~2012 laptop I have.
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Mesen - NES Emulator

Post by rainwarrior »

I'll take a look at the new build.
Sour wrote:I guess there must be something with my FCEUX configuration that is causing it to be abnormally slow.
I have to apologize, I made a mistake before, I thought New PPU was on because I almost always have it there, but it got set to old at some point. Sorry! So, you can reduce the severity of the relative comparison a bit, but it's still true that Mesen is too slow when debugging on battery, for me.

With New PPU I get more like 650fps at full speed rather than 1300. When not fast forwarding, about 3% total CPU instead of 2.3%, vs. Mesen kinda jumping from 3-6% but maybe mostly a little over 4%.

When switching to battery mode, there's still enough overhead that I can debug in FCEUX with no slowdown unless I basically open all of its debug viewers at once and turn all their refresh frequencies up to full.
Sour wrote:Opening the debugger in Mesen does impact performance a lot - this is because it turns on a lot of stuff (trace logger, profiling, CDL logging, access counters, etc.). This is why you can open the trace logger and immediately see the execution's history (vs needing to start it beforehand in FCEUX, for example).
Hmm, if you've already got an automated rewind capability, is there really a need to be proactively keeping traces as well? Couldn't you regenerate them on demand from the rewind?

I know you're using the CDL to aid the disassembly, but in my view it's only a little bit helpful, usually very easy to spot "nonsense" data code. If it's consuming significant CPU, I'd definitely turn it off if t was an option. (When starting to use the debugger, showing unidentified data was probably the first option I went looking for and turned on.)

Maybe part of why it's not that much of a problem to me in FCEUX is I can easily control the starting line of the disassembly view. If I see garbage at the top, I just move it up or down a line to find the alignment of the code. Your disassembly I see no easy way to move it one line. Mouse wheel only goes by 3 line increments. (And the desire here is 1-byte increments.) A clickable arrow at the top or bottom of the scroller might help.
Sour wrote:I might also be able to move the processing for some of these to another thread...
If that's possible, it might help making it more usable on battery for me, but it depends whether the stuff that really requires single threading isn't already using the whole core though. (Like I was seeing ~17% in the CPU usage, which I interpret as one maxed thread (12.5%), and another ~40% of another thread on a second core? I think there's a far ways to go before that maxed thread would have any overhead.)
Sour wrote:To go to the PC, you can double-click the top of the callstack or use "Show Next Statement" (Alt+*).
Thanks. The call stack is particularly cool. Since getting to it seems like the same function to me as what "go to" does, I didn't expect to find it in a different menu. I think it would still be worth having as another option in the go to list.

I notice Escape will now unpause the debugger, at least if used from the game window. That's an improvement, though I would much rather if the same key for pause and unpause worked in the debugger window too, similar to how I think having run as F5 be the same as load state as F5 is just asking for mistakes. It is NOT easy to tell which window currently has focus, especially since keys pressed in one often affect the other.

(Also, I am finding myself leaving FPS indicator on just so that I can have a pause indicator that doesn't darken and obscure the whole screen.)
Sour wrote:The code window (and a lot of other things) all use GDI+ (this is what most .NET drawing routines use), maybe GDI+ doesn't respect Windows' own anti-aliasing settings?
Well, the code window looks to me like it's specially rendered, and not using native text stuff. I assume the other uses are the overlay on the game window, where it's totally innocuous to me, but when staring at a big block of disassembly it really sticks out like a sore thumb. With a well hinted font and no anti-aliasing, I'm used to being able to make the text smaller and still have very good legibility, so maybe I'm just a bit fussy about fonts like that. :S

If I could make it smaller and not anti-aliased, I could fit more text in the window and feel more comfortable reading it. As it is, it's OK in the default size, but I can't really make it smaller (mainly because it has 2 sizes of text in it, and the smaller one gets blurry really quick). Like if I could choose the font and specify its size numerically, that would be many times more useful than the increase/decrease size interface where I don't even know a precise number for the size.
Sour wrote:PRG ROM display: I'm not sure what to suggest here - a bank number is vague in a lot of situations. Do you need this information to always be visible? Or would it being shown in a tooltip be sufficient? (e.g on mouse-over on the cpu address?)
The main problem is that the option is either add an extra half-line of small text (reduces amount of code I can see in the window, and hard to read) or replace the CPU address entirely (losing acces to the CPU address). What I was suggesting is that even having it on the left in-line with the CPU address at the same size would be better than either of those options.

Actually, since the CPU and PRG addresses are never going to differ in the bottom 3 nybbles you could even omit those... but a hover tooltip would also do the job. The main meed is just having easy access to the the PRG address, wthout having to give up 50% of the vertical for it, or have to go into the menu and toggle options every time i want to see it.

I am noticing now you have a nice bank display along the bottom, though! That's really good. That's a pretty decent way to see what bank I'm currently in.
Sour wrote:Customizing the default labels: That might be nice, though it might be a pain to edit them in the UI. Maybe allow a simple XML file to be put in Mesen's debugger folder to configure the default workspace on a per-mapper basis?
Well, for me editing them in a text editor would be perfectly good.
Sour wrote:Labels can't start with $ because it would just be confusing when trying to parse what's under the mouse. Ideally, would need to allow the label to be blank (this is possible to define comments in the code) and allow the comment to show in the tooltip for an address that has a comment (it doesn't at the moment).
Well, the blue highlight is nice, since it gives a visual indication that it's a known label and might have a hover tip. If I can't call it $2000 I'd probably just work around with like _2000 or something, not a big deal.

Anyhow, disabling them is the best option for me right now, and if I want custom names I can make them for a specific project, but I really like the tooltip documentation they provide; it's just that the names get in the way for me.
Sour wrote:What CPU does your laptop have? It would at least let me compare with the ~2012 laptop I have.
Intel Core i7-4700MQ @ 2.40 GHz (4 core / 8 thread)
Sour
Posts: 891
Joined: Sun Feb 07, 2016 6:16 pm

Re: Mesen - NES Emulator

Post by Sour »

So hey, funny story - I was able to improve the performance when the debugger is opened by about ~60-70% ... by turning on the debugger while running PGO for the release builds (so essentially I did nothing, except help the compiler do its job better).
I could probably get another 10-15% more performance by disabling the profiler & access counters when the memory tools aren't opened (and probably a tiny bit more if I disabled the trace logger too), but I figure if this is enough for your laptop, maybe that extra 10-15% wouldn't be all that useful.

e.g: I went from ~180fps w/ debugger opened to 310fps in one case, and 140fps to 240fps in another.
Hopefully that helps the situation with your laptop a lot.

Also, you were absolutely correct about the font (I had never really noticed how blurry the text was.) Apparently I turned on antialiasing for text in that custom textbox all the way back in 2015 when I first created it. I switched it to use ClearType instead (which is what the font I'm using is meant to be used with), and the text is far clearer than before on my end. Zooming out also keeps it pretty readable. Let me know if you feel like choosing the font/exact size would still be useful despite this.

Build: download
rainwarrior wrote: A clickable arrow at the top or bottom of the scroller might help.
That's actually something I completely forgot about when I made the new scrollbar, and is something I've actually found myself wanting to use a few times - I'll add one.
Being able to realign the disassembly isn't really possible unless I rebuild the disassembler from scratch, though, essentially. At the moment Mesen disassembles strictly based on the CDL data, and disassembles the entire CPU memory when pausing the debugger (it doesn't restrict itself to disassembling the viewport).

For the shortcut keys, the best suggestion I have at the moment would be to change the shortcuts for save/load states in the preferences so that they don't overlap with the debugger's hardcoded shortcuts. I'll try to get shortcut customization added to the debugger relatively soon, it shouldn't be that hard.

Pause screen: So I guess you'd want a "pause" screen that's similar to FCEUX? (e.g just a small pause icon)

For PRG Addresses: I can add an option to display it inline like there currently is for the byte code. And/or maybe a way to display the upper PRG bits only, like you said (not too sure what I would call this, though)
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Mesen - NES Emulator

Post by lidnariq »

Sour wrote:Apparently I turned on antialiasing for text in that custom textbox all the way back in 2015 when I first created it. I switched it to use ClearType instead (which is what the font I'm using is meant to be used with), and the text is far clearer than before on my end. Zooming out also keeps it pretty readable. Let me know if you feel like choosing the font/exact size would still be useful despite this.
I've actually made a point of modifying my local build to use Lucida Sans Typewriter instead of Consolas / DroidSansMono
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Mesen - NES Emulator

Post by rainwarrior »

Sour wrote:So hey, funny story - I was able to improve the performance when the debugger is opened by about ~60-70% ... by turning on the debugger while running PGO for the release builds (so essentially I did nothing, except help the compiler do its job better).
I could probably get another 10-15% more performance by disabling the profiler & access counters when the memory tools aren't opened (and probably a tiny bit more if I disabled the trace logger too), but I figure if this is enough for your laptop, maybe that extra 10-15% wouldn't be all that useful.
Well, "good enough for rainwarrior's laptop not on full power" is only a good metric if you're rainwarrior ;) but this actually ALMOST gets up to full speed. The audio is still unlistenable whenever the FPS goes below 60, but I actually seem to be getting ~55fps here instead of ~35fps before. With the audio muted this is actually pretty tolerable debugging. (PAL games seem to do slightly better but are still dipping below 50fps... just not as much.) So yes, another few % would actually make a big difference for me specifically. Probably any significant speed improvement will broaden the number of users who can make use of it.
Sour wrote:I switched it to use ClearType instead (which is what the font I'm using is meant to be used with), and the text is far clearer than before on my end.
Yes, that's a big improvement over the previous AA method, I guess by virtue of subpixel rendering, but ignoring the user's cleartype setting and forcing it on is a problem of its own (e.g. anyone with a rotated screen, or some unusual dot arrangement). I'm not currently using a rotating screen, but I've know quite a few programmers who do it (and it's been me at some points). Control of AA becomes critical for that minority of users. (Though with at least the ability to increase font size, it can be coped with that way.)
Sour wrote:Let me know if you feel like choosing the font/exact size would still be useful despite this.
There's really never a case where I think letting the user choose their font isn't useful, but I will say that what you had was already usable, and with cleartype it's better than it was.
Sour wrote:Being able to realign the disassembly isn't really possible unless I rebuild the disassembler from scratch, though, essentially. At the moment Mesen disassembles strictly based on the CDL data, and disassembles the entire CPU memory when pausing the debugger (it doesn't restrict itself to disassembling the viewport).
Well, I only made the CDL suggestion because you had it on a list of constant-care things that might improve performance if optonal. I don't know how much extra CPU a CDL actually takes.

I would say, though, that not being able to view disassembly for code that has not yet been run is a big disadvantage, completely unrelated to any CPU the CDL might consume. When trying to step through stuff I definitely need to speculate about code that could be run but hasn't yet.
Sour wrote:Pause screen: So I guess you'd want a "pause" screen that's similar to FCEUX? (e.g just a small pause icon)
Oh, yes a small icon would be better than using the FPS overlay to fake it. The full darkening overlay seems fine for just playing games but really obtrusive when debugging... but with it off any time i was on a screen without constant animation it was really confusing when debugging, especially with keyboard input not being global I had a hard time knowing whether I was accidentally in the debugger window or paused or both.
Sour wrote:For PRG Addresses: I can add an option to display it inline like there currently is for the byte code. And/or maybe a way to display the upper PRG bits only, like you said (not too sure what I would call this, though)
Even just the PRG address tooltip idea would do the job adequately, IMO, though if you're looking for a name for an address missing the low 3 nybbles, I'd maybe call that "compact".


P.S. I just found the "event viewer" and it's amazing, though it seems to be missing a colour legend to know what's what. (Ah, I guess I can open the configure colours window and use that... though this seems to prevent any input in other windows while open.)

Weird thing I noticed: if I open the Input menu while paused in the debugger, the game will run for 1 frame before the input config window opens?
mkwong98
Posts: 282
Joined: Mon May 30, 2011 9:01 pm

Re: Mesen - NES Emulator

Post by mkwong98 »

Sour wrote:Here's a build with the HD Pack changes: download
Thank you!
I'm interested to see how kya uses conditions in the new pack and what tools are used to make the pack.
Sour
Posts: 891
Joined: Sun Feb 07, 2016 6:16 pm

Re: Mesen - NES Emulator

Post by Sour »

Made some changes:
-Font & base font size can be configured for all tools (debugger, memory viewer, etc.). It lets you select any font, but only monospace fonts will display properly in most cases.
-Added up/down arrows to the scrollbar (but you still can't change the disassembler's alignment with this, though)
-Added a "Go to PC" option in both Go To menus
-Added an option to display the PRG address in a "compact" way next to the cpu address
-When the debugger is opened and execution is paused, a blue pause icon will show up at the top left of the screen (it can be disabled in the debugger). This icon will also be shown when the debugger is closed if the "disable pause screen" option is enabled.

-It's now possible to customize the default labels on a per mapper basis. I was about to create an .xml format for it, when I realized I already have my own format for labels :)
To configure labels for all mappers, create a Debugger\DefaultLabels.Global.mlb file in Mesen's home folder.
On top of this, you can also create files for specific mappers (both the global file & mapper-specific file will be imported, with the mapper-specific labels having priority). Name them like this: DefaultLabels.[mapper number].mlb
For FDS or NSF files: DefaultLabels.FDS.mlb, DefaultLabels.NSF.mlb

If anyone ends up making label sets for mappers/etc (or just improving the default labels I have at the moment), I'd be more than happy to include them in Mesen releases, too.

Edit: I didn't explain .mlb files at all - they're the import/export format for Mesen's labels (much like FCEUX's .nl files). So you can configure the labels inside the debugger's UI, export them to .mlb and save that file with one of the naming schemes above to override the default labels.

Build: download


Opening the input dialog causing a frame to run is "normal" - this is because it has to pause the emulator (due to multithreading) to update the list of connected gamepads, and pausing the emulator can only be done at the end of a frame (except when done from the debugger).

Nice to know it's running faster, pity it's still not up to 60+fps, though. I'll try and see if I can squeeze a bit more performance out of it.

mkwong98 wrote:I'm interested to see how kya uses conditions in the new pack and what tools are used to make the pack.
He's made pretty heavy use of conditionals in his pack (has 700+ conditions defined), but I'm unsure how he built the pack. The definition file is over 5k lines long, so hopefully he didn't write all of it by hand. Maybe you can send him a PM on romhacking.net and see if he's willing to show it to you?
Post Reply