2025-08-30
As August's end nears, this week I did a lot of things.
List the supported flags as hex as well, if they are >= 16 and not part of a dual-flag entry. This makes it easier to determine how to combine flags, or specify single ones using + or -.
Fix: List the progress choices as types (0, 1, 2, 3, 4) rather than flags (1, 2, 4, 8, 16).
This program allows to renumber the AMIS multiplex number of a resident AMIS multiplexer if its int 2Dh entrypoint follows a certain format. Of course, our TSRs all do follow this format.
Note the equivalent instructions using AL for cmpsb, insb, movsb, and outsb. The particularly interesting one is lodsb
followed by scasb
for cmpsb, as it implies that scasb is like cmp al, [es:di]
because cmpsb is like cmp byte [si], [es:di]
("source index" first). Sometimes, like for the AMIS check id function, it is relevant which way the scasb comparison is.
Adds the sortmap.pl script, which extracts the interesting bits from the WarpLink extended map file's detailed segment map and sorts the file sections according to the binary order of the full sections instead of according to the files.
The remaining two changes are not only on sortmap.pl:
During testing the sortmap.pl script, I found that one file section showed up with an alignment of "512" (should read "256") or, in the map file, "PAGE". Curiously enough, the actual alignment seemed to be on a byte boundary.
I created some tests to see how NASM emits the different possible alignments, and studied the omfdump and WarpLink extended map file outputs of those. (I found a NASM bug during this, where it is supposed to emit a warning if it rounds up an alignment, but the warning only shows up if an error is emitted.)
Sure enough, out of the 7 possible values for alignment, WarpLink only supported BYTE, WORD, PARA, and PAGE. The unsupported DWORD, 4KIB, and a remaining invalid value where handled in different ways in the three spots relevant to this. That's how we observed a "PAGE" alignment in the map file but the section wasn't actually aligned to a 256-byte boundary.
Through the wonders of free software I determined where the alignment is read, and added support for NASM's DWORD and 4KIB alignment. The changes in particular:
call far
didn't seem to work correctly when both the call and the destination were in the same object file.The check id function is passed a structure that includes a reserved word, a sequential number, and a counted string as application ID. The DOS's multiplexer compares the ID and sequential against a table, returning an F0h to FFh return code to accept or an E0h to EFh return code to fail. The design of passing a sequential is copied from plans I had for lRxDOS v7.30 that never materialised. However, some of the parsing the table is offloaded to the multiplexer resident in the DOS, providing greater flexibility.
That was it on the version checks.
mov al, 3
and iret
).The SETDRIVE case was interesting in that the function did return an error status, but this was only ever checked in two spots. Everywhere else, the caller assumed ds:di -> a valid UPB and acted accordingly. This could lead to memory or data corruption if a caller specified an unknown unit number.
The only two changes are updating and syncing the AMIS private function descriptions in the manual and in amis.asm, as well as updating the attribution year in amis.asm to read 2025.
Discussion
The NASM behaviour of encoding
call far label
wrongly with the label in the same object file was a bug of at least some NASM v2.16 revisions that's been fixed since, refer to https://bugzilla.nasm.us/show_bug.cgi?id=3392949Bug was introduced into the v2.16 series on 2022-12-07 and fixed on 2023-10-17.