Mesen Debugger - Feedback/Feature Requests? (2018 edition)
Moderator: Moderators
Re: Mesen Debugger - Feedback/Feature Requests? (2018 editi
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.
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.
Re: Mesen Debugger - Feedback/Feature Requests? (2018 editi
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.Maybe 1 color for each ppu register (different colors for read/write, so ~10 colors?)
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?
Re: Mesen Debugger - Feedback/Feature Requests? (2018 editi
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"
$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"
Re: Mesen Debugger - Feedback/Feature Requests? (2018 editi
Though I'd probably number the colors differently for consistency with how color numbers are interpreted in the reset of Mesen: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
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
Re: Mesen Debugger - Feedback/Feature Requests? (2018 editi
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: 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!
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: 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!
Re: Mesen Debugger - Feedback/Feature Requests? (2018 editi
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: 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.
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: 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.
Re: Mesen Debugger - Feedback/Feature Requests? (2018 editi
For my own edification, I've marked up your screenshot there, adding what the sync, colorburst, and (NTSC-only) overscan would look like:
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...Re: Mesen Debugger - Feedback/Feature Requests? (2018 editi
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 :pBananmos 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.
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.
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)lidnariq wrote:Although maybe some kind of ruler during hblank might possibly be...
Re: Mesen Debugger - Feedback/Feature Requests? (2018 editi
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.
Re: Mesen Debugger - Feedback/Feature Requests? (2018 editi
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.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.
It doesn't look like that information is in the tooltip yet, though... but yeah, that'd be a good place to put it.And when it's not the tooltip should suffice.
Re: Mesen Debugger - Feedback/Feature Requests? (2018 editi
Good to see some debateI disagree. There are tricks involving mixed $2005/$2006 writes
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
Re: Mesen Debugger - Feedback/Feature Requests? (2018 editi
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.
Re: Mesen Debugger - Feedback/Feature Requests? (2018 editi
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
-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
Re: Mesen Debugger - Feedback/Feature Requests? (2018 editi
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: 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:
Ends up looking like this in Mesen's debugger:
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".
...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:
...results in the code in Mesen looking like so:
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.
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: 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
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
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
Last edited by Bananmos on Tue Feb 20, 2018 8:20 am, edited 1 time in total.
Re: Mesen Debugger - Feedback/Feature Requests? (2018 editi
Whoops, that's because of the "Marked" column I added last night - I'll get it fixed after work.Bananmos wrote:it looks like I cannot set any breakpoints
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.