2023-01-22

This week several things progressed with the debugger and the 95LX.

However, the first item of note is that I unearthed a three-button serial mouse. I connected it to COM1 of the 686 DOS box. (COM2 has the null modem cable to the Linux box because PD ZModem defaults to COM2, which I then copied in lDebug.) Installing a driver was as easy as issuing a ctmouse /v command, which apparently reconfigured the resident instance of Cute Mouse (version 2.1 something). The mouse's ball is a little clunky but it generally works.

During use of the debugger on the HP 95LX, I noticed upon some long line (probably testing nested IF commands) that the "^ Error" indicator's position wrapped around at the 40 columns that were configured in the IOC variable (I/O Columns). However, the whole input line was displayed as is to the display, running off the visible part of the screen (that is, the first 40 columns).

The solution was quickly found: When the rawinput line editor finally redraws the entire input line, it should split lines at 40 columns so as to stay within the visible part.

Easier said than done. I had to test the handling of this for an unusual amount of time, as the details kept slipping my grasp. I do think I succeeded eventually, but I did mark the code as magic. In this sense that means it is mysterious, surprising, or difficult to understand.

So after testing the new build on the Linux machine of course the next order was to transfer it to the 95LX.

The transfer of the lcdebugu.com file proved difficult. PD ZModem repeatedly terminated with an error. Eventually, I found that the free space on the SRAM card was below 3000 Bytes. I deleted some files to make space for the full file.

Next, it appeared that PDZM continued the transfer where it had aborted. The transfer appeared to run to its completion. However, running lcdebugu /d- /cy95lx.sld crashed the debugger with some erroneous messages.

I transferred a somewhat older build of lDebug (ldebug.com) after that. I also checked the lCDebug I had transferred in dosemu2 on the Linux box, where it worked flawlessly. Finally I ran lDebug on the problematic lCDebug on the 95LX. lCDebug started up fine, but did not quit on a Q command. Running BU and tracing into the Q command I found it was corrupted.

Moreover, I found out that there was no bug in the lCDebug program, its code section simply was corrupted. I tested for this by debugging the initial relocations and segment setups and finding that at the point the code section is relocated, the Q command code was already wrong.

So I had to transfer the lCDebug file anew.

Side note: The 95LX's shell appears to be missing a move command, and ren between different directories on the same file system also appears to fail.

Eventually, the IOCLINE splitting handling turned out to work perfectly. Which wasn't surprising after the tests on the Linux development box, but it's something.

As a german proverb has it, "Einsicht ist der erste Schritt zur Besserung" (translation: insight is the first step to improvement). Our Einsicht project certainly is at its first steps yet. After some organisational setup we now get two separate executables built from the Insight source tree. The Einsicht build defaults to enable the Terminal window support, whereas it defaults to disabled for Insight now. (With good reason: There is no sophisticated allocation of the terminal buffer; once enabled, it is allocated a full 64 KiB at the application's startup.)

After a bit of documentation of the prior changes to Insight, particularly the new keyboard shortcuts, the actual work on Einsicht kicked off with the Register window. It is now in a state where a register dump (R or RE command) in the connected lDebug will update the Register window in Einsicht, and register or flag modifications in Einsicht's Register or Flags window are sent to lDebug using an r reg := value command.

This is still far from perfect. Every digit or flag modified in Einsicht sends a separate command to lDebug. The Terminal window is not immediately updated with the sent command, requiring to enter another keypress to Einsicht or even exit the Flags window to trigger an update. And Einsicht never sends an R command for dumping registers, or r fl . to numerically dump the flags register, on its own. Consequently, initially it will not have lDebug's register values. Einsicht also does not reply to the lDebug KEEP prompt as yet.

Further, the lDebug register values are not yet copied to the saved registers at any point, so differences to Einsicht's initial values will always remain displayed as differences. (Except for the first time that Einsicht's Register window is opened, it will copy the current registers to the saved registers. The flag for this is set so that this only happens once. This flag is reset by Insight's Trace routines.)

Another bit that is not yet supported is to skip the lDebug register change highlighting escape codes that lDebug can intersperse into its output for the R register dump command. Partially supported is running lDebug on a 16-bit (pre-386) CPU, where writing to the 386-specific registers is not supported.

It leaves a lot to be desired, and the model of the register and flag updates will not exactly map to how disassembly and data buffers can be updated from lDebug output, but it is a start.