It is currently Sun Dec 16, 2018 8:03 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 153 posts ]  Go to page Previous  1 ... 6, 7, 8, 9, 10, 11  Next
Author Message
PostPosted: Sat Apr 14, 2018 8:22 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 531
bleubleu wrote:
The one thing I would tweak is that I would highlight tiles/att changes regardless of whether the data has actually changed or not
Yea, I figured this was less than ideal. The current implementation is strictly a UI-side feature and it would actually require a lot more changes to be able to properly highlight all writes (as there is currently no tracking of PPU read/writes in the debugger). I'll add it to my list as a future improvement idea, but it might be a while before I can get to it.

gauauu wrote:
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.
I've added an option for this in the emulation options: "Randomize power-on state for mappers".
It only has an impact on some mappers - specifically, those you mentioned + most of the mappers covered by tepples' holy diver tests (since I figured those were also most likely good candidates for homebrew). It will randomize startup banks, and also other things like prg/chr banking modes or mirroring (when possible). It's far from perfect, but it should at least help just a little bit when trying to check for initialization bugs.


Top
 Profile  
 
PostPosted: Wed Aug 08, 2018 7:39 pm 
Offline

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

I've been enjoying 0.9.6 so far. Such a good tool for development.

One tiny feature that I keep wanting to have would be to be able to jump to the memory viewer by right clicking on a Label in the debugger. I use debug info, so pretty much every symbol is there and often I am "what does this thing contain again?".

The ultimate would be to have 2 options (if applicable):
- Show in CPU memory
- Show in ROM/RAM memory (useful when a bank isn't currently mapped).

See attached image for a terrible ms-paint mockup.

-Mat


Attachments:
Mockup.jpg
Mockup.jpg [ 96.36 KiB | Viewed 3751 times ]
Top
 Profile  
 
PostPosted: Wed Aug 08, 2018 7:54 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20883
Location: NE Indiana, USA (NTSC)
Do we want to count the ROM addresses relative to the start of PRG ROM (e.g. $000000-$01FFFF) or of the iNES image (e.g. $000010-$02000F)?


Top
 Profile  
 
PostPosted: Thu Aug 09, 2018 1:57 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 531
bleubleu wrote:
The ultimate would be to have 2 options (if applicable):
- Show in CPU memory
- Show in ROM/RAM memory (useful when a bank isn't currently mapped)
If I remember correctly, rainwarrior also requested something similar to this a while ago (although I think his case was to navigate from one memory type to the other within the hex editor, I'd have to find the post). These kinds of actions would probably be useful in a number of other places, too (e.g right-click in the code window, hex editor, etc.) It shouldn't be too hard to add these (not just in the label list, but in general), I'll try to get around to it soon.

tepples wrote:
Do we want to count the ROM addresses relative to the start of PRG ROM (e.g. $000000-$01FFFF) or of the iNES image (e.g. $000010-$02000F)?
Mesen currently has "PRG ROM" and "CHR ROM" addressing types for breakpoints/labels that count bytes based on the start of a particular memory type, rather than the offset in the .nes file.


Top
 Profile  
 
PostPosted: Thu Aug 09, 2018 5:04 pm 
Offline

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

Let me know if you need testing.

-Mat


Top
 Profile  
 
PostPosted: Fri Aug 24, 2018 5:59 pm 
Offline

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

Im getting a crash when setting a condition breakpoint. I simply set the expression to "a > 20" and i get this crash:

Code:
Unhandled Exception: System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
   at Mesen.GUI.InteropEmu.Run()
   at Mesen.GUI.Forms.frmMain.<StartEmuThread>b__206_0()
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
   at System.Threading.ThreadHelper.ThreadStart()
[Finished in 44.3s]


Not sure if it will crash in any game or just mine.

-Mat


Top
 Profile  
 
PostPosted: Fri Aug 24, 2018 6:22 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 531
bleubleu wrote:
Not sure if it will crash in any game or just mine.
I can't seem to make it crash on my end, could you show me a screenshot of the breakpoint's edit window? Does it crash as soon as you enter the condition and click ok?
Could you try using a similar/identical breakpoint on another game to see if you get similar results?


Top
 Profile  
 
PostPosted: Sun Aug 26, 2018 5:44 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 531
bleubleu wrote:
The ultimate would be to have 2 options (if applicable):
- Show in CPU memory
- Show in ROM/RAM memory (useful when a bank isn't currently mapped).
I just added these to the label list's context menu (you can also assign shortcut keys for these).

Also, I've added "View in cpu memory", "View in [prg rom/work ram/save ram]", "View in disassembly" shortcuts in the hex editor (these can also be assigned shortcuts). "View in disassembly" is currently only available if the debugger window is already opened.

This should hopefully help navigation between windows a bit - let me know if you find any issues with it (or if you have other similar scenarios that would benefit from these kinds of shortcuts). The latest AppVeyor build contain the changes.


Top
 Profile  
 
PostPosted: Wed Aug 29, 2018 10:31 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7022
Location: Canada
If I open a ROM that crashes on startup, Mesen will kick me back out to the game select menu before I can open a debugger to try and see what happened. While in this menu I can't open a debugger either because it's greyed out in the menu. Maybe if the "developer mode" option is selected could this just open the debugger instead of exiting the game?


Top
 Profile  
 
PostPosted: Thu Aug 30, 2018 6:22 am 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 531
There's an option for this already (although it might not be as obvious as it should be) - if you turn on "Break on CPU crash" in the debugger (Options->Break options), it should open the debugger whenever a game is about to crash instead of unloading the game.


Top
 Profile  
 
PostPosted: Thu Aug 30, 2018 7:05 am 
Offline

Joined: Wed Apr 04, 2018 7:29 pm
Posts: 39
Location: Montreal, Canada
Sour wrote:
bleubleu wrote:
The ultimate would be to have 2 options (if applicable):
- Show in CPU memory
- Show in ROM/RAM memory (useful when a bank isn't currently mapped).
I just added these to the label list's context menu (you can also assign shortcut keys for these).

Also, I've added "View in cpu memory", "View in [prg rom/work ram/save ram]", "View in disassembly" shortcuts in the hex editor (these can also be assigned shortcuts). "View in disassembly" is currently only available if the debugger window is already opened.

This should hopefully help navigation between windows a bit - let me know if you find any issues with it (or if you have other similar scenarios that would benefit from these kinds of shortcuts). The latest AppVeyor build contain the changes.


Thanks man! I will try that soon. As for the crash I am not getting it right now. Next time i have it ill save the ROM, line number and condition i used.

-Mat


Top
 Profile  
 
PostPosted: Thu Aug 30, 2018 11:35 am 
Offline
User avatar

Joined: Sun Apr 08, 2018 11:45 pm
Posts: 29
Location: Southern California
rainwarrior wrote:
If I open a ROM that crashes on startup, Mesen will kick me back out to the game select menu before I can open a debugger to try and see what happened. While in this menu I can't open a debugger either because it's greyed out in the menu. Maybe if the "developer mode" option is selected could this just open the debugger instead of exiting the game?


Yeah, I'd like to request the same thing! I run in to this a lot when doing large scale refactors or setting up little test projects.


Top
 Profile  
 
PostPosted: Thu Aug 30, 2018 1:23 pm 
Offline

Joined: Wed Apr 04, 2018 7:29 pm
Posts: 39
Location: Montreal, Canada
samophlange wrote:
Yeah, I'd like to request the same thing! I run in to this a lot when doing large scale refactors or setting up little test projects.


I think Sour answered this.

Quote:
There's an option for this already (although it might not be as obvious as it should be) - if you turn on "Break on CPU crash" in the debugger (Options->Break options), it should open the debugger whenever a game is about to crash instead of unloading the game.


-Mat


Top
 Profile  
 
PostPosted: Thu Aug 30, 2018 4:35 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7022
Location: Canada
Another case where data before code garbles the opcodes in the debugger. In this instance, the code and data table are in RAM. Put an execute breakpoint on "reg_write" ($031B) to see the problem. (source, this one's easier to build than that other thing I was working on)

Turning off the option to "disassemble unidentified code" sort of helps, but only if i've executed this function before (otherwise it will appear line by line as I execute it... though this is why I normally want this option on all the time, I am often looking around for new code, branches untaken, etc.)

Is there a CDL for RAM? The code seems to be highlighted and identified for disassembly, but right clicking the "mark selection as..." option is greyed out. (Also notice that the memory view seems to let you manually mark CDL this way too, but not in CPU view, only in PRG ROM view, which is maybe not easy to jump between, esp. since CPU view seems to be the one that "edit in memory view" takes you to from the disassembly view.)


Also, not related to this, but I believe the 5B frequencies are off by 1?


Attachments:
db_vrc7_dbg.zip [7.04 KiB]
Downloaded 115 times
Top
 Profile  
 
PostPosted: Thu Aug 30, 2018 5:40 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 531
I changed a couple of things with the RAM's disassembly logic:
-The disassembly for RAM (all types) should properly realign itself whenever verified code is found
-The disassembler will keep disassembling instructions in RAM until an inconditional jump instruction is found (e.g rts, rti, jmp), like it already does for PRG ROM/Work RAM/Save RAM.

The first one should fix your issue, and the second makes the disassembly view a bit more useful when the "disassemble unknown code/data " option is not enabled.

There is no CDL for RAM - but the disassembler does keep a cache of known instructions that have been executed in RAM and uses that to disassemble (this can't be manipulated by the user, though). The cache is invalidated as the contents of memory changes. It's normal for the CPU memory view to not let you use the "mark selection as.." actions on RAM, it should only be enabled on PRG ROM.

rainwarrior wrote:
Also, not related to this, but I believe the 5B frequencies are off by 1?
Are you asking because you noticed the difference by listening to it, or because you checked the code?
There is in fact a very suspicious looking +1 here: https://github.com/SourMesen/Mesen/blob ... udio.h#L58
Not sure why it's there, but that would probably be the cause?


samophlange wrote:
Yeah, I'd like to request the same thing! I run in to this a lot when doing large scale refactors or setting up little test projects.
The "Break on CPU crash" option I mentioned should work - let me know if it doesn't though.


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: nesrocks and 1 guest


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