It is currently Mon Jun 18, 2018 7:45 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 121 posts ]  Go to page Previous  1 ... 5, 6, 7, 8, 9  Next
Author Message
PostPosted: Sun Mar 18, 2018 9:49 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 6342
Location: Canada
Oh, well in that case I suppose what is needed is a list of MEMORY block to ROM location overrides?

In some of my projects I've split things into separate link steps, which is what I'd assumed you were doing. That would require a multiple .dbg mapping.

To handle both styles, it could be a list of entries with 3 pieces of information?
  • 1. .dgb file
  • 2. MEMORY block
  • 3. ROM location override (presumably just the start address?)

I dunno if we're getting into territory where there might be a zillion ways to organize things though.

I suppose as an alternative workaround, though you could process the .dbg file to inject the final ROM addresses back into it. (Or in my case, I could synthesize a .dbg file of my own from the separate ones.) From FCEUX I was already used to having my own script to build the .NL debug files anyway.


Top
 Profile  
 
PostPosted: Sun Mar 18, 2018 10:33 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10513
Location: Rio de Janeiro - Brazil
rainwarrior wrote:
I suppose as an alternative workaround, though you could process the .dbg file to inject the final ROM addresses back into it. (Or in my case, I could synthesize a .dbg file of my own from the separate ones.) From FCEUX I was already used to having my own script to build the .NL debug files anyway.

I made scripts like this before, but the common kind of symbolic debugging in FCEUX and Mesen never worked well for me, since I reuse RAM a lot in different parts of my programs, from function parameters and local variables to modules that don't run concurrently, so there was no way I could give a single name to each memory position and have the symbolic disassembly make sense.

What I'm doing now is generating my own symbol file using macros (for labels/variables that are created through macros), so I get to choose which symbols end up in the file and which don't. Everything that uses shared memory normally doesn't go to my custom symbol file, but when I'm debugging a specific module or function, I enable the output of their respective symbols, and there are no conflicts.

Source-level debugging should pretty much solve that problem though, so I'll see if patching the .dbg file isn't too much trouble.


Top
 Profile  
 
PostPosted: Mon Mar 19, 2018 4:31 am 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 415
It's possible that your .dbg file contains the information required to make it work properly already.
The .dbg files does list the file offsets based on the output filename (so I assume it's meant to support multiple files), but all the projects I have at the moment only have a single output. If you can PM me the .dbg file you get, I might be able to figure out a way to make it work?


Top
 Profile  
 
PostPosted: Tue Mar 20, 2018 9:33 pm 
Offline
User avatar

Joined: Sat Jan 09, 2016 9:21 pm
Posts: 399
Location: Central Illinois, USA
Another feature request that probably already exists (as most of mine do!):

I love that there's a way to ask it to randomize ram at startup. Is there a way to make it start in a random bank/banks? (which I realize is slightly complicated because it has to work for each banking scheme). It would be nice to be able to properly test to make sure my stubs to jump into the first bank are all working right.

Thanks!

_________________
My games: http://www.bitethechili.com


Top
 Profile  
 
PostPosted: Wed Mar 21, 2018 3:19 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 415
This isn't a feature at the moment, but something I have been considering for a while. The problem is that I see no simple way to making it work for all ~250 boards Mesen supports without having to check all of them, validate what their know bootup state is and then alter their code as needed.

At the moment, on mappers with banks smaller than 32kb, Mesen does try to leave the banks as open bus (except the fixed banks), which forces you to initialize the mapper properly (and prevents it from working when it shouldn't) - but sometimes implementation details make it so it's easier to just select bank 0 everywhere (e.g MMC3 does this, among others)

Either way, it should be relatively easy to implement randomized banking for common commercial/homebrew mappers, though, since that would restrict the list to about 10-15 mappers or so? I'm not sure which mappers would be the most important to target (beyond the obvious ones like MMC/VRC mappers, etc.) - so if anyone has a list/suggestions to make, that would be helpful (esp. when it comes to popular homebrew mappers).


Top
 Profile  
 
PostPosted: Wed Mar 21, 2018 6:58 pm 
Online

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7211
Location: Seattle
I'd think open-bus would be the useful default, instead of random banks ...

Maybe only the common ones that use 32K banking would be random banks?


Top
 Profile  
 
PostPosted: Wed Mar 21, 2018 8:10 pm 
Offline
User avatar

Joined: Sat Jan 09, 2016 9:21 pm
Posts: 399
Location: Central Illinois, USA
lidnariq wrote:

Maybe only the common ones that use 32K banking would be random banks?


BNROM and GTROM were the two that I had in mind, both with 32k banks. (Both of which I recently ran into bugs when testing in hardware because of errors in my startup bank switching that I never saw on emulators)

_________________
My games: http://www.bitethechili.com


Top
 Profile  
 
PostPosted: Thu Mar 29, 2018 12:20 pm 
Offline

Joined: Sun Mar 25, 2018 10:30 pm
Posts: 1
Please disregard my reply if the requested feature is already available.

What I want is integration into Visual Studio 2017 (or JetBrain's IDE product) as an extension so that we can simply load a ROM (.nes file) by clicking a menu item or toolbar button and start debugging, just as we normally do with C/C++ code inside VS. Because Visual Studio or JetBrain's IDE product has already provided a rich set of debugging tools like setting (conditional) breakpoints, stepping over and into, watch (and change) variables, viewing memory and CPU contents, etc., it makes more sense to take advantage of this existing IDE instead of creating a separate new one having the same function (or quite possibly less functions with more bugs), and of the expertise most of us already have working inside of it.


Top
 Profile  
 
PostPosted: Thu Mar 29, 2018 1:19 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 415
While connecting an existing IDE with Mesen's debugger via a protocol like gdb might be feasible (like it was discussed earlier in the thread), implementing the entire emulator as a Visual Studio (or other IDE) plugin that would allow you to load NES files right into the IDE would be a gigantic task (and essentially akin to rewriting the entire project).

The end result would be that people now need to download and install a specific IDE (e.g VS, which is several GBs in size) to use the debugger. And while VS is widely used, not everybody uses it, and people may not be able to use it at all (e.g Linux users) - the same could be said of any other specific IDE. So while I can see some of the appeal of being able to use an existing IDE for this, I don't think I agree that it would be a better solution, overall.

Either way, though, this is definitely not something that I will be doing - it would probably take several hundred hours of my time to complete this kind of project (if not more).


Top
 Profile  
 
PostPosted: Sun Apr 08, 2018 4:42 pm 
Offline

Joined: Wed Apr 04, 2018 7:29 pm
Posts: 17
Location: Montreal, Canada
Hi.

Im new to nesdev so apologies if I havent read the whole thread. Here are a few ideas I came up with from using Mesen for about a month (its awesome btw).

  • It would be nice if CTRL+R worked when the focus in on the debugger. I often set the game in a specific state to debug something and resetting quickly is nice.
  • A little debugger watch syntax that could be added to visualize arrays starting at a specific address would be useful. Not having to bring up the memory viewer for some small stuff is nice. Visual Studio has a couple versions of this. If I write "ptr,10" it will show me the 10 first element of the array starting at ptr. Of course VS knows the type, Mesen doesnt. Having a way to see arrays of byte or word would be great. Another syntax VS has is "ptr,mb" (in this case mb means memory byte). It will show me the first few bytes starting at this address. (https://docs.microsoft.com/en-us/visualstudio/debugger/format-specifiers-in-cpp)
  • Being able to view the tiles and attributes that were recently updated in the PPU debugger would be cool. I had to implement 4-way scrolling, which was super annoying, so I ended up writing myself a little C# app on the side to see what was going on. Here is a screenshot if you need inspiration, red shows tiles updated recently, yellow are attributes.

That's all I got for now.

Keep up the good work.

-Mat


Attachments:
Scroll.png
Scroll.png [ 19.27 KiB | Viewed 826 times ]
Top
 Profile  
 
PostPosted: Mon Apr 09, 2018 11:58 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 6342
Location: Canada
Wanting to investigate nametables or CHR across scanline splits, I tried opening multiple PPU debug windows and give them each a different scanline display option. Unfortunately, this option does not seem to be per-window, but rather a global thing where only the last value takes effect. (Also displaying the wrong value for one of the windows, since changing one does not update the other... but ideally it wouldn't be global anyway.)

Probably not a trivial thing to implement, but since this emulator has the (unique?) feature of duplicate PPU debug windows, seems a shame it's not available.


Top
 Profile  
 
PostPosted: Mon Apr 09, 2018 4:49 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 415
I gave the tile/attribute highlighting a shot with the data I had available in the UI already:
Attachment:
highlight.png
highlight.png [ 23.25 KiB | Viewed 766 times ]
As is, it only highlights PPU writes that actually change the data (so if the game writes the same value twice, it won't highlight). The highlights only stay on the screen for a single frame, so usually have to play the game in slow motion to see them for a decent amount of time. I could fade them out over time (with a lot more logic), but then that would make it harder to discern on which specific frame an update occurs. Is this sufficiently useful as is? If so, I just need to add a checkbox to toggle the highlight on/off and I'm done :p

-Reset: I'll add customizable reset/power cycle shortcuts to the debugger window
-Array/etc syntax in the watch: I can see the use here, but making it work with the rest of the code that's currently used for watch expressions involves a lot of changes - can't promise anything on this one, but I'll add it to my list of future improvement ideas.

rainwarrior wrote:
Probably not a trivial thing to implement, but since this emulator has the (unique?) feature of duplicate PPU debug windows, seems a shame it's not available.
The multiple PPU windows were originally just a way to allow someone to look at multiple tabs at once (instead of splitting the tools across multiple separate windows), but I never really considered the interaction with the scanline/cycle fields. Making the scanline/cycle fields a per-window option wouldn't be hard, I'm mostly worried about the performance impact of having to check through an "array" of scanline/cycle combinations on every PPU cycle vs comparing with a single fixed value. It might not have that much of an impact though, I'll check.


Top
 Profile  
 
PostPosted: Mon Apr 09, 2018 6:15 pm 
Offline

Joined: Wed Apr 04, 2018 7:29 pm
Posts: 17
Location: Montreal, Canada
Wow thanks!

I'll give it a shot. Coffee donation incoming!

-Mat


Top
 Profile  
 
PostPosted: Mon Apr 09, 2018 9:03 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 415
Here's a (Windows-only) build with the changes: download

It adds:
-2 options to the nametable viewer to toggle the highlight of tile/attribute data changes
-Reset/Power Cycle shortcuts to the main debugger window (customizable - but you will have to customize these independently from the shortcuts in Options->Preferences)
-The ability to have multiple PPU viewer windows opened & set to update at different scanlines/cycles - it should run about as fast as before, or maybe a tiny little bit faster.

And thanks for the donation!


Top
 Profile  
 
PostPosted: Fri Apr 13, 2018 4:20 pm 
Offline

Joined: Wed Apr 04, 2018 7:29 pm
Posts: 17
Location: Montreal, Canada
Hi!

I just got around to test the new feature. Its great! The one thing I would tweak is that I would highlight tiles/att changes regardless of whether the data has actually changed or not. When debugging scrolling (for example) you will often rewrite the same data (imagine a blue sky in mario), but you still want to know you did it correctly. The PPU is kind of a write-only thing for most developers.

-Mat


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: Google [Bot] and 4 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