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

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 »

Looks awesome, but how does it work over time? The scanline and cycle options at the bottom don't really apply to this screen, since this is not a snapshot of a specific moment, but the log of an entire frame. Also, since it's nearly impossible to sync the CPU with the PPU in a game, those annotations may jitter a lot when the emulator is running. I guess it's possible to keep the CPU debugger open and advance frame by frame to see this window in "slow motion", right?
Sour
Posts: 891
Joined: Sun Feb 07, 2016 6:16 pm

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

Post by Sour »

I'm not against shifting the image to match the actual NTSC timings, but it seemed easier (for me) to see how much you need to shift your writes if the entire hblank is together on the right side? Personally I always see the scanlines as being 0 (blank), 1-256 (pixels), 257-341 (blank), even though that's not what's actually happening NTSC-wise.
And I did forget to keep a 1 pixel blank on the left side for cycle 0 which doesn't output a pixel (so everything in my screenshot is off by 1 pixel at least)

Didn't know about the XOR trick, that's good to know. Though in this case, if I XORed it with the background, then you'd have the problem of not knowing which register it represents without checking the tooltip.

The exact cycles seem to vary quite a bit from frame to frame (maybe +/- 20-25 ppu cycles or so?) - was it meant to be almost the same on every frame?

@tokumaru
It refreshes at ~15fps while the emulation is running. When breaking execution, it refreshes on every break/step (like the rest of the PPU viewer tools). Technically, the "Draw partial frame" behavior should probably be applied here too (because I clear out the list of PPU writes at the start of the frame, so if you break at scanline 120, you will only see writes for scanlines -1 to 120).

You're right that the scanline/cycle options at the bottom don't make sense in this case, I will probably hide them when the tab is active and hardcode it to refresh at the end of the frame when the emulation is running.
User avatar
gauauu
Posts: 779
Joined: Sat Jan 09, 2016 9:21 pm
Location: Central Illinois, USA
Contact:

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

Post by gauauu »

Sour wrote:
@gauauu You should already be able to do this in the trace logger using conditional logging. Try this condition: "IsWrite && Address == $400" - it should only log instructions that write to $400
Wow, you rock... Every time I need a feature, turns out it's already there and I just haven't discovered it. Again, thanks!
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

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

Post by lidnariq »

Sour wrote:The exact cycles seem to vary quite a bit from frame to frame (maybe +/- 20-25 ppu cycles or so?) - was it meant to be almost the same on every frame?
I ... thought at the time that I made the diagram in Nintendulator that it was perfectly synced to the PPU, but I'm really not confident anymore.
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 »

I don't think anyone managed to achieve perfect PPU synchronization before blargg found out a way to do it. But even when things are perfectly sync'ed you can't really do pixel-perfect raster effects, since the smallest unit of time the CPU can control is equivalent to 3 pixels, so there will invariably be at least SOME jittering.
Bananmos
Posts: 552
Joined: Wed Mar 09, 2005 9:08 am
Contact:

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

Post by Bananmos »

Wow, you're quick! That looks amazing and makes me drool already :)

I am a bit confused as to why it only shows a single dot for each scanline though? The actual write in an STx instruction should occur over a full CPU cycle if I'm not mistaken. And on NTSC that would correspond to 3 PPU pixels output. So I'd expect three dots to be visible rather than just one.

Is there a chance we could try a version of it out ourselves soon? I'd really like to run it through a few stress tests. For one thing, it'd be fun to re-visit my really old "Years Behind" demo with it. That one went through a lot of effort to align writes to be within hblank even when DPCM throws the timing off, but it's still not 100% perfect. Mainly because I wasn't yet aware of how each boot of the NES would create a different phase alignment between the PPU and CPU clocks.

Speaking of which, I think I have another feature request that might not be in yet... does Mesen emulate and/or let you control this semi-random alignment of CPU/PPU phase? If your hblank window is *really* tight (such as when changing a palette index and then restoring the full X/Y scroll value) you might need to reset your NES many times to check that your hblank code still works fine under all reset phases. And being able to explicitly reset to each phase would significantly shorten this labor.
User avatar
gauauu
Posts: 779
Joined: Sat Jan 09, 2016 9:21 pm
Location: Central Illinois, USA
Contact:

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

Post by gauauu »

One other very minor feature request (unless you've already done this and I just can't find it, like every other request I make):

The option for "break on power/reset" seems to be only available to select from within the debugger window. But if don't have that selected, and my game is crashing immediately at startup, I can't open the debugger to toggle that option.

My workaround has been to load a different game or an older working version of my game, open the debugger, toggle that option, then re-open my game (alternatively I could probably edit the config file directly). Is there a way (or can you add a way) to toggle that option from the "no game is loaded" view, or on the main window somewhere?
Sour
Posts: 891
Joined: Sun Feb 07, 2016 6:16 pm

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

Post by Sour »

Image
I think choosing the colors might not actually be necessary this way? Every color seems relatively easy to distinguish? And should still be visible against most backgrounds.

Image
I've tried to add as much as I could here (and ended up making icons for the run ppu options to be able to put them too). Anything that seems to be missing?
Bananmos wrote:Is there a chance we could try a version of it out ourselves soon?
I'm not quite completely done with the code just yet and out of time for tonight - I should be able to make a build with the changes tomorrow night though.
Bananmos wrote:The actual write in an STx instruction should occur over a full CPU cycle if I'm not mistaken. And on NTSC that would correspond to 3 PPU pixels output. So I'd expect three dots to be visible rather than just one.
Technically, the "write" portion of the CPU cycle only lasts half a cpu cycle, iirc. So at most it'd be 1.5 PPU cycles? Either way, it's just simpler to represent it as it is in the emulation core. The CPU runs 3 PPU cycles before every CPU cycle (in the emulator), the dot where the write appears is the last PPU cycle that was competed before the write was performed. e.g: if the write is at cycle 30, then cycle 30 is done running, and the write occurred right before cycle 31 was run.
Bananmos wrote:does Mesen emulate and/or let you control this semi-random alignment of CPU/PPU phase?
There is an option to not reset the PPU when resetting the console (to mimic the original famicom) in the emulation settings (advanced tab) - you can use this to change the alignment by resetting. (Because of recent changes, the reset trigger is only processed at scanline 240 cycle 0, so the PPU will always be on scanline 240 at the end of reset - it should still cause the PPU's alignment to change each time, though.). Alternately, you can also just edit the emulator's state & change the PPU's cycle manually - that should also do the trick.
gauauu wrote:Is there a way (or can you add a way) to toggle that option from the "no game is loaded" view, or on the main window somewhere?
Even toggling the option won't work actually - unless the debugger window is opened, breakpoints are never triggered. What I could do is use the "Developer Mode" setting as a switch and force the debugger to open up automatically if the game is about to crash (by executing an invalid opcode) if dev mode is on - at that point you should be able to just reset the game and debug it normally.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

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

Post by lidnariq »

Bananmos wrote:I am a bit confused as to why it only shows a single dot for each scanline though? The actual write in an STx instruction should occur over a full CPU cycle if I'm not mistaken. And on NTSC that would correspond to 3 PPU pixels output. So I'd expect three dots to be visible rather than just one.
M2 is high for precisely 15/8 of a pixel, at least on NTSC. We still don't know what 2CA07 or UA6527P duties are.

/PPUSEL (or whatever you want to call the signal going into PPU pin 13) should have that same signal, delayed by two gate times. Given that /ROMSEL is delayed about 30ns ... it's probably 50ns delayed, give or take? That's roughly one more master clock cycle.

Krzysiobal has stated that CPU bus is not necessarily stable by the time M2 rises—he's had to adjust timing in his hardware to latch things on a rising edge of /ROMSEL instead of a falling edge—and it seems likely that this could be related to the glitchiness of writes to $2003.



Oh, hey, I noticed (and forgot due to lack of frequent use) that I seem to be unable to specify a file from the command line?
Last edited by lidnariq on Fri Feb 16, 2018 11:43 am, edited 1 time in total.
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 »

I've often dreamed about some kind of a remote debugging protocol (probably over sockets) that would allow source-level debugging from an editor like Visual Studio Code by retrieving information about the registers and other stuff from the debugger, and by being able to control the emulator's execution (stepping, etc).

Consider this a very, very low priority request since I don't have any immediate use for it. :)
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi
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 »

Sour wrote:I think choosing the colors might not actually be necessary this way? Every color seems relatively easy to distinguish? And should still be visible against most backgrounds.
Looks OK to me. I guess we'll have to give this a try in different games to see how well the color scheme works in practice.
I've tried to add as much as I could here (and ended up making icons for the run ppu options to be able to put them too). Anything that seems to be missing?
Looks great! The meanings of the PPU icons are very clear. I'm sure it'll be very handy to have all these options just one click away.

I was just now using Mesen and thought of a few more suggestions/requests:

- Add a "grayscale" option to the "Palette" dropdown in the CHR Viewer tab: This is so that we can see tiles clearly even when the game is flashing the palettes or they're all blanked out during transitions or something. Being able to force a grayscale palette (or maybe 4 different color gradients, so that the attribute information is still visible) on the Nametable viewer could be useful as well, so it's possible to analyze screen-drawing routines that run during screen transitions.

- Keep both "Freeze" and "Unfreeze" options (and possibly "Toggle"?) available in the Memory Viewer's context menu: It's not uncommon for me to freeze scattered addresses, so it would be very convenient if I could select a range containing multiple frozen addresses to unfreeze then all at once, but the way it is now, the "Unfreeze" option only appears if ALL selected addresses are frozen, so I have to either unfreeze one by one or freeze an entire range and then unfreeze it (I'm pretty sure that this last solution could have undesired side effects if the game was running though, since multiple unrelated addresses would be frozen for a while).

And now for another low-priority request: Would it be possible to graphically display the final waveform in the APU Viewer? I haven't done much audio coding for the NES yet, but I imagine it could be useful to step through APU update code and actually see how each write affects the output. Maybe this could be used to analyze cracks and pops or other problems that are difficult to hear.

EDIT: I just noticed that there's no mirroring information at all in the Nametable Viewer, and this is kind of a big deal, since mirroring greatly impacts how scrolling engines work, and there are a few special effects that make use of rapid mirroring switching... I don't see any room where to put the mirroring information though, so I can't really think of a good solution for this.
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 »

I just though of a way to handle the palette issues I mentioned in the last post (having palettes that are not affected by the game so that we can still see pattern and name tables even when the palettes are flashing or blank):

Add a set of alternate palettes after the 8 actual palettes the system has, pre-populated with grayscale, other gradients, or anything you see fit, but keep them editable just like the real palettes, so that users can setup their own alternate palettes if the built-in ones don't work for them (reversed brightness or something). Then, in the CHR viewer, you can pick "Alt. 0", "Alt. 1", "Alt. 2", etc. as the palette to display tiles with, and in the Nametable Viewer, you could check "Use alternate palettes" to use the first 4 alternate palettes instead of the real palettes.

What do you think?
Sour
Posts: 891
Joined: Sun Feb 07, 2016 6:16 pm

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

Post by Sour »

lidnariq wrote:Oh, hey, I noticed (and forgot due to lack of frequent use) that I seem to be unable to specify a file from the command line?
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.
thefox wrote:I've often dreamed about some kind of a remote debugging protocol (probably over sockets)
In theory, I guess this wouldn't be overly hard to create on the emulator side of things, but creating/maintaining the addon for it for VS Code and/or other IDEs would probably require a lot of time/effort. I'm not saying it'll never be a thing, but if it is, it probably won't be anytime soon :p
tokumaru wrote:a few more suggestions/requests:
-Freeze/Unfreeze: I'll change unfreeze to be available whenever a frozen address is selected
-APU Viewer: I actually originally wanted to do this (displaying the wave form for each channel independently), but it turned out to be a lot trickier than I had anticipated (e.g would need to keep the output volume for every single channel on every single APU cycle in a buffer to be able to display it in the UI at different time scales, etc.), mostly because I didn't want to negatively affect Mesen's general performance, etc. I might try to get this done at some point in the future, though.
-Nametable mirroring: Technically, for the most part, you can visually see the mirroring info (and you can also see the exact nametable mappings at the bottom of the debugger window, too), but I could add a mirroring field to the NT viewer, too (someone else actually asked the same thing a few days ago, too)
-CHR/Nametable grayscale/custom palettes: I'll have to see about this - the palette viewer/editor is directly connected to the PPU's palette RAM, so adding custom palettes in there can't really be done as-is (I'd need another way to store the custom palettes, etc.). Preset palettes (e.g 4x 3 different shades of the same color + black) might be a little simpler to get done.
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 »

Sour wrote:
thefox wrote:I've often dreamed about some kind of a remote debugging protocol (probably over sockets)
In theory, I guess this wouldn't be overly hard to create on the emulator side of things, but creating/maintaining the addon for it for VS Code and/or other IDEs would probably require a lot of time/effort. I'm not saying it'll never be a thing, but if it is, it probably won't be anytime soon :p
Yeah actually I was thinking that somebody else (like me) would be creating the VS Code (or whatever else other IDE) add-on. I might give it a go at some point.
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi
russellsprouts
Posts: 53
Joined: Sun Jan 31, 2016 9:55 pm

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

Post by russellsprouts »

I started making a VSCode extension for editing CA65 assembly code. I had syntax highlighting, hover to see the values of constants, and jump to definition implemented at least. I should dig it out and make it presentable for others to use. It parses the CC65 debug info file to provide all the information.

VSCode implements the language server protocol, which is a standard that many IDEs use, so with just a bit of glue it could integrate with a bunch of editors.

VSCode also has a debugging server protocol, which could plug into an emulator for live debugging using the source.
Post Reply