Mesen - Debugger Feedback?

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

tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Mesen - Debugger Feedback?

Post by tepples »

furrykef in #nesdev ran them through Google Translate, got "démarrage à froid" (cold boot) and "démarrage à chaud" (warm boot), and then confirmed their usage in Google Search and in a French Wikipedia article.
Sour
Posts: 890
Joined: Sun Feb 07, 2016 6:16 pm

Re: Mesen - Debugger Feedback?

Post by Sour »

@dullahan
I've fixed the path finding issue - the code will now go up the path looking for the files until it reaches the drive's root folder.

As for transforming the labels, I guess the simplest way would be to allow the user to setup regular expressions to parse & replace portions of the text?
It's not the most user friendly method, but it is a debugger and all..


@Myask & @tepples
I probably should have mentioned this earlier, but I'm a French native.
To be honest, while "Démarrage à froid" and "Démarrage à chaud" are probably the correct terms technically speaking, I don't believe I've ever heard anybody using them in my life. (To be fair, I am from Quebec - people from France and the like may very well use these).
For the moment, I've settled on "Arrêt & redémarrage" (litt. Stop & restart), which I feel conveys the meaning, and should be understandable for anybody, whether or not they know the technical term for it.

I also ended up using the same logic for Japanese - 停止と再起動 - which is also just "stop and restart".
User avatar
thefox
Posts: 3134
Joined: Mon Jan 03, 2005 10:36 am
Location: 🇫🇮
Contact:

Re: Mesen - Debugger Feedback?

Post by thefox »

Sour wrote:@thefox
Thanks for testing!

That amount of errors is pretty impressive! If you had labels in the debugger, then my guess is that it was unable to load the source files.
This would probably be due to the path in the "name" tag for the "file" directives.
Currently the regex I'm using only allows the following characters in paths:
0-9, a-z, A-Z ( ) _ . - : / \
Any chance the paths you have in your DBG file (should be at the very top) contain something outside of these?
Nope, the paths are very normal. Also, I think it was able to load some of the source files at least (can't bother to test again now, but I think I saw some of my source code).
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi
Sour
Posts: 890
Joined: Sun Feb 07, 2016 6:16 pm

Re: Mesen - Debugger Feedback?

Post by Sour »

thefox wrote:Nope, the paths are very normal. Also, I think it was able to load some of the source files at least (can't bother to test again now, but I think I saw some of my source code).
Alright, thanks. Either way, I've changed the import's code slightly in the release I just did (0.6.0) which might fix this (no promises though).

There are still some suggestions that were given in this thread that haven't been added to 0.6.0, I have them written down and will get to them eventually.
I've been working on the debugger for dozens of hours over the past few weeks and need to take a break from it!

Thanks again for all the feedback, and if anyone has any other suggestions, don't hesitate to post them!
Sour
Posts: 890
Joined: Sun Feb 07, 2016 6:16 pm

Re: Mesen - Debugger Feedback?

Post by Sour »

I just spent most of the day on this and am mostly finished rewriting the memory viewer tool in Mesen.
Preview build: download
Note: This build is Windows-only, because making a Linux+Windows package takes a lot more time - Linux users can compile from the latest source code on GitHub, it includes all the changes. (note: I did not test Linux at all yet)

The memory viewer is now a proper hex editor - everything can be edited:
-NES built-in 2k RAM
-PRG ROM, Work RAM, Save RAM
-CHR ROM & RAM
-Palette RAM
-Primary/secondary OAM
-Nametable memory (via the PPU Memory dropdown option)
Note: Attempting to write to addresses mapped to registers or not mapped at all has no effect.

It's now also possible to display a text representation of the binary data.
It supports TBL files, and defaults to ASCII conversion when no TBL file is loaded.
The TBL mappings are saved in the debugger's workspace (independent for each rom debugged)

Example with AllPads rom (which contains ascii encoded text):
hexedit1.png
Example with FF3 (J) with a TBL file loaded to convert to kana:
hexedit2.png
It's possible to search for hex values, or text.
When searching for text, the TBL values are used to produce the corresponding binary data, so you can search for a Japanese string and find it in FF3's text.

The text column supports variable-width characters (and multiple characters per byte) and highlights the right text based on the hex selection:
hexedit3.png
This is one of the main features that was still lacking from Mesen's debugger at this point.
Anyone have any feedback and/or suggestions to improve it?
And please let me know if you get any crashes or find any bugs, too.

PS: Main things left on my todo list at this point:
-A simple visual CHR editor
-Ability to save edited PRG/CHR ROM back to a .nes file
-"Jump list" (i.e like the callstack tool but for all jumps, useful to trace back the execution)
-Scripting
-Add some way to compile/run assembly code, or edit the existing code
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Mesen - Debugger Feedback?

Post by tepples »

Sour wrote:-A simple visual CHR editor
-Ability to save edited PRG/CHR ROM back to a .nes file
This would be killer, particularly if you were to make an oldskool UI reminiscent of Genecyst.
Oziphantom
Posts: 1565
Joined: Tue Feb 07, 2017 2:03 am

Re: Mesen - Debugger Feedback?

Post by Oziphantom »

I see this continues the gui spaghetti debugger trend ;)

The Debugger code view seems to get confused easily
debug1.png
here the unknown block is

Code: Select all

                        CPX #$50
                        BNE bC60B
                        RTS 

pltXYtoPPU              STX a00
                        STY a01
                        JMP plt_p00_toPPU

clearNMIFlags           LDA #$00
                        STA NMIDoneFlag
                        STA NMIDoVRAMUpdates
Then latter you get to
debug2.png
Which is really

Code: Select all

                        BNE bF82F
bF826                   JSR sF383
                        LDX #$C0
                        LDY #$C0
                        BNE bF836
bF82F                   JSR sF383
                        LDX #$86
                        LDY #$86
bF836                   JSR sF3D0
                        LDA #$00
                        STA aE4
                        JMP jF40F

bF840                   LDY #$09
                        LDA #$EF
                        BNE bF826
fF846                   .BYTE $0A
fF847                   .BYTE $13
fF848                   .BYTE $1C
fF849                   .BYTE $25
fF84A                   .BYTE $2E
fF84B                   .BYTE $37
fF84C                   .BYTE $40
fF84D                   .BYTE $49
fF84E                   .BYTE $52,$5B,$07,$C3,$F8,$E2,$F8,$08
                        .BYTE $F9,$1B,$F9,$07,$2F,$F9,$60,$F9
                        .BYTE $A1,$F9,$CC,$F9,$07,$AF,$FA,$CA
                        .BYTE $FA,$E4,$FA,$F5,$FA,$07,$DA,$F9
The problem with having the auto magical code on the side is, when it gets confused there is nothing you can do. For example when you have inlined data with code ala
debug3.png

Code: Select all

$CCA9: A5 31       sCCA9                   LDA BirdEntFSMIndex
$CCAB: 20 5E C3                            JSR jmpA
$CCAE:                                     .WORD JustRTS,setupDogEnt,setDogAnimWalk,dogUpdWalk,setDogAnimSniff
$CCB8:                                     .WORD updHoldFrame,setDogAnimShock,updHoldFrame,setDogAnimStartJump,dogUpdJump
$CCC2:                                     .WORD dogSetupLaugh,updHoldFrame,dogSetupShowDucks,updHoldFrame,setupForNextDuck
$CCCC:                                     .WORD aCE18,aCE2E,updHoldFrame,aCE40
$CCD4: A2 1F       setupDogEnt             LDX #$1F
$CCD6: BD 6E E7    bCCD6                   LDA fE76E,X
$CCD9: 95 30                               STA f30,X
$CCDB: CA                                  DEX 
$CCDC: 10 F8                               BPL bCCD6
$CCDE: A9 03                               LDA #$03
$CCE0: 85 BA                               STA NumShotsLeft
$CCE2: A9 01                               LDA #$01
$CCE4: 85 BE                               STA RedrawBulletsFlag
$CCE6: 85 AD                               STA NeedUpdDuckShotRow
$CCE8: A9 02                               LDA #$02                     ;game palllete
$CCEA: 85 23                               STA NextPallete
$CCEC: A5 25                               LDA a25
$CCEE: C9 07                               CMP #$07
$CCF0: D0 05                               BNE bCCF7
$CCF2: A9 10                               LDA #$10
$CCF4: 85 31                               STA BirdEntFSMIndex
$CCF6: 60                                  RTS 

Having a Monitor mode would really help with these issues and be nice in general(IMHO). That way I can D CCD4 and see the code I want. or doing the debug display in a live window so I can move up and down a few bytes and it disassembles from the address at the top of the screen.
If you have a monitor that lets you specify labels, breakpoints, watches then you can put a custom file on the the command line params, which then lets you open Mesen, add a bunch of labels, breakpoints etc from an external tool.
Having an option to open the debugger on BRK would be nice also, so I can add a BRK into code and then have the debugger fire on it from my code editor. Also assemblers will pad unused areas with 00, so if the code hits lala land it will stop.
CPU history command is the nectar of the gods. What it does is, it keeps a trace of the last N instructions the CPU performs, so if you code goes bad and you end up in lala land, you can type CHIS and it will show you exactly how it got to lala land - for example this is what it looks like

Code: Select all

** Monitor 177 035
(C:$0c4f) chis
1431  A5 34      LDA $34             :A$16 X$02 Y$00 SP$f2   -
1433  10 01      BPL $1436           :A$02 X$02 Y$00 SP$f2   -
1436  A5 14      LDA $14             :A$02 X$02 Y$00 SP$f2   -
1438  29 08      AND #$08            :A$f7 X$02 Y$00 SP$f2 N -
143a  F0 48      BEQ .mainGameHitDetect_C64VICTriggerSystem__checkRelease :A$00 X$02 Y$00 SP$f2   -   Z
1484  A9 00      LDA #$00            :A$00 X$02 Y$00 SP$f2   -   Z
1486  85 36      STA $36             :A$00 X$02 Y$00 SP$f2   -   Z
1488  85 37      STA $37             :A$00 X$02 Y$00 SP$f2   -   Z
148a  60         RTS                 :A$00 X$02 Y$00 SP$f2   -   Z
091a  20 F1 12   JSR .HUD_updateCurrBird :A$00 X$02 Y$00 SP$f4   -   Z
12f1  24 32      BIT $32             :A$00 X$02 Y$00 SP$f2   -   Z
12f3  10 1C      BPL .HUD_updateCurrBird__exit :A$00 X$02 Y$00 SP$f2 N -   Z
12f5  24 23      BIT $23             :A$00 X$02 Y$00 SP$f2 N -   Z
12f7  10 18      BPL .HUD_updateCurrBird__exit :A$00 X$02 Y$00 SP$f2 N -   Z
12f9  E6 31      INC $31             :A$00 X$02 Y$00 SP$f2 N -   Z
12fb  A0 00      LDY #$00            :A$00 X$02 Y$00 SP$f2   -
12fd  A5 31      LDA $31             :A$00 X$02 Y$00 SP$f2   -   Z
12ff  29 0F      AND #$0F            :A$4b X$02 Y$00 SP$f2   -
1301  D0 0E      BNE .HUD_updateCurrBird__exit :A$0b X$02 Y$00 SP$f2   -
1311  60         RTS                 :A$0b X$02 Y$00 SP$f2   -
091d  20 DF 09   JSR .GFSM_dispatchBirdFunction :A$0b X$02 Y$00 SP$f4   -
09df  A6 24      LDX $24             :A$0b X$02 Y$00 SP$f2   -
09e1  BD F0 09   LDA .BirdFSMLUT_hi,X :A$0b X$01 Y$00 SP$f2   -
09e4  48         PHA                 :A$0a X$01 Y$00 SP$f2   -
09e5  BD EA 09   LDA .BirdFSMLUT_lo,X :A$0a X$01 Y$00 SP$f1   -
09e8  48         PHA                 :A$69 X$01 Y$00 SP$f1   -
09e9  60         RTS                 :A$69 X$01 Y$00 SP$f0   -
0a6a  20 53 0D   JSR .bird_updateBirdAnim :A$69 X$01 Y$00 SP$f2   -
0d53  C6 1B      DEC $1B             :A$69 X$01 Y$00 SP$f0   -
0d55  30 01      BMI $0D58           :A$69 X$01 Y$00 SP$f0   -   Z
0d57  60         RTS                 :A$69 X$01 Y$00 SP$f0   -   Z
0a6d  20 8F 0D   JSR .bird_updateBirdMovement :A$69 X$01 Y$00 SP$f2   -   Z
0d8f  A6 1C      LDX $1C             :A$69 X$01 Y$00 SP$f0   -   Z
0d91  BD AD 33   LDA .BirdYXDeltas,X :A$69 X$09 Y$00 SP$f0   -
0d94  C9 AA      CMP #$AA            :A$ff X$09 Y$00 SP$f0 N -
0d96  D0 07      BNE $0D9F           :A$ff X$09 Y$00 SP$f0   -    C
0d9f  18         CLC                 :A$ff X$09 Y$00 SP$f0   -    C
0da0  65 17      ADC $17             :A$ff X$09 Y$00 SP$f0   -
0da2  85 17      STA $17             :A$97 X$09 Y$00 SP$f0 N -    C
0da4  E8         INX                 :A$97 X$09 Y$00 SP$f0 N -    C
0da5  BD AD 33   LDA .BirdYXDeltas,X :A$97 X$0a Y$00 SP$f0   -    C
0da8  F0 19      BEQ .bird_updateBirdMovement__endAdd :A$01 X$0a Y$00 SP$f0   -    C
0daa  30 0C      BMI .bird_updateBirdMovement__sub :A$01 X$0a Y$00 SP$f0   -    C
0dac  18         CLC                 :A$01 X$0a Y$00 SP$f0   -    C
0dad  65 15      ADC $15             :A$01 X$0a Y$00 SP$f0   -
0daf  85 15      STA $15             :A$50 X$0a Y$00 SP$f0   -
0db1  90 10      BCC .bird_updateBirdMovement__endAdd :A$50 X$0a Y$00 SP$f0   -
0dc3  E8         INX                 :A$50 X$0a Y$00 SP$f0   -
0dc4  86 1C      STX $1C             :A$50 X$0b Y$00 SP$f0   -
0dc6  60         RTS                 :A$50 X$0b Y$00 SP$f0   -
0a70  20 C7 0D   JSR .bird_checkClipEntityXandY :A$50 X$0b Y$00 SP$f2   -
0dc7  A5 15      LDA $15             :A$50 X$0b Y$00 SP$f0   -
0dc9  A6 16      LDX $16             :A$50 X$0b Y$00 SP$f0   -
0dcb  D0 06      BNE $0DD3           :A$50 X$00 Y$00 SP$f0   -   Z
0dcd  C9 18      CMP #$18            :A$50 X$00 Y$00 SP$f0   -   Z
0dcf  F0 23      BEQ .bird_checkClipEntityXandY__offLeftScreen :A$50 X$00 Y$00 SP$f0   -    C
0dd1  D0 04      BNE .bird_checkClipEntityXandY__checkY :A$50 X$00 Y$00 SP$f0   -    C
0dd7  A5 17      LDA $17             :A$50 X$00 Y$00 SP$f0   -    C
0dd9  C9 19      CMP #$19            :A$97 X$00 Y$00 SP$f0 N -    C
0ddb  F0 05      BEQ .bird_checkClipEntityXandY__aboveTopY :A$97 X$00 Y$00 SP$f0   -    C
0ddd  C9 92      CMP #$92            :A$97 X$00 Y$00 SP$f0   -    C
0ddf  F0 07      BEQ .bird_checkClipEntityXandY__belowBottomY :A$97 X$00 Y$00 SP$f0   -    C
0de1  60         RTS                 :A$97 X$00 Y$00 SP$f0   -    C
0a73  20 4F 0C   JSR .bird_setBirdXY :A$97 X$00 Y$00 SP$f2   -    C
(C:$0c4f)
While you have the logger, you have to set it up and it starts to eat RAM and file space and then you have to wade through it all to get what you want, just having a last 64/128 commands on a single command is enough to save the day.

With the hex editor, showing Blue - execute, Green - Read, Red - Write, Yellow Read/Write and being able to turn off decay and then Mark the areas already highlighted. This way you can play game for bit, mark access, do new thing. Immediately see which bit of code was run when you did the thing and which memory locations it accessed to do it. Also handy for finding if code indexes over an array boundary.

Having HardReset/ColdBoot/ColdStart also reloading the ROM file would be worth its weight in gold. I.e see bug, change code, assemble, then ColdStart, where WarmStart just keeps the current code. FYI VICE has the terms RESET > HARD SOFT and its translated into a stupid number of languages so you could look at what they have. I think the way it gets away with it, is it has a parent menu Reset then then opens to options for Hard, Soft, Drive 8, Drive 9, Drive 10, Drive 11 so it doesn't have to translate or show Hard Reset, Soft Reset.

Uppercase opcodes is the CBM standard, mainly because the PET and other computers of the era that followed, TRS-80, Apple ][ only had uppercase character sets so the monitors and assmeblers of the day also did uppercase, once we got to the C64 era where we did have upper and lower case modes, it was such a standard and BASIC was done in all uppercase it just stuck. Although on a PC I type all my code lowercase.
Sour
Posts: 890
Joined: Sun Feb 07, 2016 6:16 pm

Re: Mesen - Debugger Feedback?

Post by Sour »

Oziphantom wrote:The Debugger code view seems to get confused easily
I'm not sure what you mean - the debugger keeps track of what it knows to be code. If it cannot tell with certainty that something is code, it is displayed in an unknown block until it can be certain that it is in fact code (e.g usually after it has been executed at least once). The more code you run, the more accurate it becomes.
Oziphantom wrote:If you have a monitor that lets you specify labels, breakpoints, watches then you can put a custom file on the the command line params, which then lets you open Mesen, add a bunch of labels, breakpoints etc from an external tool.
You can already import labels from CC65 - I'm not sure what you would import breakpoints & watches from?
Having an option to open the debugger on BRK would be nice also, so I can add a BRK into code and then have the debugger fire on it from my code editor.
Adding breakpoints on specific instructions should be easy, I'll see what I can do.
What it does is, it keeps a trace of the last N instructions the CPU performs
This should be easy to add as well.
With the hex editor, showing Blue - execute, Green - Read, Red - Write, Yellow Read/Write and being able to turn off decay and then Mark the areas already highlighted.
This should be much easier to implement than before with the new hex editor.
Having HardReset/ColdBoot/ColdStart also reloading the ROM file would be worth its weight in gold.
Hard resets already reload the rom.

Thanks for the feedback!
Oziphantom
Posts: 1565
Joined: Tue Feb 07, 2017 2:03 am

Re: Mesen - Debugger Feedback?

Post by Oziphantom »

Sour wrote:
Oziphantom wrote:The Debugger code view seems to get confused easily
I'm not sure what you mean - the debugger keeps track of what it knows to be code. If it cannot tell with certainty that something is code, it is displayed in an unknown block until it can be certain that it is in fact code (e.g usually after it has been executed at least once). The more code you run, the more accurate it becomes.
Well the code highlighted I'm 95% sure had run by the time I took the screenshot, but then later when it has the data which it shows as code with illegals LAX, SLO etc, would have been accessed but defiantly not executed, looking at the code you can see it would crash the system if it had. BTW it is Duck Hunt(world).nes ROM
Sour wrote:
Oziphantom wrote:If you have a monitor that lets you specify labels, breakpoints, watches then you can put a custom file on the the command line params, which then lets you open Mesen, add a bunch of labels, breakpoints etc from an external tool.
You can already import labels from CC65 - I'm not sure what you would import breakpoints & watches from?
A text editor. What you can do if your IDE doesn't have it own system, is make special labels so for example if we look at this code

Code: Select all

birdUpdate
	jsr mainGameHitDetect_C64VICTriggerSystem
	jsr HUD.updateCurrBird
	jsr GFSM_dispatchBirdFunction
	lda BirdEnts.alive
	beq _noFlyAway
	#ISAEqualTo SkyColour,#kHud.Colours.FlyAwaySky,_noFlyAway
	#ISAMinus HasFirstBirdCrossedActiveLine,_doFlyAwayCheck
	#ISAGTE BirdEnts.y,#160,_noFlyAway
	#STN HasFirstBirdCrossedActiveLine
_doFlyAwayCheck
	#ISAMinus CurrentShot,_doFlyAwayNoShots
	lda FrameCounter
    lsr a 
    bcc _noFlyAway
	#DecToHoldFF FlyAwayTimer
	bpl _noFlyAway
	bmi _doFlyAway
_doFlyAwayNoShots
	lda #0
	jsr bird.setBirdToNewDir
_doFlyAway	
	; need to show dialog here	
	#STAB #kHud.Colours.FlyAwaySky,SkyColour	
	#STAB #kGFSM_Bird_index.updateFlyAway,BirdEnts.functionIndex
	jsr HUD.setupFlyAwaySprites
_noFlyAway	
	#ISANotEqualTo BirdEnts.functionIndex,#kGFSM_Bird_index.empty,_exit
	; either shot of flew away
	;#STAB #kMG_FSM_index.endBird,MainGameFSMIndex
	#STAB #kHud.Colours.Sky,SkyColour
	#STAB #kMG_FSM_index.dogShowCatch,MainGameFSMIndex
	#ISAZero NumBirdsShot,_laugh
	#STZ BirdEnts.functionIndex
	jsr HUD.clearFlyAwayBitmapData
	rts
_laugh
	#STAB #kDogShowBirdFSMIndex.SetupLaugh,BirdEnts.functionIndex
;	#STAB #kMG_FSM_index.dogLaugh,MainGameFSMIndex
_exit
	rts
Which has a lot of sub branches and some of the paths don't have convenient labels to latch onto.
Say I want to break after the 'lda BirdEnts.alive beq _noFlyAway' check up the top. I would normally set a break point to the parent function 'birdUpdate' then when it fires, search through the code till I find the part I want then move the breakpoint. What I can do instead is

Code: Select all

birdUpdate
	jsr mainGameHitDetect_C64VICTriggerSystem
	jsr HUD.updateCurrBird
	jsr GFSM_dispatchBirdFunction
	lda BirdEnts.alive
	beq _noFlyAway
_BREAK_
	#ISAEqualTo SkyColour,#kHud.Colours.FlyAwaySky,_noFlyAway
Then I have a script that parses the label file the assembler spits out. I should at this point mention how VICE works. The Label file runs Commands, where the AddLabel command ( abbreviated to al) is used as

Code: Select all

al .birdUpdate $0a9e
al .birdUpdate__doFlyAwayCheck $0ab6 (note I just made the addr up )
....
but you can put any monitor commands in the file. So I scan for file for _BREAK_ which in this case will be al .birdUpdate__BREAK_ $0aa9 to which I then append a
'break $0aa9' to the labels file. When the LoadLabels(ll) is executed ( as a command line argument ) it then adds all the labels then adds the break points. This way I can set breakpoints from my code editor, they are set before the code runs, and I don't have to keep setting and adjusting every time. Also when I change the code and shift everything down as I added some code, the breakpoints get reset in the correct position by me just doing the 'll' command again.
You can also set up watches. Given a variable is defined as, you can then do

Code: Select all

*=$02 ; ZP
CurrentLevel .byte ?
WATCH_LOAD_STORE_CurrentLevel = CurrentLevel
or
WATCH_LOAD_CurrentLevel = CurrentLevel
or
WATCH_STORE_CurrentLevel = CurrentLevel
Where this then finds an appends a 'watch load/store address' command to the labels file. Load = watch read, Store = watch load allowing me to track watches on variables from the text editor as well. Given the variables are assigned dynamically by the assembler it lets me easily set them without having to look it up live in the emulator.
VICE also exposes a TELNET interface to the monitor, so you can "remote debug", however IDE's such as CBM Studio use the telnet to allow dynamic breakpoints. I.e you run code then click on the line you want to break on, since it has its own internal assembler it can work out where it is in RAM, then via the telnet connection it will send a 'break ADDR' command to running VICE to add the break point, VICE then send back what number breakpoint it is, so when you click the breakpoint to remove it, the IDE can send 'delete NUM' to remove it. Although I personally don't use the IDEs ( as their internal assemblers are too weak for my tastes ) a lot of newbies and people returning to the scene head straight for them as they are comfy and help get them back up to speed quickly and let them get things happening.

Probably not something you can really do for CC65 but CA65 should be able to support it.
Sour wrote:
Having HardReset/ColdBoot/ColdStart also reloading the ROM file would be worth its weight in gold.
Hard resets already reload the rom.
NICE!!! :D
Sour
Posts: 890
Joined: Sun Feb 07, 2016 6:16 pm

Re: Mesen - Debugger Feedback?

Post by Sour »

Some more updates: download preview build

PPU viewer: Added a lightweight tile editing tool in the CHR viewer. The selected tile (select by clicking on it in the left-side view) is drawable, can press 1-4 to select palette for left button, right button is color 0. Changes are "live" and can be done while the emulator is running.
tileeditor.png
Hex Editor:
-Ability to highlight read/write/exec bytes and have them fade after X frames
-Ability to freeze memory values to prevent the rom from changing them (right-click on hex editor)
-Added context menu shortcuts (add label, breakpoints, watch)
-Ability to de-emphasize (make semi-transparent) read/written/executed/unused bytes
hexeditor.png
Trace Logger: This now shows recently executed instructions (keeps the last 30k instructions in memory) - this works even if the trace logger window is not opened (but the debugger window must be opened for the instructions to be logged)
tracelogger.png
Debugger:
-Added "break on unofficial opcodes" and "break on BRK" options (breaking on other OP codes is possible via conditional breakpoints)
-Added a "Save ROM as..." option to save ROM file containing any modifications done to PRG ROM or CHR ROM (including via the tile editor tool). (Only works on .nes files for now)
-Conditional breakpoints: Greatly improved performance - can still run at well over 60fps with several conditional breakpoints executing on every CPU instruction
tepples wrote:This would be killer, particularly if you were to make an oldskool UI reminiscent of Genecyst.
Sorry, it doesn't look very oldskool!
Oziphantom wrote:Well the code highlighted I'm 95% sure had run by the time I took the screenshot
The debugger needs to be opened while the code runs for it to be properly registered as code - that's probably what happened.
As for importing breakpoints/watch values, I can probably come up with a fairly simple format for it - though I don't expect to go much further than that (e.g: telnet, a console, and the like would take far too much time to add - there are a lot of other things I still want to add to Mesen that would take priority over this)
Sour
Posts: 890
Joined: Sun Feb 07, 2016 6:16 pm

Re: Mesen - Debugger Feedback?

Post by Sour »

I just finished adding an assembler tool

Features:
-Edit existing code in PRG ROM (or anywhere)
You can multi-select lines in the code window and right-click"Edit selected code" to start editing it.
(I also added a small feature to copy the selected code to the clipboard.)

-Allows you to assemble and add new code anywhere (ram, rom)
-Supports labels & comments (but they are not kept once the code is updated)
-Automatically assembles as you type
-Validates syntax and warns you of errors (as you type the code)
-Any change done to PRG ROM will be saved to the ROM file if you save it (File->Save ROM as)

I've also added a feature that lets you type code in the assembler and run it right away on the CPU ("Execute" button in the screenshot below).
Whatever code you execute ends up being mapped to $3000-$3FFF (it steals the address range from the PPU temporarely) and executes until a write to $3000 is done (or the last list of the code is reached)
After the write to $3000, execution returns to wherever the PC was before.
Registers and the like are not restored, so it's up to the code you use to save/restore values/registers you don't want to alter.
This basically lets you alter the state of anything by using 6502 assembly.
assembler.png
codewindow.png
Last edited by Sour on Tue Mar 14, 2017 8:30 am, edited 1 time in total.
Oziphantom
Posts: 1565
Joined: Tue Feb 07, 2017 2:03 am

Re: Mesen - Debugger Feedback?

Post by Oziphantom »

I took the last preview for a quick spin, good stuff.

Code editing. NICE!!!!

If you could add some nice Syntax Sugar, delete on a row, NOPs it. Handy for removing a JSR line when hunting or trying to figure out what makes something go wrong. Having a restore from ROM option would be nice as well.
User avatar
rainwarrior
Posts: 8731
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Mesen - Debugger Feedback?

Post by rainwarrior »

Oziphantom wrote:If you could add some nice Syntax Sugar, delete on a row, NOPs it.
I remember the SN Systems debugger for PS3 had this feature. It was pretty handy sometimes.
Oziphantom
Posts: 1565
Joined: Tue Feb 07, 2017 2:03 am

Re: Mesen - Debugger Feedback?

Post by Oziphantom »

rainwarrior wrote:
Oziphantom wrote:If you could add some nice Syntax Sugar, delete on a row, NOPs it.
I remember the SN Systems debugger for PS3 had this feature. It was pretty handy sometimes.
Perfect for getting rid of an Assert that is somebody else's problem - and is firing 5 times a frame ;)

With the Trace history could you expand the P from being a hex byte to show the flags, it is really obtuse. Also is it in 6502 silicon order or 6502 Datasheet order?
If you are worried about space you could only show active signals ie.

N--I0-- or NzcI0vb -> NI for negative and Interrupt
Sour
Posts: 890
Joined: Sun Feb 07, 2016 6:16 pm

Re: Mesen - Debugger Feedback?

Post by Sour »

Thanks for the feedback - I've added an option to select the output format for the status register: "Hexadecimal", "Text" or "Text (Active only)" - which corresponds to the original format + the 2 suggested alternatives (I didn't update the download yet though)

The removed code is already turned into NOPs - deleting a line will add a corresponding number of NOPs at the end of the edited block. It would be relatively complex to insert the NOPs where the deletion(s) occurred, considering you can also delete/insert/modify other portions of the code as well.
As is, you can already re-edit the code, delete the NOPs at the bottom & add the line you had deleted back. You do have to remember the erased code's exact location to be able to do this, though.

I'll also add "Discard PRG changes" and "Discard CHR changes" when I get a chance (to reset code/graphic modifications done with the hex/chr/code editors)
Post Reply