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.
The lDebug repo got updated some.
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.
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.
2024-12-11
Debug
) in msconst.nas+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.
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.
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