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.
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?
$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"
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
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!
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.
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...
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.
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
-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
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
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.