Table of Contents

Script for lDebug (SLD) file for the HP 95LX, and more lDebug development

2022-09-25

Having adjusted the R, U, D, and E commands to be more 40-column friendly I am currently using the following script for lDebug (sld) file to set up the debugger:

r dco or= 800
r dco6 or= 1200
r dco2 or= 111
r ior = #16
r ioc = #40
r dao or= 80

The script file is stored in A:\95LX.SLD. I run the debugger using a command like lcdebugu /d- /cy95lx.sld. (I only transfer non-DPMI lCDebug builds to the 95LX because they can act both as the normal outer debugger or the inner debuggable debugger.)

2022-09-26

I added one line to the 95LX.SLD script for lDebug file. I also created an alternative file which is useful for debugging filter style programs like unix2dos and b16cat. This is the full Q95LX.SLD file:

@r dco or= 800
@r dco6 or= 1200
r dco2 or= 111
r ior = #16
r ioc = #40
r dao or= 80
r dco3 and= ~ 4000_0000

This file is used in a command like lcdebugu.com /d- /c@yq95lx.sld. The additional AT signs '@' insure that no output is written to the stdout DOS handle. After DCO6 flag 200 is set all further output of the debugger interface goes to the BIOS terminal so it won't interfere with the data sent to stdout.

Clearing DCO3 flag 4000_0000 helps debugging a filter program, too. With this option set, the get key function's idle loop will also call interrupt 21h service 0Bh to make DOS check for Control-C. Unfortunately, it appears that this check sees the Control-C before our interrupt 16h calls get it. Therefore DOS writes "^C" to stdout and then cancels the debugger process. (The cancelling is fine, that is not a problem and works as intended.) This was observed as the ^C string missing when running with stdout redirected. It goes to stdout instead of the terminal. Clearing this DCO3 flag makes it so our interrupt 16h calls receive the Control-C keypress and we display "^C" to the terminal as intended.

During debugging of this problem I created a memory image of the debugger's code segment and data segment. It went something like this:

Now you have a binary file that's nearly 128 KiB sized and should contain everything to trace execution until the keypress is received.

Adjustments to the debugger

R: 16-bit display re-arranged to use 3 lines instead of 2, showing up to 5 of the 16-bit registers per line. Direction Flag and Interrupt Flag states are displayed as with one letter each.

U: Mnemonic offset adjusted from 28 to 20, meaning only 4 bytes of machine code can be dumped per line (in a 16-bit code segment). Not perfect as long instructions can still exceed 40 columns. Jumping notices and referenced memory display still displayed up to 79th column.

D: 8 bytes of data per line instead of 16. Segment is not displayed on data lines. All DB/DW/DD command outputs fit in 40 columns (for 16-bit segments). Segment is displayed in header and trailer, if those are enabled.

E: After continuing interactive E mode by entering a blank, the prompt line will wrap around before any offset divisible by 4 intead of only divisible by 8. Output will not exceed 39 columns (in a 16-bit segment) except for when a byte with address modulo 4 equal to 3 is updated with two hexits and the update confirmed with a minus sign '-'.