Table of Contents
Early December work
2024-12-08
Today marks the 100th blog post that I wrote on the HP 95LX. It also is likely to be the last post in December due to the café closing for a few weeks starting tomorrow.
lDebug
The lDebug repo got updated some.
- Put the online help depack buffer into the message segment, avoiding eating into the data/entry segment. Initially this was progbits allocation to simplify the change.
- Introduce the message segment nobits size equates.
- Fix debug.asm to use message segment nobits size for BOOTCODETARGET1
- Move online help depack buffer at end of message segment, nobits, with an indirection in the case of boot help truncation.
- Fix init.asm to use message segment nobits size for total boot allocation size
- Initialise the nobits trailer of message segment in boot init
- Enumerate largest help text file to shrink the online help depack buffer by 246 bytes.
- Only show hint about heatshrink Z use once during help compressing
- Update news-r9 section of manual
Online help compression
Compressing the online help using heatshrink, non-solid (ie every page on its own), costs about 300 bytes of code and nearly 3 KiB for the depack buffer which now lives in the message segment. However, the total memory use of the debugger as well as the size of the uncompressed executable both shrink by several kibi bytes.
Immediate assembler and dual code segments
Prior to release 9 we have now enabled the immediate assembler feature of the debugger. This is accessible to the user using dot commands, eg . add ax, 26 would add 26h to the AX register and set the arithmetic flags accordingly. Most instructions are supported for this. Those involving CS or IP are implemented using a number of workarounds and "as if" processing to get the expected results.
As a side effect of enabling _IMMASM, the lDebugX (DPMI-enabled) builds now employ the dual code segments. This is bad for performance but allows the code to grow more than before, limited as it was to 64 KiB.
MS-DOS kernel
- In EVEN mmacro emit NOPs for BIOCODE section
- Rename msbio CODE section to BIOCODE
- Fix inclusion of empty TEXT and Table sections in msdos, and add paragraph-aligned DOSSTART
- Include dosseg.nas in msbio1.nas
- Prepare src/INC/MAKEFILE to use const2.nas ported file (forgotten during porting)
- Delete src/INC/CONST2.ASM original file (forgotten during porting)
- Rename five variables in msdos to avoid clash with msbio variables:
- Link the entire msdos at the end of msbio module
- Make use of the linked in msdos rather than that passed by lDOS drkernpl
- Pass empty binary file instead of msdos.sys when building the lDOS drkernpl stage
- Update msinit.nas INIT comment to note the passed DOS is no longer used
- Add support for lCFG block and its check debugger field, picked from EDR-DOS changes to the same effect (1, 2). (Lightly modified the register usage.) Split into two changesets: Pass and use lCFG block for two flags, and add two more flags.
- Comment on msinit.nas INIT receiving cx:di → lCFG block
2024-12-11
- Quote a warning message that got corrupted from a define (
Debug) in msconst.nas - Change class of DOSSTART to DOSSTART to avoid generating a different section in the sharer
- Use new object files for sharer to prepare for nobits DOS data. This changeset produces exactly the same output as the prior one.
- Adjust sectioning in sharer to match new one of msdos
- Truncate sharer executable by only assembling DOS data as nobits (uninitialised) space. Saves about 5000 bytes of executable size at no cost. Checked to generate the same prefix and same effective minimum allocation as prior changeset using ident86.
- Avoid creating empty TEXT section in const2.nas
- Rename different LAST section to AFTERDOS to clarify. (It likely only worked because it was another LAST section, not the one used by the msdos objects. As we discovered, the LAST section isn't empty.)
ident86
- Add -j / --show-diff switch, to dump trace listing lines that correspond to differing bytes. I found my self doing this look up and crossreferencing manually, so of course there was an idea to automate it.
- Strip some leading blanks before the -j trace listing line dump.
- Shorten the -j trace listing dump some more.
- Add -J / --show-diff-colour switch to reverse video the specific bytes that were listed as different bytes.
- Before -j output display filename related to the trace listing lines.
- Match MS-DOS I_am mmacros as sized data directives in the trace listing file.
- Put a debug message to after currentfile being defined, and check that currentfile is not empty.
- Allow to match question marks in the hexdump generated by NASM. Needed for MS-DOS sharer conversion to use a nobits image of DOS data.
- Avoid an exception if no --include paths given.
- Disallow to match structure members, needed after the change to allow matching question marks.
- Add more debugging output around map ranges use.
- Fix, add args.offset to mapranges once, after the headersize has been applied to the default args.offset of
+0. Needed after the 2024-12-01 changeset that added the headersize variable to every map range tuple. In addlistu we used to add the args.offset to every map range tuple, so that effectively the header size got counted twice. - Add -X / --trailer-size switch to change length of the listed trailer.
- Display contents and deltas of differing MZ header fields and effective minimum allocations.
- If no source file name found in the .tls, use the .tls filename itself as the name.
I found that the case of a symlink containing an absolute pathname is already handled correctly by Python when using pathlib's / (slash) operator. If the second operand is an absolute path, then the first operand is not prepended.
fixmem
- Fix following a symlink with an absolute pathname, would prepend the link's directory incorrectly before.
- Fix following one symlink but not a second one, if a link points to a link.
- Use File::Basename dirname function rather than manipulating a pathname manually in symlink processing.

Discussion
I notice that the MS-DOS source code has many lines with say ;AN004 at the end. I figured this was some internal Microsoft annotation which would be meaningless outside, but I see that even on new lines that you've written they can be present. What is their purpose?
I know as much (or little) about those as you. I figured the numbers are likely related to revisions or issues in some external system. I don't (intentionally) add them to lines that I add but it is likely I may have left them in when editing something. Feel free to link examples of that!
Oh yeah if you look at the start of the file like in https://hg.pushbx.org/ecm/msdos4/file/b9535f8582cc/src/BIOS/sysconf.nas#l11 you see a list of the revisions corresponding to the codes it seems.
This is the one that caught my eye, but looking at it again now I see it's a large modification of an existing line not a new one. https://hg.ulukai.org/ecm/msdos4/rev/b9535f8582cc