Mesen - Debugger Feedback?
Moderator: Moderators
Re: Mesen - Debugger Feedback?
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.
Re: Mesen - Debugger Feedback?
@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".
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".
Re: Mesen - Debugger Feedback?
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).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?
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi
Re: Mesen - Debugger Feedback?
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).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).
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!
Re: Mesen - Debugger Feedback?
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): Example with FF3 (J) with a TBL file loaded to convert to kana: 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: 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
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): Example with FF3 (J) with a TBL file loaded to convert to kana: 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: 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
Re: Mesen - Debugger Feedback?
This would be killer, particularly if you were to make an oldskool UI reminiscent of Genecyst.Sour wrote:-A simple visual CHR editor
-Ability to save edited PRG/CHR ROM back to a .nes file
-
- Posts: 1565
- Joined: Tue Feb 07, 2017 2:03 am
Re: Mesen - Debugger Feedback?
I see this continues the gui spaghetti debugger trend
The Debugger code view seems to get confused easily here the unknown block is
Then latter you get to
Which is really
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
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
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.
The Debugger code view seems to get confused easily 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
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
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
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)
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.
Re: Mesen - Debugger Feedback?
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:The Debugger code view seems to get confused easily
You can already import labels from CC65 - I'm not sure what you would import breakpoints & watches from?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.
Adding breakpoints on specific instructions should be easy, I'll see what I can do.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.
This should be easy to add as well.What it does is, it keeps a trace of the last N instructions the CPU performs
This should be much easier to implement than before with the new hex editor.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.
Hard resets already reload the rom.Having HardReset/ColdBoot/ColdStart also reloading the ROM file would be worth its weight in gold.
Thanks for the feedback!
-
- Posts: 1565
- Joined: Tue Feb 07, 2017 2:03 am
Re: Mesen - Debugger Feedback?
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 ROMSour wrote: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:The Debugger code view seems to get confused easily
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 codeSour wrote:You can already import labels from CC65 - I'm not sure what you would import breakpoints & watches from?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.
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
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
Code: Select all
al .birdUpdate $0a9e
al .birdUpdate__doFlyAwayCheck $0ab6 (note I just made the addr up )
....
'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
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.
NICE!!!Sour wrote:Hard resets already reload the rom.Having HardReset/ColdBoot/ColdStart also reloading the ROM file would be worth its weight in gold.
Re: Mesen - Debugger Feedback?
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. 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 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) 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
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)
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. 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 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) 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
Sorry, it doesn't look very oldskool!tepples wrote:This would be killer, particularly if you were to make an oldskool UI reminiscent of Genecyst.
The debugger needs to be opened while the code runs for it to be properly registered as code - that's probably what happened.Oziphantom wrote:Well the code highlighted I'm 95% sure had run by the time I took the screenshot
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)
Re: Mesen - Debugger Feedback?
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.
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.
Last edited by Sour on Tue Mar 14, 2017 8:30 am, edited 1 time in total.
-
- Posts: 1565
- Joined: Tue Feb 07, 2017 2:03 am
Re: Mesen - Debugger Feedback?
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.
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.
- rainwarrior
- Posts: 8731
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: Mesen - Debugger Feedback?
I remember the SN Systems debugger for PS3 had this feature. It was pretty handy sometimes.Oziphantom wrote:If you could add some nice Syntax Sugar, delete on a row, NOPs it.
-
- Posts: 1565
- Joined: Tue Feb 07, 2017 2:03 am
Re: Mesen - Debugger Feedback?
Perfect for getting rid of an Assert that is somebody else's problem - and is firing 5 times a framerainwarrior wrote:I remember the SN Systems debugger for PS3 had this feature. It was pretty handy sometimes.Oziphantom wrote:If you could add some nice Syntax Sugar, delete on a row, NOPs it.
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
Re: Mesen - Debugger Feedback?
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)
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)