Mesen Debugger - Feedback/Feature Requests? (2018 edition)
Moderator: Moderators
Re: Mesen Debugger - Feedback/Feature Requests? (2018 editi
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?
Re: Mesen Debugger - Feedback/Feature Requests? (2018 editi
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.
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.
Re: Mesen Debugger - Feedback/Feature Requests? (2018 editi
Wow, you rock... Every time I need a feature, turns out it's already there and I just haven't discovered it. Again, thanks!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
My games: http://www.bitethechili.com
Re: Mesen Debugger - Feedback/Feature Requests? (2018 editi
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.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?
Re: Mesen Debugger - Feedback/Feature Requests? (2018 editi
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.
Re: Mesen Debugger - Feedback/Feature Requests? (2018 editi
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.
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.
Re: Mesen Debugger - Feedback/Feature Requests? (2018 editi
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?
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?
My games: http://www.bitethechili.com
Re: Mesen Debugger - Feedback/Feature Requests? (2018 editi
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.
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?
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:Is there a chance we could try a version of it out ourselves soon?
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: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.
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.Bananmos wrote:does Mesen emulate and/or let you control this semi-random alignment of CPU/PPU phase?
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.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?
Re: Mesen Debugger - Feedback/Feature Requests? (2018 editi
M2 is high for precisely 15/8 of a pixel, at least on NTSC. We still don't know what 2Bananmos 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.
/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.
Re: Mesen Debugger - Feedback/Feature Requests? (2018 editi
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.
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
Re: Mesen Debugger - Feedback/Feature Requests? (2018 editi
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.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 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'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?
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.
Re: Mesen Debugger - Feedback/Feature Requests? (2018 editi
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?
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?
Re: Mesen Debugger - Feedback/Feature Requests? (2018 editi
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.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?
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 :pthefox wrote:I've often dreamed about some kind of a remote debugging protocol (probably over sockets)
-Freeze/Unfreeze: I'll change unfreeze to be available whenever a frozen address is selectedtokumaru wrote:a few more suggestions/requests:
-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.
Re: Mesen Debugger - Feedback/Feature Requests? (2018 editi
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.Sour wrote: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 :pthefox wrote:I've often dreamed about some kind of a remote debugging protocol (probably over sockets)
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi
-
- Posts: 53
- Joined: Sun Jan 31, 2016 9:55 pm
Re: Mesen Debugger - Feedback/Feature Requests? (2018 editi
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.
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.