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

Post Reply
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 »

lidnariq wrote:That's partially an error in early VRC6 documentation. You have to write $24, not $04, to register $B003.

(The layout in the PPU viewer and the memory map in the debugger agree on vertical mirroring; I don't know why the "Mirroring Type" text disagrees)
I'm a little confused, then. Are Nintendulator, Nestopia, FCEUX and the PowerPak getting this behaviour wrong?
Edit: the answer is yes. Correct emulation of this is not necessary for any of the Konami games, apparently, which never fail to set bit 5 of $B003.
The wiki wrote:For the nametables, if the $20s bit of $B003 is set and the lower 4 bits of $B003 have one of the following values, CHR A10 is replaced
This mentions replacing CHR A10 but says nothing about CIRAM A10. It also says "not replaced" for some values, which I'm confused how it's different from "vertical mirroring"... I guess if bit 4 of $B003 is set, normally CHR10-17 are replaced by the designated banking register, right? So this is an additional CHR override in that case? What gets overridden when bit 4 is not set? Is the incoming signal in that case PPU A10? Does the override also apply to CIRAM A10 instead of CHR A10?
Last edited by rainwarrior on Sat Mar 10, 2018 8:35 pm, 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 »

As far as I know, only Bizhawk, Mesen & puNES pass the VRC6 mirroring test rom that natt made (it's on the wiki).
I don't pretend I even slightly remember what the behavior is (took me ages to wrap my head around it the first time around) - but the current behavior "should" match an actual VRC6 chip.

The label at the bottom of the nametable viewer might be wrong in this case - it only works for games that use the "simpler" mirroring management code (e.g the majority of mappers), but it won't work for mappers that require more customization. (A bit like the MMC5 doesn't display proper banking data at the bottom of the debugger window, either)
lidnariq
Posts: 11430
Joined: Sun Apr 13, 2008 11:12 am

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

Post by lidnariq »

rainwarrior wrote:I'm a little confused, then. Are Nintendulator, Nestopia, FCEUX and the PowerPak getting this behaviour wrong?
Yes.
This mentions replacing CHR A10 but says nothing about CIRAM A10. It also says "not replaced" for some values, which I'm confused how it's different from "vertical mirroring"... I guess if bit 4 of $B003 is set, normally CHR10-17 are replaced by the designated banking register, right? So this is an additional CHR override in that case? What gets overridden when bit 4 is not set? Is the incoming signal in that case PPU A10? Does the override also apply to CIRAM A10 instead of CHR A10?
CIRAM A10 is always connected to CHR A10. I should add that explicitly to the page.

It's confusing, and I'm too familiar with the subject material to figure out how to make it clearer.
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 »

Thanks. I'll fix my ROM, and I'll make an attempt to improve the Wiki now that I understand.

Edit: Ha ha ha, I feel a lot less bad about my bug after looking at the version of the wiki page from when I wrote the ROM. :P Had no idea that whole $B003 register was mostly unknown until 2014!
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 »

Goto in memory viewer has a 4 digit limit. This limit makes it ineffective on PRG-ROM.

Event viewer has a "marked breakpoints" option but the marked breakpoints don't seem to appear unless they are also enabled to break, but if I do that I can only see one at a time (since the event viewer only shows events since last break?)

PPU CHR viewer has option to display on a particular scanline, but if you pause emulation to look at the same scanline I have to go into the debugger and manually advance to that scanline. It's nice to have the ability to see immediate PPU updates like this, of course, but it makes it really hard to e.g. advance frame by frame until the thing you're looking for comes up and inspect what that frame was up to at scanline 100.

Though on that though a "break on scanline" feature might be interesting to have? Would kind of be a substitute for frame advance + see PPU on particular scanline.
Sour
Posts: 890
Joined: Sun Feb 07, 2016 6:16 pm

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

Post by Sour »

Some changes:
-Memory viewer's goto's character limit is now based on the size of the memory type being displayed
-Added a "Refresh on pause/break" option to the ppu viewer & event viewer
-Added a "Break on..." option (that currently only allows you to break on cycle 0 of any scanline, but might add some more stuff in here later on)
-The UNROM-512 mirroring issue you mentioned in the other thread should be fixed (hopefully)

Build: download

About the event viewer, though, I can't reproduce the behavior you're getting. Marked breakpoints appear even if "Break Execution" is not checked, and all events appear, not just the ones since the last code break. Are you getting this for any game, no matter how you open the event viewer, whether or not the debugger window is opened, etc?
lidnariq
Posts: 11430
Joined: Sun Apr 13, 2008 11:12 am

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

Post by lidnariq »

At this precise moment, the build is broken for me:

Code: Select all

Debugger/frmDbgShortcutGetKey.cs(22,33): error CS1043: Invalid accessor body `=>', expecting `;' or `{'
Debugger/frmDbgShortcutGetKey.cs(22,55): error CS1043: Invalid accessor body `=>', expecting `;' or `{'
	Task "Csc" execution -- FAILED
	Done building target "CoreCompile" in project "$HOME/src/Mesen/GUI.NET/GUI.NET.csproj".-- FAILED
Done building project "$HOME/src/Mesen/GUI.NET/GUI.NET.csproj".-- FAILED

Build FAILED.
Errors:

$HOME/src/Mesen/GUI.NET/GUI.NET.csproj (default targets) ->
/usr/lib/mono/xbuild/14.0/bin/Microsoft.CSharp.targets (CoreCompile target) ->

	Debugger/frmDbgShortcutGetKey.cs(22,33): error CS1043: Invalid accessor body `=>', expecting `;' or `{'
	Debugger/frmDbgShortcutGetKey.cs(22,55): error CS1043: Invalid accessor body `=>', expecting `;' or `{'

	 0 Warning(s)
	 2 Error(s)

Time Elapsed 00:00:01.2859550
make: *** [makefile:75: ui] Error 1
[/size]

this is after having "make clean"
Sour
Posts: 890
Joined: Sun Feb 07, 2016 6:16 pm

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

Post by Sour »

Should be fixed - my fault for trying to save a few keystrokes by using recent C# features :p
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 new build fixes the erroneous writes to the last CHR page.

Now that this is working, though, it has exposed another problem, but only in one of the 2 ROMs. Both ROMs have the battery flag set, and the log window output for both of them is the same.

However, one of them ends up treating a write to $8000 (the blinking lights) as a write to the banking register and corrupting ROMs. (Otherwise doesn't usually crash, because the code until the next real bank register write is all in the fixed bank.) I'm not sure how this is possible given the source code for that mapper, though, yet I can clearly watch it happen in the debugger and visually as the wrong CHR table is displayed. Unless HasBattery can be cleared aftrer the log in some way? (Yet it's working for the other one...?)
xmas2012_bad_bank.png
And to demonstrate what I mean about the event viewer, here I have marked breakpoints in magenta and you can clearly see where I have breaked (compare to image above for the two set breakpoints, all i've done below is clicked the one checkbox indicated):
xmas2012_missing_events.png
I can turn on mapper register writes and see the other write (to $C000-FFFF, which has a breakpoint set to show in the viewer, but is not breaking). When I hit the breakpoint here for $8000, I can see the event for the breakpoint I have just hit, but the others never show. If I turn the breakpoints on but leave them set to show, they never appear at all. They only appear when I actually break execution on them, and even when I do that I will only ever see the one I just broke on.
Sour
Posts: 890
Joined: Sun Feb 07, 2016 6:16 pm

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

Post by Sour »

Thanks for the screenshots - the breakpoint events were getting overridden by the "mapper register write" (because they both happened at the same scanline+cycle) - fixed it so the UI keeps track of all events that occur on a given scanline+cycle, so the breakpoint events should display properly now.

And based on the log you posted in the other thread, the most likely problem is that HasBattery() ends up being false (for both games?) because the save ram's size is set to 0 bytes in the NES 2.0 header. This was to avoid loading/writing .sav files when there is no actual save data - I've changed this so that HasBattery() is still true, but the .sav files won't be created if the size is set to 0 bytes. Hopefully both roms work properly with this.

Build: download
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 »

Yep, both ROMs work correctly with this one. Thanks!

2012 is now fine. 2014 had been working with the previous version too, but it's possible that it had the same problem in an innocuous way that I wasn't noticing.

The breakpoint events now work as expected too.
Sour
Posts: 890
Joined: Sun Feb 07, 2016 6:16 pm

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

Post by Sour »

Following a discussion I had with Bananmos and after what felt like an eternity's worth of coding and refactoring, I've finally added source-level debugging support for CC65/CA65 projects.

This adds a "Source View" that allows you to debug using the original source code (and step through it) and also offers a number of advantages over the regular disassembly view (e.g local variables, being able to see code that is not currently mapped to CPU memory, etc.). It works for assembly & C projects, but the C support still needs a bit more polish.

Example:
sourceleveldebugging.png
In the screenshot, you can see that the preview tooltip is able to display code that is not currently available to the CPU (the code for "RenderLevelScreens").

And here's what it looks like with a project coded in C:
cproject.png
There's also a new option to display the original source files as comments in the disassembly view:
showascomments.png
Feedback/bug reports on this feature would be very welcome, if you have CA65/CC65 projects to test it on (I only have a handful of projects that I currently test with).

Build: download

To turn the feature on, you need to generate the .dbg when compiling and load then load it in Mesen's debugger (or turn on the auto-load .dbg file option). Once a .dbg file is loaded, you can right-click on the code window and select "Switch to Source View" (Ctrl+Q by default) to turn on source level debugging.

Also, when in "Source View" mode, all labels/comments defined in the debugger are ignored. The source view's labels, etc. are taken straight from the .dbg file and cannot be altered (this was needed for a number of reasons).
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 »

Very cool! I don't think I can use this feature, though... My linking configuration generates multiple output files, that I combine externally after assembling, so I imagine it will be impossible for the emulator to know where each line of code ended up in the final ROM.

I tried it anyway, and while I can see all my source files, the emulator isn't able to follow the program's execution (i.e. it doesn't highlight the current instruction, breakpoints don't work, etc.), and the "show source as comments" option doesn't do anything either, which's expected.

The reason I build my ROMs like this is because I want to dynamically align code/data of different sizes to the end of each PRG-ROM bank, so I need to assemble the end of the bank before the beginning in order to get its size and pad the beginning appropriately, which means I have to combine all the parts in the correct order after assembling everything.
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 »

Maybe some intermediate file could be used to assign a set of .dbg files each to a specific region of the ROM?
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 »

Well, in my case I still have a single .dbg file, since I still assemble everything at once, it's just that my linking configuration file specifies different output files for different memory sections.
Post Reply