pushbx wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== lDebug release 5 goofs, Control-C, and planned new TSR /J switches ======

**2023-03-10**

The lDebug release 5 is done. Alongside [[blog:pushbx:2023:0308_ldebug_release_5|the blog post]] about the included changes, I also posted [[https://sourceforge.net/p/freedos/mailman/freedos-user/thread/b06a2bd9-ab11-514f-dcaf-e884af4c0715%40ulukai.org/#msg37787811|an announcement]] to the freedos-user mailing list. I [[https://www.bttr-software.de/forum/forum_entry.php?id=20174|copied this mail to the Announce section]] of the DOS Ain't Dead forum. I also linked to the mail [[https://twitter.com/pushbx/status/1633538094224793604|in a tweet]] on the pushbx twitter.

Some things didn't go quite as expected.

===== =====

[[https://pushbx.org/ecm/test/20230307/rel5.txt|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. ([[https://hg.pushbx.org/ecm/ldebug/file/release5/doc|Refer to the doc subdirectory]].)

As an aside, I discovered that the lDebug repo of the FreeDOS Gitlab site [[https://gitlab.com/FreeDOS/devel/ldebug/-/tree/4401c5e7c41ef235bc42f39d7c4132782b0c5a45/APPINFO|has a number of translations of the lDebug LSM]], which include the longer description (based on [[https://pushbx.org/ecm/doc/ldebug.htm#overview|"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 ([[blog:pushbx:2022:0927_script_for_ldebug_sld_file_for_the_hp_95lx_and_more_ldebug_development|first mention]] on the blog, and [[blog:pushbx:2022:1217_new_95lx_setup_script_for_ldebug|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 [[blog:pushbx:2022:0927_script_for_ldebug_sld_file_for_the_hp_95lx_and_more_ldebug_development|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


{{tag>ldebug 95lx tsr}}


~~DISCUSSION~~
pushbx wiki

User Tools

Site Tools

Page Tools
