It is currently Sun Sep 23, 2018 7:01 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 153 posts ]  Go to page Previous  1 ... 4, 5, 6, 7, 8, 9, 10, 11  Next
Author Message
PostPosted: Sat Mar 10, 2018 3:59 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 6818
Location: Canada
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.

Top
 Profile  
 
PostPosted: Sat Mar 10, 2018 4:05 pm 
Offline

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


Top
 Profile  
 
PostPosted: Sat Mar 10, 2018 4:11 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7541
Location: Seattle
rainwarrior wrote:
I'm a little confused, then. Are Nintendulator, Nestopia, FCEUX and the PowerPak getting this behaviour wrong?
Yes.

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


Top
 Profile  
 
PostPosted: Sat Mar 10, 2018 4:46 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 6818
Location: Canada
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!


Top
 Profile  
 
PostPosted: Thu Mar 15, 2018 12:00 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 6818
Location: Canada
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.


Top
 Profile  
 
PostPosted: Thu Mar 15, 2018 5:34 pm 
Offline

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


Top
 Profile  
 
PostPosted: Thu Mar 15, 2018 6:27 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7541
Location: Seattle
At this precise moment, the build is broken for me:
Code:
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


this is after having "make clean"


Top
 Profile  
 
PostPosted: Thu Mar 15, 2018 6:38 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 516
Should be fixed - my fault for trying to save a few keystrokes by using recent C# features :p


Top
 Profile  
 
PostPosted: Thu Mar 15, 2018 7:24 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 6818
Location: Canada
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...?)

Attachment:
xmas2012_bad_bank.png
xmas2012_bad_bank.png [ 93.34 KiB | Viewed 2044 times ]


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):

Attachment:
xmas2012_missing_events.png
xmas2012_missing_events.png [ 108.24 KiB | Viewed 2044 times ]


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.


Top
 Profile  
 
PostPosted: Thu Mar 15, 2018 9:11 pm 
Offline

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


Top
 Profile  
 
PostPosted: Thu Mar 15, 2018 9:16 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 6818
Location: Canada
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.


Top
 Profile  
 
PostPosted: Sun Mar 18, 2018 5:17 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 516
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:
Attachment:
sourceleveldebugging.png
sourceleveldebugging.png [ 62.45 KiB | Viewed 1938 times ]
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:
Attachment:
cproject.png
cproject.png [ 21.02 KiB | Viewed 1934 times ]


There's also a new option to display the original source files as comments in the disassembly view:
Attachment:
showascomments.png
showascomments.png [ 30.07 KiB | Viewed 1938 times ]

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).


Top
 Profile  
 
PostPosted: Sun Mar 18, 2018 9:26 pm 
Offline
User avatar

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


Top
 Profile  
 
PostPosted: Sun Mar 18, 2018 9:36 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 6818
Location: Canada
Maybe some intermediate file could be used to assign a set of .dbg files each to a specific region of the ROM?


Top
 Profile  
 
PostPosted: Sun Mar 18, 2018 9:42 pm 
Offline
User avatar

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


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 3 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:  
cron
Powered by phpBB® Forum Software © phpBB Group