Mesen Debugger - Feedback/Feature Requests? (2018 edition)
Moderator: Moderators
Re: Mesen Debugger - Feedback/Feature Requests? (2018 editi
Would it be easier to implement VS Code's protocol for these things or GDB's?
Re: Mesen Debugger - Feedback/Feature Requests? (2018 editi
It was, in fact, with 0.9.4-1-g423ac65a, so that makes sense.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.
Re: Mesen Debugger - Feedback/Feature Requests? (2018 editi
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.
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.
Re: Mesen Debugger - Feedback/Feature Requests? (2018 editi
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
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
Re: Mesen Debugger - Feedback/Feature Requests? (2018 editi
tepples wrote:Would it be easier to implement VS Code's protocol for these things or GDB's?
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.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.
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
Re: Mesen Debugger - Feedback/Feature Requests? (2018 editi
So I've tried the latest build, and am just loving this visualisation!
...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
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 - 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 - 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 - 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)
...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
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 - 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 - 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 - 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)
Re: Mesen Debugger - Feedback/Feature Requests? (2018 editi
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).
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).
-
- Posts: 1565
- Joined: Tue Feb 07, 2017 2:03 am
Re: Mesen Debugger - Feedback/Feature Requests? (2018 editi
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. 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
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. 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
Re: Mesen Debugger - Feedback/Feature Requests? (2018 editi
Thanks for the new features, Sour! The PPU Writes Viewer is pretty cool, not only for checking out raster effects, but also vblank handlers!
Re: Mesen Debugger - Feedback/Feature Requests? (2018 editi
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
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!
https://www.patreon.com/bitinkstudios <- Support me on Patreon!
Re: Mesen Debugger - Feedback/Feature Requests? (2018 editi
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 modeThe tooltip issue is most likely related to you having DPI set to over 100% in Windows. I'll take a look.
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.
Re: Mesen Debugger - Feedback/Feature Requests? (2018 editi
Nice to hear that people are finding it useful!
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.
Thanks for the screenshot! Allowed me to figure out the problem in all of 5 seconds.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
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 :pBananmos wrote:I have had the 125% setting since forever though, so it's a bit of a bummer to have to revert it.
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.
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)Oziphantom wrote:Having the ability to easy invoke the debugger from the main game window would be nice.
Re: Mesen Debugger - Feedback/Feature Requests? (2018 editi
Thanks! I can confirm it works on my side tooNo need, it's fixed
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...
Re: Mesen Debugger - Feedback/Feature Requests? (2018 editi
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:
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%.
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%.
Re: Mesen Debugger - Feedback/Feature Requests? (2018 editi
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:
[ ] Stop execution
[ ] Mark on Event Viewer using this color: