====== Early November work ======

**2024-11-10**

This week some work happened on Enhanced DR-DOS, lDebug, MSDebug, and MS-DOS. I was also involved in commenting on several stackoverflow questions.


===== stackoverflow =====

==== MS-DOS Debug misbehaves when writing to 1000h:0 ====

[[https://stackoverflow.com/questions/79164865/debug-exe-from-dos-6-22-errored-on-assembling-mov-ax-imm16-with-the-a-command|A user attempted to assemble some code at 1000h:0]] using the command ''a 1000:0''. They noticed that the third instruction would cause an error and be assembled to the wrong opcode. They identified that this only happened on one system (MS-DOS v6.22 running in VirtualBox) and did not happen on another system (NTVDM of MSWindows 2000).

The first several comments discussed whether the question is appropriate for stackoverflow. I was the first [[https://stackoverflow.com/questions/79164865/debug-exe-from-dos-6-22-errored-on-assembling-mov-ax-imm16-with-the-a-command#comment139595912_79164865|to suggest a reason for the observed behaviour]]: The address 1000h:0 (linear 10000h, 64 KiB) may be in use by the kernel or the debugger. Thus, overwriting it may be the cause of the misbehaviour.

Another user (whose comments are now deleted) suggested that the written address would not be a problem, but was unable to answer why the error occurred, simply stating that the debugger application must be broken.

Eventually yet another user was able to recreate the wrong case and, along with references to the 2024 free software release of the Debug sources, [[https://stackoverflow.com/questions/79164865/debug-exe-from-dos-6-22-errored-on-assembling-mov-ax-imm16-with-the-a-command/79168610#79168610|confirmed that the erroneous write would corrupt a part of the debugger's assembler table]]. My diagnosis was spot on.


==== (Free)DOS Debug accepts ''mov cx, al'' instruction ====

[[https://stackoverflow.com/questions/79171410/how-to-print-a-symbol-for-a-user-provided-number-of-times-in-dos-assembly-x86|Another question was from a user writing a Debug script]] to be used in DOSBox-X. Their resulting program misbehaved. This turned out being due to their use of the instruction ''mov cx, al'' which the debugger silently assembled to a different encoding (''mov cx, ax'' or 89h C1h).

I first suggested this incorrect instruction [[https://stackoverflow.com/questions/79171410/how-to-print-a-symbol-for-a-user-provided-number-of-times-in-dos-assembly-x86#comment139607126_79171410|may be among those accepted by MS-DOS Debug]]. Trying in lDebug, the instruction correctly was flagged as an error. The user, however, stated that DOSBox-X shipped with the debugger used. I didn't think they'd ship a (formerly nonfree) MS-DOS Debug.

After searching a while, I [[https://stackoverflow.com/questions/79171410/how-to-print-a-symbol-for-a-user-provided-number-of-times-in-dos-assembly-x86#comment139607292_79171410|came across]] the repo's ''src/builtin/debug_exe.cpp'' that contained a hexdump of a file called debug.exe. Using a small perl scriptlet (''perl -pe 's/[^0-9A-Fa-f]*(0[Xx])?([0-9A-Fa-f]+)[,\r\n]*/sprintf("%c", hex($2))/ge' debug.txt > debug.exe'') I extracted the file. Turns out it is (Free)DOS Debug v1.25. Indeed, the binary exactly matches DEBUG.COM from [[https://pushbx.org/ecm/download/fddebug/DEBUG125.zip|that version's release]]. The choice of an .exe filename extension in the DOSBox-X sources is misleading, as the executable of this version of DOS Debug is a flat-format (.com) executable.

I did wonder whether the application is properly credited in DOSBox-X. Its source tree contains a file named CREDITS.md but the only relevant entry is "FreeDOS utilities as binary blobs (FreeDOS; no license)". Turns out [[https://stackoverflow.com/questions/79171410/how-to-print-a-symbol-for-a-user-provided-number-of-times-in-dos-assembly-x86#comment139607446_79171410|for the original DOS Debug branch this is probably fine]]. Maybe not so much for other FreeDOS applications included there.

Eventually I confirmed that the most recent release of DOS Debug/X still accepts the incorrect ''mov cx, al'' instruction. (**ETA**: I [[https://github.com/Baron-von-Riedesel/DOS-debug/issues/19|reported the bug to the DOS Debug/X repo]].)


=== The hunt for the bugfix changeset ===


I reviewed some lDebug releases but did not gain much information there, as the daily builds did not reach back far enough (only up to [[https://pushbx.org/ecm/download/old/ldebug/20211019.zip|2021-10-19]]) to accept the incorrect instruction.

Therefore I set up a build environment to build older lDebug revisions. This entailed several steps:

Clone lDebug, lmacros, ldosboot, scanptab, inicomp, crc16-t, and symsnip repos.

Try to update lDebug repo using a command like ''hg up -r 'branch(default) and date("<2018-02-19")' ''.

The lDebug repo would update to [[https://hg.pushbx.org/ecm/ldebug/rev/59cda96de21d|a changeset from much later that was backdated to 2010]] as it added an old doc file. Strip that changeset using ''hg strip -r .''.

Retry updating as before.

Update all the other repos to era-appropriate revisions, using this scriptlet:

<code>cd -
for d in *
do
  if [ $d != ldebug ]
  then
    echo -ne "$d: "
    hg up -R $d -r "date('<"$(hg log -R ldebug -r . --template '{date|shortdate}')"')"
  fi
done
cd -</code>

(On review, the quoting seems wrong but with the shortdate format it doesn't matter and works anyway.)

Build the debugger, using either ''INICOMP_METHOD=none ./make -w-pp-macro-params-legacy -D_BOOTLDR'' or ''INICOMP_METHOD=none ./mak.sh -w-pp-macro-params-legacy -D_BOOTLDR''

The NASM warning disabled there pops up when assembling older source trees with a recent NASM. It is emitted often enough to be distracting.

The explicit enabling of the _BOOTLDR define is needed for certain revisions (2018-02-19) that will fail to build if it isn't present. This bug [[https://hg.pushbx.org/ecm/ldebug/rev/0621cdaae7c5|was eventually fixed (2018-02-26)]], or can be worked around [[https://hg.pushbx.org/ecm/ldebug/file/dc3ae76de0dd/source/msg.asm#l808|by commenting out the LOADSETTINGS istruc uses in msg.asm]].

The output files produced will be either debug.com or ldebugu.com.


=== The changeset ===

This set up allowed me to identify the revision using a manual "bisect" style process (a roughly binary search to find the exact changeset). It turned out to be a happy coincidence; [[https://hg.pushbx.org/ecm/ldebug/rev/3bea7a5380de#l1.7|the changeset (2019-10-11)]] was only concerned with rejecting invalid combinations of the ''pushw'' and ''pushd'' push immediate instructions.

The relevant change is that in the line assembler's ''ao15'' the ''opsize'' variable is no longer set unconditionally. Instead, the control flow is transferred to ''ao09''. This part of the code checks that either the size in ''al'' matches ''opsize'', or ''opsize'' used to hold a zero (later named SIZ_NONE) and is then updated with the size in ''al''.

It turns out that in case of the invalid ''mov cx, al'' instruction the ''ao15'' code is called twice, once with the size being passed as 2 (SIZ_WORD) and once with it as 1 (SIZ_BYTE). With the unconditional overwriting, the instruction is incorrectly accepted.


==== 8086 segmentation ====

In this question, a user [[https://stackoverflow.com/questions/79170918/how-can-the-intel-8086-access-the-entirety-of-the-address-space-at-a-given-time|asked about the 8086 segmentation]]. At first I was puzzled by the "4 memory segments" framing until I parsed that these correspond to the four segregs that the 8086 has available. In effect, they stated that only up to 4 times 64 KiB can be accessed "at a time".

In my comments I stated that in practice what you do is use segment arithmetic and change the segment registers around to access more than that limit. I also addressed some statements about segment overlap. A different user eventually prepared a proper answer that's also good.

In the comments of that answer, the original poster suggested that a difference of 100h in the segment registers should lead to a unique prefix of offsets 0000h to 00FFh in the lower segment. I corrected this, stating that the answer's offset 0000h to 0FFFh is correct, as the segment address is specified in paragraphs of 16 bytes each.


===== Enhanced DR-DOS =====

This project's [[https://hg.pushbx.org/ecm/edrdos/shortlog/8a412e478d23|updates]] primarily concern [[https://github.com/SvarDOS/edrdos/pull/123|the micro-optimisations suggested to the SvarDOS repo's tracker]].

[[https://hg.pushbx.org/ecm/edrdos/rev/a0faf6054977|Two]] older [[https://hg.pushbx.org/ecm/edrdos/rev/888a99fe7697|commits]] of the SvarDOS repo that affect the shell were apparently forgotten in 2024 January. This came up during applying the optimisations. I picked these changes separately.

Finally, I [[https://hg.pushbx.org/ecm/edrdos/rev/8a412e478d23|updated the lDOS version]] to 2024 November.


===== webecm =====

I [[https://hg.pushbx.org/ecm/webecm/rev/b22fcc2340d0|added a section for MSDebug]].


===== fixmem =====

  * Bugfix, [[https://hg.pushbx.org/ecm/fixmem/rev/504bff736e8a|in getlabel match a16 register names caps-insensitively]] (MS-DOS sometimes uses them allcaps)
  * [[https://hg.pushbx.org/ecm/fixmem/rev/de522b4a2db2|Handle what appear to be labels starting with an a16 register name]] followed by a dot, expanding the dot into a plus
  * Support MS-DOS I_NEED macro [[https://hg.pushbx.org/ecm/fixmem/rev/6e4b86e1119a|without a size]], or [[https://hg.pushbx.org/ecm/fixmem/rev/71a64b99ead6|with a numeric size]] (both result in byte size)
  * Detect proc, procedure, or entry macros [[https://hg.pushbx.org/ecm/fixmem/rev/62a0668ef8fd|as defining labels]] (may be needed by MS-DOS)
  * Detect proc directive [[https://hg.pushbx.org/ecm/fixmem/rev/872d006f1f1e|with prepended label]] (may be needed by MS-DOS)
  * [[https://hg.pushbx.org/ecm/fixmem/rev/6bed3ab11e68|Use addequate or addlabel]] for labels used in a number of directives/macros, crucially ''public'' directives (needed for MS-DOS)


===== lDebug =====

Last week had a change not uploaded then, [[https://hg.pushbx.org/ecm/ldebug/rev/0db89ab6fcbd|describing the dbitmap Extension for lDebug]] some more in the manual.

The only recent change to the debugger was [[https://hg.pushbx.org/ecm/ldebug/rev/b319e854af46|to enable _DEBUG4 builds]] by referring to the ''getc.raw'' label rather than ''getc.rawnext''. However, _DEBUG4 builds with dual code sections may stlll be broken.

The change was needed to try and debug a problem with an older lDDebug, which occurred during the bisecting and examining of the change that prohibited ''mov cx, al''. It turned out that [[https://hg.pushbx.org/ecm/ldebug/file/3bea7a5380de/source/debug.asm#l4489|that revision of lDebug (2019-10-11) unconditionally called the serial port cleanup function in its qq command]]. This, of course, led to a hang in the outer lDebug (a recent revision) when it was connected to serial I/O.

I looked into reconfiguring the old lDDebug to avoid this, but it turns out back then the IRQ and port number [[https://hg.pushbx.org/ecm/ldebug/file/3bea7a5380de/source/serialp.asm#l326|were hardcoded]]. Another interesting aspect was that this lDDebug would also reset the IRQ's interrupt vector unconditionally, clearing it to zero if it was never hooked. This would lead to problems if serial I/O was reconnected later in the same VM.

This bug, of course, [[https://hg.pushbx.org/ecm/ldebug/rev/90bc2abad8d6|was fixed later (2020-05-15)]].


===== MSDebug =====

[[https://hg.pushbx.org/ecm/msdebug/rev/67e7a60e1ad7|The first changeset simply adds some changes]] to the manual that weren't listed yet, and updates a reference to a feature now partially done (sector access to drives > 32 MiB, but not FAT32 drives).

The subsequent changes concern the P command. It didn't [[https://hg.pushbx.org/ecm/msdebug/rev/a8e9d9186992|proceed past indirect call instructions]] (FF /2 and FF /3) if their mod=0 or (near only) mod=3. Further, it didn't [[https://hg.pushbx.org/ecm/msdebug/rev/1e9407e150c8|parse segment prefixes before the opcodes]], which may be valid for repeated string instructions or memory-indirect call instructions.

The mod=3 case and the segment prefixes it turns out were handled by MS-DOS v6.22 Debug. The mod=0 cases however were not. Thus these changes [[https://hg.pushbx.org/ecm/msdebug/rev/280225f784ac|are documented]] as partially recreating the later MS-DOS revisions and partially as new.

Further, the release number [[https://hg.pushbx.org/ecm/msdebug/rev/4ecb3327bd97|was updated to release 3]].


===== MS-DOS kernel =====

The msdisp.asm and disp.asm files being dropped last week didn't work initially, breaking the build. I fiddled with it some until I was able to have the build succeed, and use the new NASM sources.

The subsequent changes are all towards the next module, mscode.obj.

ifssym.inc could define IFSR_MODE to either a byte variable or a word variable. A possibly differing expansion (address) for the same define is fine, but fixmem.pl really wants them to all have the same size. Therefore [[https://hg.pushbx.org/ecm/msdos4/rev/7b0fe8a32d01|I edited the uses of IFSR_MODE]] to instead refer to IFSR_MODE_BYTE (lseek) and IFSR_MODE_WORD (open).

I also [[https://hg.pushbx.org/ecm/msdos4/rev/a2b3f2c0aed4|manually ported the multi-line macros in ifssym.mac]]. I put these macros into the "NASM original macros" block. Before that I added [[https://hg.pushbx.org/ecm/msdos4/rev/a2b3f2c0aed4#l1.12|a commented out list of all IFSR_ defines using the labelsize macro]]. Although the addresses (expansions) are all invalid, fixmem.pl will read the correct sizes from these lines to process uses of these defines.

The mmacros [[https://hg.pushbx.org/ecm/msdos4/rev/a2b3f2c0aed4#l1.74|will first undefine all IFSR_ smacros to avoid interference]], as [[https://hg.pushbx.org/ecm/fixmem/file/6bed3ab11e68/nasm.mac#l31|labelsize cannot deal with defines that are already defined]] as single-line macros.

[[https://hg.pushbx.org/ecm/msdos4/rev/ffc7437874c7|Some additional]] definite values [[https://hg.pushbx.org/ecm/msdos4/rev/0f1d98ba9c32|in structure definitions]] were dropped to avoid the "attempt to assemble code in absolute space" NASM errors. As before we may eventually need to handle instances of these structures specifically.

In dosmac.mac, [[https://hg.pushbx.org/ecm/msdos4/rev/fe2ce86e4de5|I_NEED macros now accept a single parameter]] and will default to byte size. (Numeric sizes were already accepted to mean byte size by accident.) Further, [[https://hg.pushbx.org/ecm/msdos4/rev/b214fd9d4893|some macros are newly defined]] with ''%imacro'' directives to match caps-insensitively.

In one instance, a ''TABLE ENDS'' directive was used to switch the current section back to the CODE section. The NASM macros do not yet contain a mechanism to make this work, so for now [[https://hg.pushbx.org/ecm/msdos4/rev/51272a22a431|I inserted]] a ''section CODE'' directive.

Finally, I pushed an incorrect changeset to the repo yesterday. Rather than [[https://hg.pushbx.org/ecm/msdos4/rev/7c12f037a571|deleting the original (.ASM) files]] I deleted the new (.nas) files. This predictably made the build fail. (I did think to manually delete the mscode.obj and mscode.fob files before the build ran.) I hope today's fix will make the build succeed.

{{tag>stackoverflow msdebug fddebug ldebug hg edrdos webecm fixmem msdos msdos4}}


~~DISCUSSION~~