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

Sour
Posts: 890
Joined: Sun Feb 07, 2016 6:16 pm

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

Post by Sour »

Yea, that turned out to be the best way to do it, thanks for the idea!
I had to make some changes to breakpoints, so I'll need to test things out a bit more, but for now it's working.
Still need to get color customization done, too.
eventviewer2.png
Bananmos
Posts: 552
Joined: Wed Mar 09, 2005 9:08 am
Contact:

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

Post by Bananmos »

Maybe 1 color for each ppu register (different colors for read/write, so ~10 colors?)
Well, there's very few registers in the NES that are both read/write. Of the PPU ones there's only $2007/$2004, and reading those is of limited value and only done by a handful of games.

And given that the number of easily distinguishable colours are somewhat limited, I'd be tempted to say that distingushing reads and writes is perhaps not the best use of them?
lidnariq
Posts: 11430
Joined: Sun Apr 13, 2008 11:12 am

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

Post by lidnariq »

I count a total of 12 different functions on the PPU's CPU interface:
$2000w, $2001w, $2002r, $2003w, $2004r, $2004w, $2005a, $2005b, $2006a, $2006b, $2007r, $2007w

(Visual2c02 shows the same 12—look near node #396)

Failing to distinguish read vs write only saves you two. Failing to distinguish first vs 2nd also only saves you two.

The 12 evenly-spaced colors around the edges of the RGB color cube are fairly easily distinguished: 1 2 3 4 5 6 7 8 9 A B C

although you may wish additional colors for "breakpoint" and for "reads/writes to non-extant registers"
tepples
Posts: 22705
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 »

lidnariq wrote:The 12 evenly-spaced colors around the edges of the RGB color cube are fairly easily distinguished: 1 2 3 4 5 6 7 8 9 A B C
Though I'd probably number the colors differently for consistency with how color numbers are interpreted in the reset of Mesen:

1 2 3 4 5 6 7 8 9 A B C

Or to keep them from being oversaturated:

1 2 3 4 5 6 7 8 9 A B C
Sour
Posts: 890
Joined: Sun Feb 07, 2016 6:16 pm

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

Post by Sour »

I ended up pretty much half-randomly assigning the default color palette. It's more or less impossible to come up with something perfect considering there are 16 colors to select at the moment. If anyone comes up with something that's better, feel free to post a screenshot of the color setup window & I can update the defaults to match.

Distinguishing the 1st/2nd write on the PPU registers that use them would be possible without too much effort, I think, if that's something that would make sense. Could also add APU register read/writes (as 2 colors) - I'm not sure there is much of a reason to do so, though? Can be achieved via the breakpoint marking functionality if really needed, too.

Overall, it looks like this now:
eventviewer3.png
Build with the latest changes: download (Windows-only to save myself a bit of time)

Let me know what you think.

Edit: Forgot to actually upload the build, fixed!
Bananmos
Posts: 552
Joined: Wed Mar 09, 2005 9:08 am
Contact:

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

Post by Bananmos »

People may have different opinions on this one, but I don't think there's much point in distinguishing the 1st/2nd write to $2005/$2006. In normal circumstances it should be obvious that you're doing a double-write. And when it's not the tooltip should suffice.

I kind of liked the older default colour scheme better as writes to $2005/$2006 are much harder to distinguish now. But now that the default can be changed I can just change it back to my liking, so just figured I'd mention it in case you like feedback on the defaults.

The latest version does seem to have a bug on my side though: It only shows the PPU writes for a partial frame. See this screenshot from Years Behind again:
YearsBehind_missing_ppuwrites.png
I was thinking it might be running into some fixed limit for the number of events per frame? But unticking certain events seems to have no effect either.
lidnariq
Posts: 11430
Joined: Sun Apr 13, 2008 11:12 am

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

Post by lidnariq »

For my own edification, I've marked up your screenshot there, adding what the sync, colorburst, and (NTSC-only) overscan would look like:
eventviewer3_sync_marked.png
eventviewer3_sync_marked.png (4.67 KiB) Viewed 4299 times
Now that I've actually done this... yeah, I can see it's not particularly useful. Although maybe some kind of ruler during hblank might possibly be...
Sour
Posts: 890
Joined: Sun Feb 07, 2016 6:16 pm

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

Post by Sour »

Bananmos wrote:writes to $2005/$2006 are much harder to distinguish now
[...]
I was thinking it might be running into some fixed limit for the number of events per frame? But unticking certain events seems to have no effect either.
Whoops, didn't even notice both $2005/2006 had similar colors. I'll try to come up with something more reasonable - at the moment it was pretty much selected on a "I want to get this done tonight" basis :p

And your assumption is correct, actually there is a limit of 1000 "events" logged per frame. The display options do not affect the limit, either. 1000 was probably plenty when only writes were being logged, but with all the new things getting logged, it's clearly not enough. I'll switch it to being dynamic with no hard limit, instead.
lidnariq wrote:Although maybe some kind of ruler during hblank might possibly be...
Not too sure I'm understanding what you mean - maybe adding an optional grid every X clocks would do it? Slightly unrelated, but I was also thinking of changing the background color for the scanlines where it is safe to run the sprite DMA (which is slightly different between PAL & NTSC, afaik)
tepples
Posts: 22705
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 »

At least the sync column is useful to tell where the final $2005 write falls relative to v_vertical=t_vertical on the pre-render line, which happens continuously during the sync pulse between that line and the first picture line.
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 »

Bananmos wrote:People may have different opinions on this one, but I don't think there's much point in distinguishing the 1st/2nd write to $2005/$2006.
I disagree. There are tricks involving mixed $2005/$2006 writes (such as mid-screen scroll changes or even this) that may make the order of the writes significantly harder to distinguish. There's also the case when the first write is done in advance for timing reasons so there may be a large gap before the second write.
And when it's not the tooltip should suffice.
It doesn't look like that information is in the tooltip yet, though... but yeah, that'd be a good place to put it.
Bananmos
Posts: 552
Joined: Wed Mar 09, 2005 9:08 am
Contact:

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

Post by Bananmos »

I disagree. There are tricks involving mixed $2005/$2006 writes
Good to see some debate ;)

I'm not saying it's not useful at all, just that I'm not sure the this-is-the-first-or-second-write information needs to be that much in-your-face to warrant colour coding it, if the colour space is limited. The screenshots I posted also mess with the latch order as it's doin a $2006/$2005/$2005/$2006 sequence. But I think the green-red-red-green pattern communicates that well enough in the picture.

Anyway, with configurable colours I could always set both writes to look the same, so I don't particularly mind if it does get distinguished...

And nice trick with avoding the first address write, 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 »

I was disagreeing that the distinction is trivial for a human to make, but I actually agree that using different colors for that is overkill and could even cause confusion. Having that information in the tooltip would be cool though. I should've been more clear. :mrgreen:
Sour
Posts: 890
Joined: Sun Feb 07, 2016 6:16 pm

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

Post by Sour »

Some improvements/fixes:
-Changed default color palette - should be better than before (but there is still some overlap between colors)
-Fixed 1k event limit - there should be no upper limit anymore (tested with up to ~90k events on a single frame)
-Improved the UI's refresh performance and set the FPS limit to ~30fps instead of ~15.
-Added lines to delimit the start of NMI, the last "safe" scanline where sprite DMAs work properly and when stepping in the code, it will also display the current scanline (to indicate that anything below that line will be empty)
-Tooltips for writes to 2005/2006 now have a "2nd write" flag
-Tooltips for breakpoints now display info on the breakpoint (type, address range, condition)
-It is no longer necessary to open the main debugger window for breakpoint markers to show up on the event viewer
-Added a "marker" column (abbreviated to "M") in the breakpoint list that contains a checkbox - it can be clicked to quickly mark/unmark a breakpoint (without having to open the breakpoint edit dialog)

...I think that's it. Only improvement ideas I have left at the moment would be to add another tab with a list view of all the events, in the order they occurred and maybe some option to display a grid over the image (e.g maybe every 8 pixels or such). Let me know if there's anything else that could still be improved/added.

Windows-only build: download
Bananmos
Posts: 552
Joined: Wed Mar 09, 2005 9:08 am
Contact:

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

Post by Bananmos »

Thanks! Tried the new build, and all events now show :)

I figured I would take a closer look at the debugger, and ran into a few issues:

First of all, it looks like I cannot set any breakpoints. Clicking (with either the left or right mouse button) in the "breakpoints" list box just brings up this message box:
DebuggerCrash.png
Furthermore, I figured I would try out the CA65 .dbg file support. And while it mostly works out-of-the-box, some of the results are a bit confusing. Although a disclaimer is in place: I'm not at all familliar with CA65's .dbg files, or how much of the following "bugs" could just be limitations in this format, or bugs in ca65 rather than Mesen. :)

Anyway, the following code in my .asm file:

Code: Select all

DrawActorsPriorityLevel:
    @priorityLevel = actorFlagsZP       ; unused by draw routine
    sta @priorityLevel
    ldx #MAX_ACTORS-1
@ActorLoop:
    lda actorAddrHi,x
    beq @NextActor
    lda actorFlags,x
    and #ACTOR_PRIORITY
    cmp @priorityLevel
    bne @NextActor
    stx TEMP+14
    jsr DrawActorAnimation
    ldx TEMP+14
@NextActor:
    dex
    bpl @ActorLoop
    rts
Ends up looking like this in Mesen's debugger:
DrawActorsPriorityLevel.png
A few problems with these annotations:
1) Rather than showing the original "sta @priorityLevel"/"cmp @priorityLevel", these are shown with the actorFlagsZP variable instead. Now, @priorityLevel is just a local alias for actorFlagsZP, so this isn't a terrible behaviour. But what is curious is that the sta shows the original source-line statement (sta @priorityLevel) as a comment after the line, while the cmp does not. So I am curious what this inconsistency comes from?

2) Similarly, the original "lda actorAddrHi,x" statement is shown as a comment after the "LDA $0470,X" statement, while the "lda actorFlags,x" statement does not appear after the "LDA $0410,X" statement. And I see no reason why they should differ - both are originally allocated with a ".res MAX_ACTORS" statement.

3) "numActorsToSpawn" appears out of nowhere, when the source code actually just refers to TEMP+14. numActorsToSpawn is indeed aliased to the TEMP+14 location in a totally different subroutine "LoadMap". (declared with .proc/.endproc) But the fact that LoadMap uses it for this purpose is totally irrelevant here, and very confusing.

4) Even more strange is that the "RTS" statement gets a "YIELD" comment. YIELD is a conditional macro that calls a few sub-routines in my code, and the exact sequence depends on another constant "ACTORCLASS".

Code: Select all

.MACRO YIELD
.IF (ACTORCLASS = BLOCK_ACTOR)
    jsr BlockActorYieldSub
.ELSEIF (ACTORCLASS = BLOCK_ACTOR_ATTACHED_TOP)
    jsr BlockActorAttachedYieldSub
    jsr ReadjustBlockActorAttachedTop
.ELSEIF (ACTORCLASS = CONSTRUCTION_ACTOR)
    jsr ConstructionActorYieldSub
    jsr ReadjustY
.ELSE
    jsr AnimatedActorYieldSub
.ENDIF
.ENDMACRO
...but no matter what ACTORCLASS is set to, the YIELD macro never compiles to just an RTS. So I really don't see where this association that "RTS" == "YIELD" would come from?



And another odd mystery is that this code:

Code: Select all

.macro WRITE_CHRPAGE page
    ldy #11
@loop:
    lda (NMITEMP),y
    tax
.repeat 16,i
    lda page+$100*i,x
    sta $2007
.endrep
    dey
    bpl @loop
.endmacro

.SEGMENT "DRAGONCHR"
.align $100
dragonCHR1:
.incbin "dragon1.rhc"

dragonCHR2:
.incbin "dragon2.rhc"

.align $100
dragonCHR3:
.incbin "dragon3.rhc"

WriteChrPageDragon1:
    WRITE_CHRPAGE dragonCHR1
    rts

WriteChrPageDragon2:
    WRITE_CHRPAGE dragonCHR2
    rts

WriteChrPageDragon3:
    WRITE_CHRPAGE dragonCHR3
    rts
...results in the code in Mesen looking like so:
WriteChrPageDragon1.png
WriteChrPageDragon2.png
WriteChrPageDragon3.png
Or in other words, two of the three macro expansions show up expanded, while the third one results in the macro body embedded as comments.
Last edited by Bananmos on Tue Feb 20, 2018 8:20 am, edited 1 time in total.
Sour
Posts: 890
Joined: Sun Feb 07, 2016 6:16 pm

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

Post by Sour »

Bananmos wrote:it looks like I cannot set any breakpoints
Whoops, that's because of the "Marked" column I added last night - I'll get it fixed after work.

About the DBG file support - Mesen doesn't support local aliases (it has no concept of scope), so you can't assign multiple names to the same RAM locations and have them show up as different names throughout the code. As far as I know, the DBG file does provide that information, though, so adding support for it would be possible eventually. This should mostly explain 1 & 3.

For 2 & 4, it's been a long time since I coded the CA65 support, so I don't quite remember the conditions for it to display a comment - I'll have to check.
Ideally, having the rom, dbg file & source files would be ideal to be able to debug this one, if you're willing to share them, feel free to PM them to me.

Edit: To answer your edit about the 3rd macro: Mesen by default only disassembles code that the CPU has actually executed. There are options to change this though. In this case, I would assume the first 2 were executed while the debugger was running, but not the 3rd, which is why it's collapsed (light red background = sections that have not (yet) been used as either code or data) . Mesen uses CDL files to track the data/code segments - it's possible that the .dbg files contain enough information to produce a complete CDL file, I'd need to check.
Last edited by Sour on Tue Feb 20, 2018 8:41 am, edited 1 time in total.
Post Reply