User Tools

Site Tools


blog:pushbx:2023:0320_ldebug_release_5_goofs_control-c_and_planned_new_tsr_j_switches

lDebug release 5 goofs, Control-C, and planned new TSR /J switches

2023-03-10

The lDebug release 5 is done. Alongside the blog post about the included changes, I also posted an announcement to the freedos-user mailing list. I copied this mail to the Announce section of the DOS Ain't Dead forum. I also linked to the mail in a tweet on the pushbx twitter.

Some things didn't go quite as expected.

The commands I had prepared to create the native (zip and tlz) and FreeDOS and SvarDOS packages had one error: The FreeDOS package was named LDEBUG5.zip rather than having the entire name in allcaps as expected. This was because the 7za command to create the zip file originally created a draft zip file, which was named without caps.

The other thing is that the FreeDOS and SvarDOS packages now include two text files (.txt) that were not meant for general use but rather for development and historical reference, the segment 32-bit check list and the old log file from before the hg repo's initial commit. The FreeDOS build text file should be included, but it may be outdated. (Refer to the doc subdirectory.)

As an aside, I discovered that the lDebug repo of the FreeDOS Gitlab site has a number of translations of the lDebug LSM, which include the longer description (based on "Overview and highlights", the first section of the manual). These include a german translation (which I can read) and a french one (which for the most part I cannot read). The german translation seemed fine.

Control-C problems

2023-03-12

During recent testing of lClock's demo mode on the HP 95LX, I ran lCDebug with its 95lx.sld Script for lDebug file (first mention on the blog, and second mention) and then tried to trace through the clock application until its code segment changes, indicating that we ended up in the first demo call to the would-be resident section.

However, this trace took longer than expected. But I found I couldn't cancel it with a Control-C keypress. This happened to have three reasons:

Firstly, I disabled the interrupt 21h service 0Bh check in the shared Control-C checking code in the debugger. This is controlled by DCO3 flag 4000_0000h, which for some reason I disabled in the setup SLD. (Described some in the first mention.)

Secondly, I ran the trace with a SILENT keyword, meaning no output was generated until the end of the trace would be reached.

Thirdly, running without the SILENT keyword did not help because I also had set up DCO6 flag 200h to set, so that output is done exclusively using the ROM-BIOS interrupt 10h services. So DOS would only be able to detect Control-C when the debugger does input, which it won't do during the trace.

I did just test that even with all of these circumstances, adding a read of the IOI variable in the WHILE condition, eg as in while cs == v0 || (ioi & 0) (which discards the value read), does lead to the debugger checking for input from DOS and thus Control-C is detected. This variable, when read, causes the debugger to call interrupt 21h service 0Bh as well.

Another way to fix it is to set DCO6 option 100_0000h, which makes it so output and also input is done using the ROM-BIOS interfaces. Previously, DCO6 option 200h did this, but it was determined that it would be preferable to allow DOS script input from SLD files while doing ROM-BIOS output. This might be part of why we didn't come across this problem earlier.

New /J switches for TSRs?

We want to support additional behaviour modifications for our TSRs. However, adding additional switches could be a problem. So we can re-use and extend an existing switch, /J, which for now only controls whether DOS UMBs are used for the final resident allocation or not.

Unlike the HDPMI environment variables, which work with numeric values, I have decided that specifying different options as letters is more accessible. For this use case, a plus sign prefix could enable options and a minus sign prefix could disable them. Neither sign, but a letter after the J, is handled like a plus sign. A blank or tab or EOL or slash after the J is handled as the legacy "no DOS UMBs" switch.

What options are there?

  • U or L? for the legacy /J switch no DOS UMBs behaviour
  • P for no PSP relocation
  • T for installing interrupt handlers on top, rather than below if the EOI flag is set
  • D for not detecting a debugger
  • S for skipping the 86-DOS version 2 system check
  • E for not running an invalid EXEC system call before process relocation
  • N and O could be allowed as the same options as the /N and /O switches
You could leave a comment if you were logged in.
blog/pushbx/2023/0320_ldebug_release_5_goofs_control-c_and_planned_new_tsr_j_switches.txt · Last modified: 2023-03-20 20:16:15 +0100 Mar Mon by ecm