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
rainwarrior
Posts: 8731
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

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

Post by rainwarrior »

Sour wrote:
rainwarrior wrote:Also, not related to this, but I believe the 5B frequencies are off by 1?
Are you asking because you noticed the difference by listening to it, or because you checked the code?
There is in fact a very suspicious looking +1 here: https://github.com/SourMesen/Mesen/blob ... udio.h#L58
Not sure why it's there, but that would probably be the cause?
I noticed the difference audibly while working on a 5B audio test, but I also checked with a recorded output to make sure it wasn't just the dynamic pitch synchronization thing.

I didn't analyize your code, but that +1 in your code implementation is probably the cause. A weird thing with 5B is that the "0" value seems to give a division by zero in the frequency formula, so maybe that creates a temptation to "fix" this with +1. (I'm not sure whether the chip halts at pitch 0 or what, but pitch 1 is already above audible at 55kHz.)
Sour wrote:
samophlange wrote:Yeah, I'd like to request the same thing! I run in to this a lot when doing large scale refactors or setting up little test projects.
The "Break on CPU crash" option I mentioned should work - let me know if it doesn't though.
It works but you have to set it up before you try to run the ROM, because the option you need to set is inside the debugger that you can't open without a running ROM.
User avatar
Banshaku
Posts: 2417
Joined: Tue Jun 24, 2008 8:38 pm
Location: Japan
Contact:

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

Post by Banshaku »

I had a similar issue with one of my bug. My workaround was to start a different rom, pause it, start the one which fail and the new rom would start in paused mode (maybe by design, not sure). Then after that I would be able to set a breakpoint at the desired location.

It would be useful to have a mode in preference to not auto-start like nintendulor F2. It would be quite useful for those case.
User avatar
rainwarrior
Posts: 8731
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

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

Post by rainwarrior »

I think the real problem is just that the halt instruction boots you from the game and unloads it. That's kind of weird in itself. The cartridge doesn't fly out of the NES when that instruction is hit.

Displaying a message that the game has crashed is cool, but I think it would make a lot more sense if the emulator just paused or halted but left you with the game, giving you the option to reset.
User avatar
Banshaku
Posts: 2417
Joined: Tue Jun 24, 2008 8:38 pm
Location: Japan
Contact:

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

Post by Banshaku »

Just the image of the cartridge flying out of the nes: Attack of the killer nintendo :lol:

Now on a serious note, yes, to stop and show the debugger where the program halted could help but sometime it could be that it just went on a wrong address and ended up in data. I don't know if there is a stack of the last commands before it failed in that case. But still, that is better than just stopping the emulator from a developer point of view. A user would just need the emulator to stop like it is doing at the moment.
Sour
Posts: 890
Joined: Sun Feb 07, 2016 6:16 pm

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

Post by Sour »

To be honest, the whole "close the game on crash" has been pretty annoying on my end too, given how often I end up testing/fixing games that crash due to bugs in obscure mappers, etc. It was originally meant to be a user-friendly way to handle CPU crashes for end users, but for people trying to debug ROMs, it has the opposite effect.

I changed it so that it no longer does this when Developer Mode is enabled, which makes a lot of sense, imo. In Dev Mode, it will still display the "cpu crashed" error (once per reset/power cycle), but the cpu will keep running as per usual afterwards.

The 5B audio should be fixed now, too.
User avatar
rainwarrior
Posts: 8731
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

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

Post by rainwarrior »

The debug information from ca65 unfortunately doesn't have any output for anonymous labels.

However, it might be nice to have any branch within view (or maybe within 128 bytes of in view) to a location without a label automatically generate a label there? That'd be useful even when not using ca65.

da65 has a convention for automatically naming labels by their address, i.e. "LFF35:" would go to $FF35. The specific name is probably less important than just the visual break you get for a label.
Sour
Posts: 890
Joined: Sun Feb 07, 2016 6:16 pm

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

Post by Sour »

Dynamically generating labels around the current view would be sort of hard - the disassembly is generated when the debugger updates (e.g when stepping through the code), but not when scrolling (everything is already disassembled ahead of time at that point). It would also be a bit tricky to handle scrolling properly if labels appear/disappear as the user scrolls.

I've been thinking about it for a little bit and there's a couple of options I could probably do:
A) Make the disassembler keep track of all jump destinations it finds while disassembling and add fake temporary "labels" for them, which might look something like this:

Code: Select all

     $8054:           
8054   LDA Sprites,X           
8055   STA OamData,X           
8056   INX                     
8057   CPX #$10                 
8058   BNE $8054
These wouldn't show up in the label list, though (as they wouldn't be real labels). This would technically work for any type of memory (RAM, ROM), but when disassembling unverified bytes you could end up with random labels all over (so it would probably require ignoring jump from inside unverified code to verified code, etc.)

B) Create proper labels for all of PRG ROM as the code runs, e.g automatically create a real label whenever a label-less jump target is found (if the target is in PRG ROM). This would be a lot less of a hack, code-wise, and has the benefit that the labels would be permanent, but maybe it would result in too many labels? This would also be limited to PRG ROM code that already been executed by the CPU. In this case you might end up with this:

Code: Select all

     L38054:
8054   LDA Sprites,X           
8055   STA OamData,X           
8056   INX                     
8057   CPX #$10                 
8058   BNE L38054
(assuming that $8054 in CPU memory maps to $38054 in the PRG ROM, for example)

Personally I'm more inclined to go with B) - it would be a lot more straightforward to implement, and would probably be the best when trying to reverse-engineer/annotate a ROM's code. The main downsides would be that it wouldn't work for FDS games, or when games execute code from RAM.

If B) doesn't feel like it would be useful, though, I can try to figure out something else/better.
Sour
Posts: 890
Joined: Sun Feb 07, 2016 6:16 pm

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

Post by Sour »

A quick test gives something like this:
autolabels.png
These are regular labels that get auto-generated by the debugger as it runs, so yes, they can be renamed, etc.
As I have it now, they can't really be erased while the option to create them is enabled, though. (they will get recreated after being deleted).

The labels are only created once the CPU reaches the branch instruction (otherwise there is no guarantee that the target will be the same once the instruction is reached, because of bank switching, etc.). In terms of integration with CA65, that means they would get deleted every time you power cycle or reload the ROM, but get recreated each time as you run the code again.

I'm thinking of adding 2 separate options to control this:
-1 option to control if labels should be auto-generated for PRG ROM jumps (behavior would be identical to 0.9.6 when disabled)
-1 option on the label list to "Show generated labels", which would show/hide those labels in the label list (but they would still be used in the disassembly, whether or not they are shown in the list). This would help keep the list shorter and easier to work with (and the list would get populated as you rename the labels manually)
Sour
Posts: 890
Joined: Sun Feb 07, 2016 6:16 pm

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

Post by Sour »

yaros wrote:Is it possible to keep the generated/renamed labels in the "Workspace.xml" file along with hash of the rom, and leave them in place if hash is not changed?
This is already the case, assuming you're not loading a .dbg file. Every time a .dbg file is loaded, it resets all existing labels, which would include these auto-generated labels (which is what I was referring to in my previous post)

Saving the PRG ROM's CRC in the workspace.xml file and auto-resetting the generated labels when that changes shouldn't be all that hard, though (I've also been meaning to add a similar option with regards to the CDL files for a while now, but never got around to it).

I'll try to finish this feature up at some point this week if I can.
User avatar
koitsu
Posts: 4201
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

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

Post by koitsu »

Some minor bug reports (mainly cosmetical):

Debug -> Memory Tools -> Memory Viewer tab. The "View" pulldown (for "CPU Memory", "PPU Memory", etc.) is not wide enough to display the full name of some entries, particularly "Sprite (OAM) RAM" (shown as Sprite (OAM) RA) and "Secondary OAM RAM" (shown as Secondary OAM). I know this varies per OS/theme/DPI/etc. a bit, but it looks like there's a lot of space available to the right of that pulldown..... ;-)

Debug -> Memory Tools -> Memory Viewer tab. The latter two "View" pulldowns should be syntactically similar; "Sprite (OAM) RAM" and "Secondary OAM RAM" seem weird (particularly the inconsistent use of parenthesis). I know the secondary OAM table is unique/sort of an oddity, but still. Might I suggest alternatives:

- "Sprite/OAM RAM" + "Secondary OAM RAM"
- "Primary OAM RAM" + "Secondary OAM RAM"
- "Primary (OAM) RAM" + "Secondary (OAM) RAM"
- "Primary Sprite RAM" + "Secondary Sprite RAM"

If this conflicts with existing naming schemes you have throughout the program and would have to do a global replace + ensure all the fields are wide enough for changes, don't bother.

Debug -> Memory Tools -> Memory Viewer tab. Why is the "View" pulldown in a completely different theme/thing than the Access Counters "View" pulldown and several others under Memory Tools? Maybe it's because it has horizontal section dividers?

Debug -> APU Viewer -> there are inconsistencies in the spacing/alignment of some of these fields:

- Square 1 and Square 2: Sweep Unit "Period" and "Shift" texts are slightly indented compared to the checkboxes/states above
- Triangle: "Period", "Timer", "Frequency", and "Output Volume" are slightly indented. This may be because
- Triangle: Change "Sequence Position" to "Sequence Pos" or "Sequence Pos." so that the text fits within the space available and doesn't look "too close" to the actual field data

- Square 1, Square 2, and Noise: Envelope checkboxes/states ("Start Flag", etc.) need to be shifted to the right a little bit to be consistent with the rest of the other sections/UI
- Square 1, Square 2, and Noise: "Counter", "Divider", and "Volume" need to be aligned properly with above checkboxes/states once fixed

- DMC: "Bytes remaining" should have a capital "R"
- DMC: "Sample Rate" "Hz" suffix should be moved over to the left a little bit (3-4 pixels? See Square 1 & 2, or Triangle for examples)
- Frame Counter: "Current Step" need to be aligned properly with above checkboxes/states (moved to left a couple pixels)
- Frame Counter: "5-step Mode" should have a capital "M"

- Channel Control: horizontal spacing between "columns" of checkboxes should be more consistent/evenly distributed
- Channel Control: "Namco" should be "N163", "Sunsoft" should be "5B" (rest of UI uses chip names, not company names, ex. MMC5, VRC6)

For the APU Viewer, I've attached a screenshot with some vertical alignment lines to give you an idea of what I'm talking about.

Some of my above items might seem inconsistent in their recommendations, but the overall goal is: make all the stuff consistent. Haha :D

Not bragging, but yeah, I have an incredible eye for this sort of thing. I can often tell if something is 1 pixel off on a 24" @ 1920x1200 display; I've been called nuts (and OCD) more than once. ;-) The amusing part: I have *horrible* vision -- I got checked last week: nearsighted, 20/200 (not a typo).

P.S. -- Event Viewer is absolutely mind-blowing. When I discovered this (it's been a while since I've used Mesen), I sat here with my mouth agape.

P.P.S. -- If you would prefer this be filed in GitHub Issues, happy to do so (I just now noticed the "Report a bug" pulldown).
Attachments
ss.png
Sour
Posts: 890
Joined: Sun Feb 07, 2016 6:16 pm

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

Post by Sour »

Thanks! Most of these should be fixed now.
koitsu wrote:Debug -> Memory Tools -> Memory Viewer tab. Why is the "View" pulldown in a completely different theme/thing than the Access Counters "View" pulldown and several others under Memory Tools? Maybe it's because it has horizontal section dividers?
Yes, I can't really do much about it. I turned on "owner draw" for the dropdown list items to display proper separators (as opposed to just an empty option filled with dashes), but the dropdown's styling, for some reason (on Win 10 this is limited to the background color being different, but I think Win 7 makes it more obvious?). IIRC, I tried fixing this when I first implemented the dropdown, but could not find a way to manually draw the contents of the dropdown without altering the dropdown's style.
koitsu wrote:P.S. -- Event Viewer is absolutely mind-blowing. When I discovered this (it's been a while since I've used Mesen), I sat here with my mouth agape.
Most of the credit for the event viewer goes to Bananmos for making the request in the first place :p
Sour
Posts: 890
Joined: Sun Feb 07, 2016 6:16 pm

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

Post by Sour »

yaros wrote:Can the debugger auto assign labels to those jumps if they are within the same procedure?
FYI, 0.9.7 adds a "Auto-create jump labels" feature to the debugger, which will create labels for all jump locations that the debugger finds while the code is executing (this feature is available whether or not you're using .dbg files)

I didn't have the time to make them persist after a .dbg file is loaded yet, though. You can technically work around this by either disabling the option to automatically load .DBG files or by disabling the "Reset workspace labels [...] before importing DBG/MLB files" option found in File->Workspace->Import Settings, though. Keep in mind that disabling this option may cause labels that no longer exist (e.g because you changed the code and rebuilt the ROM) to remain in the label list, so it's not a perfect solution.
User avatar
never-obsolete
Posts: 411
Joined: Wed Sep 07, 2005 9:55 am
Location: Phoenix, AZ
Contact:

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

Post by never-obsolete »

So I finally took the time to download Mesen after fceux crashed because I tried a mmc3/chr-rom/chr-ram/wram combo.

I've only briefly tried out the debugging features, but I was immediately impressed. The event viewer is really helpful and showed me that my irq fires 1 scanline early for a few frames after reset. Something I hadn't noticed, even on hardware. Asm6 integration is a plus.

At this point, I don't see a reason to switch back. I'm going to dig deeper into the rest of its features and post any feedback if I have any. Thanks for all the work put into this.
. That's just like, your opinion, man .
Sour
Posts: 890
Joined: Sun Feb 07, 2016 6:16 pm

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

Post by Sour »

Sour wrote:
bleubleu wrote:The one thing I would tweak is that I would highlight tiles/att changes regardless of whether the data has actually changed or not
Yea, I figured this was less than ideal. The current implementation is strictly a UI-side feature and it would actually require a lot more changes to be able to properly highlight all writes (as there is currently no tracking of PPU read/writes in the debugger). I'll add it to my list as a future improvement idea, but it might be a while before I can get to it.
And so here we are, 9 months later and it's done! I added a "Ignore write that do not alter data" option to keep the old behavior, too, in case they are scenarios where the older behavior is useful. By default all tile/attribute updates (writes) done during the last frame are now highlighted, even if the value hasn't changed.

These changes required a number of changes to the core (because nametable ram did not work the same way as CHR RAM/ROM did for historical reasons) and I was more or less forced to break save state compatibility in the process. I've also added access counters for CHR ROM/RAM and nametable RAM, and the memory viewer now properly highlights reads and writes in chr rom/ram, palette and nametable ram, too. (Reads to palette ram aren't tracked for the sake of performance). This also fixes the display of the nametable mappings at the bottom of the nametable window (it should now always accurately represent the real state of the NES, including when CHR ROM/RAM is mapped between $2000-2FFF)
bleubleu wrote:If I write "ptr,10" it will show me the 10 first element of the array starting at ptr.
I'm not sure if I ever mentioned this, but it's been possible to display arrays in the watch for a now, syntax is "[address, byte count]". e.g: [mylabel, 16] or [$A0, 16]
User avatar
bleubleu
Posts: 108
Joined: Wed Apr 04, 2018 7:29 pm
Location: Montreal, Canada

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

Post by bleubleu »

Dude, thank you so much.

Just this weekend I was debugging a function to clear text, and I wasnt sure if I was writing at the right location and I was like "man, it would be so nice to be able to see the tile updates even if the value didnt change".

I didn't realize the array feature was already working. I will definitely use that all the time.

Coffee money incoming!

-Mat
Post Reply