Mesen Debugger - Feedback/Feature Requests? (2018 edition)

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems.

Moderator: Moderators

User avatar
rainwarrior
Posts: 7677
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Mesen Debugger - Feedback/Feature Requests? (2018 editi

Post by rainwarrior » Sun Mar 18, 2018 9:49 pm

Oh, well in that case I suppose what is needed is a list of MEMORY block to ROM location overrides?

In some of my projects I've split things into separate link steps, which is what I'd assumed you were doing. That would require a multiple .dbg mapping.

To handle both styles, it could be a list of entries with 3 pieces of information?
  • 1. .dgb file
  • 2. MEMORY block
  • 3. ROM location override (presumably just the start address?)
I dunno if we're getting into territory where there might be a zillion ways to organize things though.

I suppose as an alternative workaround, though you could process the .dbg file to inject the final ROM addresses back into it. (Or in my case, I could synthesize a .dbg file of my own from the separate ones.) From FCEUX I was already used to having my own script to build the .NL debug files anyway.

User avatar
tokumaru
Posts: 11466
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Mesen Debugger - Feedback/Feature Requests? (2018 editi

Post by tokumaru » Sun Mar 18, 2018 10:33 pm

rainwarrior wrote:I suppose as an alternative workaround, though you could process the .dbg file to inject the final ROM addresses back into it. (Or in my case, I could synthesize a .dbg file of my own from the separate ones.) From FCEUX I was already used to having my own script to build the .NL debug files anyway.
I made scripts like this before, but the common kind of symbolic debugging in FCEUX and Mesen never worked well for me, since I reuse RAM a lot in different parts of my programs, from function parameters and local variables to modules that don't run concurrently, so there was no way I could give a single name to each memory position and have the symbolic disassembly make sense.

What I'm doing now is generating my own symbol file using macros (for labels/variables that are created through macros), so I get to choose which symbols end up in the file and which don't. Everything that uses shared memory normally doesn't go to my custom symbol file, but when I'm debugging a specific module or function, I enable the output of their respective symbols, and there are no conflicts.

Source-level debugging should pretty much solve that problem though, so I'll see if patching the .dbg file isn't too much trouble.

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

Re: Mesen Debugger - Feedback/Feature Requests? (2018 editi

Post by Sour » Mon Mar 19, 2018 4:31 am

It's possible that your .dbg file contains the information required to make it work properly already.
The .dbg files does list the file offsets based on the output filename (so I assume it's meant to support multiple files), but all the projects I have at the moment only have a single output. If you can PM me the .dbg file you get, I might be able to figure out a way to make it work?

User avatar
gauauu
Posts: 658
Joined: Sat Jan 09, 2016 9:21 pm
Location: Central Illinois, USA
Contact:

Re: Mesen Debugger - Feedback/Feature Requests? (2018 editi

Post by gauauu » Tue Mar 20, 2018 9:33 pm

Another feature request that probably already exists (as most of mine do!):

I love that there's a way to ask it to randomize ram at startup. Is there a way to make it start in a random bank/banks? (which I realize is slightly complicated because it has to work for each banking scheme). It would be nice to be able to properly test to make sure my stubs to jump into the first bank are all working right.

Thanks!

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

Re: Mesen Debugger - Feedback/Feature Requests? (2018 editi

Post by Sour » Wed Mar 21, 2018 3:19 pm

This isn't a feature at the moment, but something I have been considering for a while. The problem is that I see no simple way to making it work for all ~250 boards Mesen supports without having to check all of them, validate what their know bootup state is and then alter their code as needed.

At the moment, on mappers with banks smaller than 32kb, Mesen does try to leave the banks as open bus (except the fixed banks), which forces you to initialize the mapper properly (and prevents it from working when it shouldn't) - but sometimes implementation details make it so it's easier to just select bank 0 everywhere (e.g MMC3 does this, among others)

Either way, it should be relatively easy to implement randomized banking for common commercial/homebrew mappers, though, since that would restrict the list to about 10-15 mappers or so? I'm not sure which mappers would be the most important to target (beyond the obvious ones like MMC/VRC mappers, etc.) - so if anyone has a list/suggestions to make, that would be helpful (esp. when it comes to popular homebrew mappers).

lidnariq
Posts: 8786
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: Mesen Debugger - Feedback/Feature Requests? (2018 editi

Post by lidnariq » Wed Mar 21, 2018 6:58 pm

I'd think open-bus would be the useful default, instead of random banks ...

Maybe only the common ones that use 32K banking would be random banks?

User avatar
gauauu
Posts: 658
Joined: Sat Jan 09, 2016 9:21 pm
Location: Central Illinois, USA
Contact:

Re: Mesen Debugger - Feedback/Feature Requests? (2018 editi

Post by gauauu » Wed Mar 21, 2018 8:10 pm

lidnariq wrote:
Maybe only the common ones that use 32K banking would be random banks?
BNROM and GTROM were the two that I had in mind, both with 32k banks. (Both of which I recently ran into bugs when testing in hardware because of errors in my startup bank switching that I never saw on emulators)

zzzhhh
Posts: 1
Joined: Sun Mar 25, 2018 10:30 pm

Re: Mesen Debugger - Feedback/Feature Requests? (2018 editi

Post by zzzhhh » Thu Mar 29, 2018 12:20 pm

Please disregard my reply if the requested feature is already available.

What I want is integration into Visual Studio 2017 (or JetBrain's IDE product) as an extension so that we can simply load a ROM (.nes file) by clicking a menu item or toolbar button and start debugging, just as we normally do with C/C++ code inside VS. Because Visual Studio or JetBrain's IDE product has already provided a rich set of debugging tools like setting (conditional) breakpoints, stepping over and into, watch (and change) variables, viewing memory and CPU contents, etc., it makes more sense to take advantage of this existing IDE instead of creating a separate new one having the same function (or quite possibly less functions with more bugs), and of the expertise most of us already have working inside of it.

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

Re: Mesen Debugger - Feedback/Feature Requests? (2018 editi

Post by Sour » Thu Mar 29, 2018 1:19 pm

While connecting an existing IDE with Mesen's debugger via a protocol like gdb might be feasible (like it was discussed earlier in the thread), implementing the entire emulator as a Visual Studio (or other IDE) plugin that would allow you to load NES files right into the IDE would be a gigantic task (and essentially akin to rewriting the entire project).

The end result would be that people now need to download and install a specific IDE (e.g VS, which is several GBs in size) to use the debugger. And while VS is widely used, not everybody uses it, and people may not be able to use it at all (e.g Linux users) - the same could be said of any other specific IDE. So while I can see some of the appeal of being able to use an existing IDE for this, I don't think I agree that it would be a better solution, overall.

Either way, though, this is definitely not something that I will be doing - it would probably take several hundred hours of my time to complete this kind of project (if not more).

bleubleu
Posts: 66
Joined: Wed Apr 04, 2018 7:29 pm
Location: Montreal, Canada

Re: Mesen Debugger - Feedback/Feature Requests? (2018 editi

Post by bleubleu » Sun Apr 08, 2018 4:42 pm

Hi.

Im new to nesdev so apologies if I havent read the whole thread. Here are a few ideas I came up with from using Mesen for about a month (its awesome btw).
  • It would be nice if CTRL+R worked when the focus in on the debugger. I often set the game in a specific state to debug something and resetting quickly is nice.
  • A little debugger watch syntax that could be added to visualize arrays starting at a specific address would be useful. Not having to bring up the memory viewer for some small stuff is nice. Visual Studio has a couple versions of this. If I write "ptr,10" it will show me the 10 first element of the array starting at ptr. Of course VS knows the type, Mesen doesnt. Having a way to see arrays of byte or word would be great. Another syntax VS has is "ptr,mb" (in this case mb means memory byte). It will show me the first few bytes starting at this address. (https://docs.microsoft.com/en-us/visual ... ers-in-cpp)
  • Being able to view the tiles and attributes that were recently updated in the PPU debugger would be cool. I had to implement 4-way scrolling, which was super annoying, so I ended up writing myself a little C# app on the side to see what was going on. Here is a screenshot if you need inspiration, red shows tiles updated recently, yellow are attributes.
That's all I got for now.

Keep up the good work.

-Mat
Attachments
Scroll.png

User avatar
rainwarrior
Posts: 7677
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Mesen Debugger - Feedback/Feature Requests? (2018 editi

Post by rainwarrior » Mon Apr 09, 2018 11:58 am

Wanting to investigate nametables or CHR across scanline splits, I tried opening multiple PPU debug windows and give them each a different scanline display option. Unfortunately, this option does not seem to be per-window, but rather a global thing where only the last value takes effect. (Also displaying the wrong value for one of the windows, since changing one does not update the other... but ideally it wouldn't be global anyway.)

Probably not a trivial thing to implement, but since this emulator has the (unique?) feature of duplicate PPU debug windows, seems a shame it's not available.

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

Re: Mesen Debugger - Feedback/Feature Requests? (2018 editi

Post by Sour » Mon Apr 09, 2018 4:49 pm

I gave the tile/attribute highlighting a shot with the data I had available in the UI already:
highlight.png
As is, it only highlights PPU writes that actually change the data (so if the game writes the same value twice, it won't highlight). The highlights only stay on the screen for a single frame, so usually have to play the game in slow motion to see them for a decent amount of time. I could fade them out over time (with a lot more logic), but then that would make it harder to discern on which specific frame an update occurs. Is this sufficiently useful as is? If so, I just need to add a checkbox to toggle the highlight on/off and I'm done :p

-Reset: I'll add customizable reset/power cycle shortcuts to the debugger window
-Array/etc syntax in the watch: I can see the use here, but making it work with the rest of the code that's currently used for watch expressions involves a lot of changes - can't promise anything on this one, but I'll add it to my list of future improvement ideas.
rainwarrior wrote:Probably not a trivial thing to implement, but since this emulator has the (unique?) feature of duplicate PPU debug windows, seems a shame it's not available.
The multiple PPU windows were originally just a way to allow someone to look at multiple tabs at once (instead of splitting the tools across multiple separate windows), but I never really considered the interaction with the scanline/cycle fields. Making the scanline/cycle fields a per-window option wouldn't be hard, I'm mostly worried about the performance impact of having to check through an "array" of scanline/cycle combinations on every PPU cycle vs comparing with a single fixed value. It might not have that much of an impact though, I'll check.

bleubleu
Posts: 66
Joined: Wed Apr 04, 2018 7:29 pm
Location: Montreal, Canada

Re: Mesen Debugger - Feedback/Feature Requests? (2018 editi

Post by bleubleu » Mon Apr 09, 2018 6:15 pm

Wow thanks!

I'll give it a shot. Coffee donation incoming!

-Mat

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

Re: Mesen Debugger - Feedback/Feature Requests? (2018 editi

Post by Sour » Mon Apr 09, 2018 9:03 pm

Here's a (Windows-only) build with the changes: download

It adds:
-2 options to the nametable viewer to toggle the highlight of tile/attribute data changes
-Reset/Power Cycle shortcuts to the main debugger window (customizable - but you will have to customize these independently from the shortcuts in Options->Preferences)
-The ability to have multiple PPU viewer windows opened & set to update at different scanlines/cycles - it should run about as fast as before, or maybe a tiny little bit faster.

And thanks for the donation!

bleubleu
Posts: 66
Joined: Wed Apr 04, 2018 7:29 pm
Location: Montreal, Canada

Re: Mesen Debugger - Feedback/Feature Requests? (2018 editi

Post by bleubleu » Fri Apr 13, 2018 4:20 pm

Hi!

I just got around to test the new feature. Its great! The one thing I would tweak is that I would highlight tiles/att changes regardless of whether the data has actually changed or not. When debugging scrolling (for example) you will often rewrite the same data (imagine a blue sky in mario), but you still want to know you did it correctly. The PPU is kind of a write-only thing for most developers.

-Mat

Post Reply