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

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems. See the NESdev wiki for more information.

Moderator: Moderators

tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

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

Post by tepples »

Would it be easier to implement VS Code's protocol for these things or GDB's?
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

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

Post by lidnariq »

Sour wrote:Is this with the latest commit or something that's older than a week or so? There was a bug in 0.9.4 due to paths getting forced to lower case in Linux, it should already be fixed though.
It was, in fact, with 0.9.4-1-g423ac65a, so that makes sense.
Bananmos
Posts: 552
Joined: Wed Mar 09, 2005 9:08 am
Contact:

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

Post by Bananmos »

Sour/lidnariq: Ah... yes, you're right that the actual part of writing during the cycle is smaller than 3 pixels.

And ~1.5 pixels is small enough that your current strategy of putting the register writes at a single pixel with an 'outline' in each direction should be good enough. Can't wait to try this feature out in practice! :)

I too would vote for GDB protocol integration to be the primary target *if* this gets implemented. GDB has been supporting this usr-case for a long time now, and even Visual Studio can use GDBserver.
Sour
Posts: 891
Joined: Sun Feb 07, 2016 6:16 pm

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

Post by Sour »

Here's an updated build: download

Changes:
-Added PPU memory write viewer
-Added toolbar to debugger window (optional)
-Fixed "draw partial frame" issue with NTSC filters (toggling odd/even frame effect on each step)
-Added cpu cycles/scanlines/frames options in "Break In" dialog
-Added option to display the previous frame in grayscale under the current frame (for use with "Draw partial frame")
-Split "Freeze/Unfreeze" command into 2 commands to allow unfreezing areas where all bytes aren't frozen
-Added a "Mirroring Type:" read-only label at the bottom of the nametable viewer (will probably make this an editable field at some point)

Let me know if you feel like there's anything out of these that still needs tweaking.

Things left (soon?):
-Opening up debugger when the CPU crashes
-Custom/Grayscale/etc palettes for CHR/Nametable viewer

Ideas for the future:
-APU output graphs
-Remote debugging

Did I forget about something?

As far as remoting debugging goes, it seems like VS Code's protocol is specific to it, but it's meant to be used as a wrapper for other protocols (e.g you can wrap a GDB debugger in a plugin for VS Code's debugger, etc.) I guess GDB might make sense here, although I have absolutely zero knowledge of it. I'm happy to help on the emulator end of things if anyone wants to try to integrate the debugger into an IDE, just let me know.

Any more feedback/feature requests? :p
User avatar
thefox
Posts: 3134
Joined: Mon Jan 03, 2005 10:36 am
Location: 🇫🇮
Contact:

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

Post by thefox »

tepples wrote:Would it be easier to implement VS Code's protocol for these things or GDB's?
Bananmos wrote:I too would vote for GDB protocol integration to be the primary target *if* this gets implemented. GDB has been supporting this usr-case for a long time now, and even Visual Studio can use GDBserver.
From my experience the gdb remote protocol isn't quite as generic as you'd hope it to be and often makes some target-specific assumptions. Could be troublesome if gdb/gdbserver doesn't know about 6502. It was also very prone to other kinds of compatibility problems. I have limited experience though so might be mistaken here.

Anyway, I wouldn't make the emulator talk to VS Code directly. The VS Code protocol is very high level, so that would lead to duplicated effort in other emulators. Instead, the emulator would talk to the debug adapter (supplying register values, memory contents, etc.), and the debug adapter would talk to VS Code. Even if there are some problems, the gdb protocol might make sense for the emulator<->adapter communication.
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi
Bananmos
Posts: 552
Joined: Wed Mar 09, 2005 9:08 am
Contact:

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

Post by Bananmos »

So I've tried the latest build, and am just loving this visualisation! :D

...however, I seem to have a problem on my side where the tooltip won't appear when I hover the mouse over the register-write-pixels. Instead it seems to trigger about 1/4 of the screen to the left of it (and similarly for the Y position, I have to go up to find the tooltip).
YearsBehind_shifted_tooltip.png
Shifted tooltip in PPU writes
Shifted tooltip in PPU writes

Do you know what could be causing this misbehavior?

I also had a look at how the writes in the second part of Years Behind are affected by the DPCM, and am... somewhat surprised. As they appear to be very badly out-of-sync whenever DPCM plays.

Here's a few screenshots:
YearsBehind_exploder.png
YearsBehind_Exploder.png
- This is the original tune by Chibi-Tech with no DPCM playing, so all bars are almost perfectly vertical save for the 2/3 cycle/scanline oscillation, as expected.

YearsBehind_gradius.png
YearsBehind_Gradius.png
- This is how the demo looks while playing the "Gradius" cover by Memblers. The bars are no longer nicely vertical, which is expected. But the big shift to the right is not.

YearsBehind_Hyperspace.png
YearsBehind_Hyperspace.png
- This is is how it looks while playing the "Hyperspace" cover by Memblers. It's even worse, and besides the big shift to the right of the PPU register write debug pixels there's also corruption on the bottom part of the blue blob.

Now, it was a long, long time since I wrote this code and memory is a bit vague in the details, so it's not impossible I did mess this approach up in the end. But I do distinctively remember spending loads of hours adjusting the fractional phase accumulator for each of the 16 sample playback rates, in order to make my set-unset-monochrome-bit debug bar look as vertical as possible even when DPCM samples were playing. I don't think I got it "perfect" as I was just observing a fuzzy and jittering bar, but it did look a lot more closer to vertical than what I'm now seeing in Mesen's PPU Write visualiser.

And the demo also seems to glitch a lot more in Mesen than it does on a real PAL NES (where there is just an occasional very subtle glitch on the scroll text, about once every half a minute. And which I think will only happens if you're unlucky with the reset phase, IIRC.

So I am wondering if Mesen could possibly have the DMA cycle steal slightly wrong for PAL machines? As I'm on vacation I can't really confirm this by trying the debug-thing on my real PAL NES. But I'll see if I can get some hacked debug code to test with other emulators tomorrow and see what they show. (and if anyone else has a PAL machine+powerpak+free time I'd be eager to find this out)
Sour
Posts: 891
Joined: Sun Feb 07, 2016 6:16 pm

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

Post by Sour »

Thanks for testing!

The tooltip issue is most likely related to you having DPI set to over 100% in Windows. I'll take a look.

Mesen's PAL emulation (and I'd even be tempted to say every emulator's PAL emulation) is probably not as robust as NTSC, so I wouldn't be too surprised if there are some issues. There are few PAL test roms, and most of them only test relatively basic behavior. Does the PAL version have any known difference in behavior vs DMC cycle stealing? Mesen implements this as stealing 4 cycles normally, and 3 cycles if it lands on the last cycle of a write instruction ($4014-related quirks aside) - I tried tweaking it to always steal 3 cycles, but then the bars end up shifting more and more to the left (instead of the right).
Oziphantom
Posts: 1565
Joined: Tue Feb 07, 2017 2:03 am

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

Post by Oziphantom »

Having the ability to easy invoke the debugger from the main game window would be nice.
To kill 2 birds with one stone, the way to get remote debugging is to have a "monitor" as you can easily run it over a telnet interface which allows for external debuggers.
remote.png
it also makes it easier to set up breakpoints, compare memory, set traces etc although when you only have 2K probably not that much need ;)
having an IO command that lets you see the hidden internal state of things is also handy. And having it in text spares you from having to make a custom GUI for every mapper under the sun ;)

having "debug borders" is a great addition btw
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

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

Post by tokumaru »

Thanks for the new features, Sour! The PPU Writes Viewer is pretty cool, not only for checking out raster effects, but also vblank handlers!
User avatar
nesrocks
Posts: 563
Joined: Thu Aug 13, 2015 4:40 pm
Location: Rio de Janeiro - Brazil
Contact:

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

Post by nesrocks »

I'm dying to get some free time to really test the workflow on this! Looks amazing!

I got a bug when quick testing though. It was mid-scanline and I hit "run one frame" and this happened. Granted, I had no idea what I was doing this for, much like random testing of buttons.
https://imgur.com/a/hTZAW
https://twitter.com/bitinkstudios <- Follow me on twitter! Thanks!
https://www.patreon.com/bitinkstudios <- Support me on Patreon!
Bananmos
Posts: 552
Joined: Wed Mar 09, 2005 9:08 am
Contact:

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

Post by Bananmos »

The tooltip issue is most likely related to you having DPI set to over 100% in Windows. I'll take a look.
Indeed that was the issue. I've changed my 125% setting to 100% and the tooltip now appears in the right spot. I have had the 125% setting since forever though, so it's a bit of a bummer to have to revert it. But if there's no other way then I'll switch just for this cool new debugging mode :)

I've hacked the Years Behind demo to replace the scroll writes in the second part with the set/unset monochrome-bit&intensify-blue sequence i originally used when building the DPCM adjustment table back in 2003. And it consistently shows the same shearing in Mesen, FCEUX and Nintendulator. Which makes me suspect that maybe I'm the one who got things a bit wrong after all. But in that case, it's still a bit of a mystery as to why the glitches are so much worse in the emulators than on a real PAL NES.

I'll make sure to run this debug version on my PAL NES when I'm back from vacation. But if anyone else with a PAL NES and flashcart wants to beat me to it, it's available here.
Sour
Posts: 891
Joined: Sun Feb 07, 2016 6:16 pm

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

Post by Sour »

Nice to hear that people are finding it useful!
nesrocks wrote:I got a bug when quick testing though. It was mid-scanline and I hit "run one frame" and this happened.https://imgur.com/a/hTZAW
Thanks for the screenshot! Allowed me to figure out the problem in all of 5 seconds.
Bananmos wrote:I have had the 125% setting since forever though, so it's a bit of a bummer to have to revert it.
No need, it's fixed :) High DPI modes are meant to work (I spent a couple of days fixing DPI issues in the interface in version 0.9.4), but it's something that constantly needs to be tested. And since testing requires firing up a Windows VM with higher DPI (or rebooting my computer), I don't do it that often :p

As far as PAL goes, it's possible there might still be some quirks about the PAL NES that are not known. As far as I know, Mesen implements all of the PAL NES' known differences vs NTSC (at least, those I am aware of), including the slightly bigger window where sprite DMA can be performed, etc.

Both issues should be fixed in this build: download
Let me know if you find any other issue.

Oziphantom wrote:Having the ability to easy invoke the debugger from the main game window would be nice.
What do you mean by this? There are customizable keyboard shortcuts to open all of the debugger tools (and enabling "Developer Mode" adds a "Debug" menu to the main window, for easier access to the tools, too)
Bananmos
Posts: 552
Joined: Wed Mar 09, 2005 9:08 am
Contact:

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

Post by Bananmos »

No need, it's fixed :)
Thanks! I can confirm it works on my side too :)

Oh, and another small issue: As Tokumaru mentioned, the ppu write visualisation can be really useful for studying the vblank write patterns as well - especially to catch the typical error of your vram writes ending up outside of vblank.

But I noticed that Mesen currently always has the window be 262 scanlines. Could we get the full 312 scanlines for PAL?

And thinking further, I think this kind of visualisation could be really good for other types of hardware-related events as well, such as getting those dots where the vblank NMI occurred, where the sprite#0 hit got set, and where an IRQ occurred.

Even better if it could be slightly configured too, kind of like a generic conditional breakpoint but with it adding to the visualisation instead of interrupting your program. (Pardon the feature creep... :)
Sour
Posts: 891
Joined: Sun Feb 07, 2016 6:16 pm

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

Post by Sour »

The feature's scope was starting to get a bit too big, so I split it out of the ppu viewer and gave it its own window:
Image

I moved the prerender scanline to the top of the screen, and made it so it adjusts the picture based on NTSC/PAL (and it will also add more lines if more were added via the overclocking options).

I'm probably going to add color customizations at this point - too many different things can be shown to pick a decent default palette.
Maybe 1 color for each ppu register (different colors for read/write, so ~10 colors?), and then 5 more colors: mapper register writes, mapper register reads, nmi, irq & sprite 0 hit.

Did I miss something obvious w/ regards to the categories of events someone might want to see on the image? (I excluded sprite DMA since it triggers a bunch of very visible $2004 writes already)

Adding conditional expressions to mark specific points on the screen would be possible, but having to add a bunch of UI just to add/delete/edit those is kind of annoying. I could add a fixed number of "condition" text fields to the window and have each condition display in a different color easily enough, though. Keep in mind conditionals are mean on performance (esp. since in this case they would need to be evaluated on every PPU cycle, instead of every CPU cycle) - each condition will probably each drop max FPS by 5-10%.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

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

Post by tepples »

I'd suggest ability to place a mark at a particular CPU read or write location, as a way of visualizing CPU use. If you're worried about UI to make them, you could toss them in with the breakpoint setting UI.

[ ] Stop execution
[ ] Mark on Event Viewer using this color:
Post Reply