jzintv debugger suggestions

[GroovyBee]

Apologies if it does this already but :-

 

1) How about specifying a special entry point using a known label name (but no fixed address). When you load in your *.rom file and symbol file the debugger will then insert a breakpoint at that address and then execute the ROM automatically (normal machine reset procedure). Thus when you get beyond the title page you are at the place where you want to be. It just saves typing "bXXXX", "r" and then clicking on the jzintv display and then pressing Ctrl.

 

Its kind of like just magically appearing at "main" when you are debugging high level "C/C++" applications. If you had to go through the *.exe housekeeping and set-up all the time it would take the shine off development.

 

2) Maybe its my style of debugging but the input focus always seems to be on the wrong thing to me. For example :

 

When I hit F4 to break into the debugger the input focus isn't on the console command window where I'd expect it to be.

 

When I type "r" in the console command window it still has the focus when at that point I'm interested in the output window if a breakpoint hasn't been encountered or I'll be dropped back into console window input mode if it has.

 

I guess I'm one of those developers that doesn't like too much mouse moving and clicking when I'm debugging.

 

No problem if its not possible to implement these suggestions.

[+DZ-Jay]

When I hit F4 to break into the debugger the input focus isn't on the console command window where I'd expect it to be.

 

When I type "r" in the console command window it still has the focus when at that point I'm interested in the output window if a breakpoint hasn't been encountered or I'll be dropped back into console window input mode if it has.

 

I guess I'm one of those developers that doesn't like too much mouse moving and clicking when I'm debugging.

 

I would appreciate these enhancements as well, if they are indeed possible and not too much hassle.

 

It is annoying that the focus remains on the console when "running," and on the output window when "debugging". I tend to forget using ALT+TAB fairly often, say, when hitting a breakpoint, and then wonder why pressing "ENTER" does not step through the code.

 

-dZ.

[intvnut]

Apologies if it does this already but :-

 

1) How about specifying a special entry point using a known label name (but no fixed address). When you load in your *.rom file and symbol file the debugger will then insert a breakpoint at that address and then execute the ROM automatically (normal machine reset procedure). Thus when you get beyond the title page you are at the place where you want to be. It just saves typing "bXXXX", "r" and then clicking on the jzintv display and then pressing Ctrl.

 

Its kind of like just magically appearing at "main" when you are debugging high level "C/C++" applications. If you had to go through the *.exe housekeeping and set-up all the time it would take the shine off development.

I have some ideas in mind for making that smoother. In the meantime, "fMAIN" saves you a couple keystrokes versus "bMAIN" followed by "r". :-)

 

2) Maybe its my style of debugging but the input focus always seems to be on the wrong thing to me. For example :

 

When I hit F4 to break into the debugger the input focus isn't on the console command window where I'd expect it to be.

 

When I type "r" in the console command window it still has the focus when at that point I'm interested in the output window if a breakpoint hasn't been encountered or I'll be dropped back into console window input mode if it has.

 

I guess I'm one of those developers that doesn't like too much mouse moving and clicking when I'm debugging.

It is annoying that the focus remains on the console when "running," and on the output window when "debugging". I tend to forget using ALT+TAB fairly often, say, when hitting a breakpoint, and then wonder why pressing "ENTER" does not step through the code.

 

One downside of using SDL for jzIntv is that I don't have access to these sorts of mechanisms (ie. changing focus). In fact, SDL doesn't even know about the debugger "window", since that "window" is another application entirely! (Typically: xterm/gnome-terminal in Linux, CMD.exe in Windows, Terminal.app in MacOS X.)

 

So, in other words, if there's a way to do it, I haven't a clue what it is offhand, and it would be different for each platform jzIntv runs on. I wish I knew a way, since it's something that annoys me too.

[intvnut]

Ok, this is what I've added to jzIntv to support several different requests:

 

jzIntv's debugger can read scripts from files now (up to 16 levels of nesting, too). The new --script command line flag allows you to specify the script. The new command "<" (that's a less-than sign) tells jzIntv to read a script from the command line.

 

Script files are pretty much identical to the commands that jzIntv accepts at the debugger prompt, except that blank lines get ignored in scripts. Also both at the prompt and in a script, anything after a semicolon is now a comment, so you can add comments to your scripts if you like.

 

With scripts, you can implement "go main()" type functionality of whatever flavor you prefer. If you have a handful of watches, breakpoints or other things, you can specify them all in the startup script also. And scripts do nest, if that's something you're interested in. That is, a "<" command can appear in a script. Nesting depth is limited to 16 levels for now.

 

I've also added new output formats for addresses. You can select between four output formats:

• LABEL ($1234)
  
• LABEL
  
• $1234 (LABEL)
  
• $1234
  

The default is the first one ("LABEL ($1234)"), but you can easily switch to the second one if you'd rather hide addresses. And you can even put that in your debugger startup script if you like.

 

So, imagine this as your startup script:

L mygame.sym  ; Load my symbol table
; Keep an eye on some variables...
W var1
W var2
; Switch off that ugly address format...
O 1   ; use "LABEL" instead
; Run until we get past the title screen
F START_GAME

 

Nice, eh?

 

I'll be posting updated binaries later today. I have a bug report I'm chasing down from dZ-Jay that appears related to dirty-rectangle updates. If we can get that sussed and I can get a fix in, I'll do that before my next release.

Edited September 14, 2010 by intvnut

[GroovyBee]

Thanks for the flexible scripting . Now another suggestion

 

When the CPU crashes can you display the last 40 instructions or so? 40 is just an arbitrary number. At the moment all you get is the state of the registers and not what caused it to happen.

[+DZ-Jay]

Thanks for the flexible scripting . Now another suggestion

 

When the CPU crashes can you display the last 40 instructions or so? 40 is just an arbitrary number. At the moment all you get is the state of the registers and not what caused it to happen.

 

GroovyBee,

 

You can use the History Dump (d) command of the debugger. I believe you'll have to enable the History Logging (h) first.

 

-dZ.

[intvnut]

You can use the History Dump (d) command of the debugger. I believe you'll have to enable the History Logging (h) first.

 

Yes, that does work. I too, actually, would like an ability to see that from within the debugger without having to open a separate file. I'll work on adding that tonight.

[intvnut]

You can use the History Dump (d) command of the debugger. I believe you'll have to enable the History Logging (h) first.

 

Yes, that does work. I too, actually, would like an ability to see that from within the debugger without having to open a separate file. I'll work on adding that tonight.

 

Ok, what I added is this: The '!' command will show you a fragment of recent history, as long as you have history tracking enabled.

• ! by itself shows the last 40 instructions.
  
• !<#1> will show the last <#1> instructions.
  
• !<#1> <#2> will show the last <#1> instructions ending <#2> instructions ago.
  

Example:

> s10
00E6 0000 EB2E 8007 02F0 FE36 02f2 6E1F SC--I-i-  DECR R0              339571
00E5 0000 EB2E 8007 02F0 FE36 02f2 6E20 -C--I-i-  BNEQ $6E1D           339577
00E5 0000 EB2E 8007 02F0 FE36 02f2 6E1D -C--I-i-  ADD@ R5,R2           339586
00E5 0000 F70E 8007 02F0 FE37 02f2 6E1E S---I-i-  SUB@ R5,R2           339594
00E5 0000 F00E 8007 02F0 FE38 02f2 6E1F SC--I-i-  DECR R0              339602
00E4 0000 F00E 8007 02F0 FE38 02f2 6E20 -C--I-i-  BNEQ $6E1D           339608
00E4 0000 F00E 8007 02F0 FE38 02f2 6E1D -C--I-i-  ADD@ R5,R2           339617
00E4 0000 070D 8007 02F0 FE39 02f2 6E1E -C--I-i-  SUB@ R5,R2           339625
00E4 0000 0708 8007 02F0 FE3A 02f2 6E1F -C--I-i-  DECR R0              339633
00E3 0000 0708 8007 02F0 FE3A 02f2 6E20 -C--I-i-  BNEQ $6E1D           339639
> !5
00E4 0000 F00E 8007 02F0 FE38 02f2 6E20 -C--I-i-  BNEQ $6E1D           339608
00E4 0000 F00E 8007 02F0 FE38 02f2 6E1D -C--I-i-  ADD@ R5,R2           339617
00E4 0000 070D 8007 02F0 FE39 02f2 6E1E -C--I-i-  SUB@ R5,R2           339625
00E4 0000 0708 8007 02F0 FE3A 02f2 6E1F -C--I-i-  DECR R0              339633
00E3 0000 0708 8007 02F0 FE3A 02f2 6E20 -C--I-i-  BNEQ $6E1D           339639
> !5 5
00E6 0000 EB2E 8007 02F0 FE36 02f2 6E1F SC--I-i-  DECR R0              339571
00E5 0000 EB2E 8007 02F0 FE36 02f2 6E20 -C--I-i-  BNEQ $6E1D           339577
00E5 0000 EB2E 8007 02F0 FE36 02f2 6E1D -C--I-i-  ADD@ R5,R2           339586
00E5 0000 F70E 8007 02F0 FE37 02f2 6E1E S---I-i-  SUB@ R5,R2           339594
00E5 0000 F00E 8007 02F0 FE38 02f2 6E1F SC--I-i-  DECR R0              339602
> 

[GroovyBee]

Thanks for adding the crash dump feature. It is a shame about the window focus problem not being easily solvable . Maybe you could put a shout out in the main programming forum for workarounds?

[intvnut]

New in this release since Sunday:

   * Debugger features
         o Ability to read "debugger scripts".  The --script=file command line flag and "< file" debugger command tell the debugger to read commands from "file".  Up to 16 levels of scripts can be nested.
         o The "!" command prints out recent trace history, if history is enabled.  "!<#1>" outputs the last <#1> instructions.  "!<#1> <#2>" outputs the last <#1> instructions ending <#2> instructions back.
         o The "o" command lets you change the address display format among the following
               + LABEL ($1234)    <-- default
               + LABEL
               + $1234 (LABEL)
               + $1234
         o Everything after ";" on a line is a comment.  This is mainly useful for debugger scripts.
   * Bug fixes
         o Force double-buffering and dirty-rectangle updates to be mutually exclusive.  They are not compatible.
   * Examples updates
         o Converted many EQU/SET in various macros and gimini.asm to QEQU/QSET
         o Added back SCRATCH, SYSTEM, CARTRAM macros to cart.mac
         o Added new ECSRAM and REQ_ECS macros to cart.mac.  REQ_ECS adds a runtime check to verify ECS is present, too.
         o Tweaked a few ECS-specific examples to use the new REQ_ECS feature.

 

Binaries:

http://spatula-city.org/~im14u2c/intv/dl/jzintv-20100914-win32.zip

http://spatula-city.org/~im14u2c/intv/dl/jzintv-20100914-osx.zip

http://spatula-city.org/~im14u2c/intv/dl/jzintv-20100914-linux-x86-64.zip (Ubuntu 8.04)

http://spatula-city.org/~im14u2c/intv/dl/jzintv-20100914-linux-i686.zip (Ubuntu 9.04)

 

SDK-1600 Example Source:

http://spatula-city.org/~im14u2c/intv/dl/jzintv-20100914-examples.zip

 

Full source:

http://spatula-city.org/~im14u2c/intv/dl/jzintv-20100914-src.zip

Edited September 15, 2010 by intvnut

[GroovyBee]

It it possible to add a command where the CPU instruction cycles between two breakpoints can be saved for a set number of iterations and then displayed in table form? Basically I want to check how much CPU headroom I have per frame of the game. The path per frame differs depending on what the player, baddies and their various state machines, logic and AI routines are doing at any time so it is complex in nature. I have been tracing through code manually but it is quite time consuming.