It is currently Wed Jun 20, 2018 7:40 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 121 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6, 7 ... 9  Next
Author Message
PostPosted: Sun Feb 18, 2018 4:12 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 416
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.

Attachment:
eventviewer2.png
eventviewer2.png [ 44.92 KiB | Viewed 614 times ]


Top
 Profile  
 
PostPosted: Sun Feb 18, 2018 6:38 pm 
Offline

Joined: Wed Mar 09, 2005 9:08 am
Posts: 410
Quote:
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?


Top
 Profile  
 
PostPosted: Sun Feb 18, 2018 6:58 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7217
Location: Seattle
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"


Top
 Profile  
 
PostPosted: Sun Feb 18, 2018 7:44 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20162
Location: NE Indiana, USA (NTSC)
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


Top
 Profile  
 
PostPosted: Sun Feb 18, 2018 9:15 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 416
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:
Attachment:
eventviewer3.png
eventviewer3.png [ 60.7 KiB | Viewed 572 times ]

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!


Top
 Profile  
 
PostPosted: Sun Feb 18, 2018 9:40 pm 
Offline

Joined: Wed Mar 09, 2005 9:08 am
Posts: 410
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:
Attachment:
YearsBehind_missing_ppuwrites.png
YearsBehind_missing_ppuwrites.png [ 50.81 KiB | Viewed 563 times ]


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.


Top
 Profile  
 
PostPosted: Sun Feb 18, 2018 9:43 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7217
Location: Seattle
For my own edification, I've marked up your screenshot there, adding what the sync, colorburst, and (NTSC-only) overscan would look like:
Attachment:
eventviewer3_sync_marked.png
eventviewer3_sync_marked.png [ 4.67 KiB | Viewed 559 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...


Top
 Profile  
 
PostPosted: Sun Feb 18, 2018 9:54 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 416
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)


Top
 Profile  
 
PostPosted: Sun Feb 18, 2018 10:00 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20162
Location: NE Indiana, USA (NTSC)
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.


Top
 Profile  
 
PostPosted: Sun Feb 18, 2018 11:14 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10513
Location: Rio de Janeiro - Brazil
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.

Quote:
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.


Top
 Profile  
 
PostPosted: Mon Feb 19, 2018 12:46 am 
Offline

Joined: Wed Mar 09, 2005 9:08 am
Posts: 410
Quote:
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 :)


Top
 Profile  
 
PostPosted: Mon Feb 19, 2018 1:10 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10513
Location: Rio de Janeiro - Brazil
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:


Top
 Profile  
 
PostPosted: Mon Feb 19, 2018 9:44 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 416
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


Top
 Profile  
 
PostPosted: Tue Feb 20, 2018 7:52 am 
Offline

Joined: Wed Mar 09, 2005 9:08 am
Posts: 410
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:
Attachment:
DebuggerCrash.png
DebuggerCrash.png [ 405.21 KiB | Viewed 427 times ]


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:
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:
Attachment:
DrawActorsPriorityLevel.png
DrawActorsPriorityLevel.png [ 72.49 KiB | Viewed 427 times ]


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:
.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:
.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:
Attachment:
WriteChrPageDragon1.png
WriteChrPageDragon1.png [ 120.68 KiB | Viewed 419 times ]

Attachment:
WriteChrPageDragon2.png
WriteChrPageDragon2.png [ 125.58 KiB | Viewed 419 times ]

Attachment:
WriteChrPageDragon3.png
WriteChrPageDragon3.png [ 41.43 KiB | Viewed 419 times ]


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.

Top
 Profile  
 
PostPosted: Tue Feb 20, 2018 8:08 am 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 416
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.

Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 121 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6, 7 ... 9  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 6 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group