User Tools

Site Tools


blog:pushbx:2025:0830_a_variety_of_progress

A variety of progress

2025-08-30

As August's end nears, this week I did a lot of things.

patchini

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).

renumber

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.

Instruction reference

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.

tractest

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:

lDOS kernel

  • Optimise int 2Fh handlers, eliminating two far jumps and relocating entries in DOSENTRY. (This unnecessary use of DOSENTRY space was the main reason to do this.) Now, the head i2F handler (set_i13_i2F) will chain using near jumps to disk_i2F and msdos_i2F. Also some more optimisation. The RE_INIT function in SYSINIT is now empty as it only initialised the msbio int 2Fh handler atop the msdos one installed by NEARDOSINIT.
  • msbdata.nas: Move strategyentry elsewhere to collect padding.
  • code.asm: Move an xchg instruction into DOSCODE to save a byte of DOSENTRY.
  • Add AMIS entry and related data to DOSENTRY. The int 2Dh entry comes with a full standard IISP header, and a renumber-compatible comparison to a multiplex number, chaining with a far indirect jump to the downlink. This downlink is initialised to point to entry_iret, but being fully functional it is valid for other applications to patch this downlink to point elsewhere. The AMIS interrupt list (only listing int 2Dh) must live in the same CS as the IISP header. The AMIS signatures could live elsewhere but for compatibility I put them into DOSENTRY too. (All of them are addressed using segment 26h.)
  • Implement a basic AMIS multiplexer, code located in DOSCODE. Functions 0, 4, and 10h. (Not compliant because function 2 is missing, and function 4 only lists the int 2Dh entrypoint without the terminal DOS interrupt handlers.)
  • Move ldos_getnum into SYSINIT segment. This required putting a far function that calls this function near into a different file, as NASM's call far didn't seem to work correctly when both the call and the destination were in the same object file.
  • Add AMIS function 11h, check id. Only id entered yet is for the sharer.
  • Optimise checkid to compare the length and text using a single repeated string comparison instruction.
  • Add the dependency on msgserv.nas for sharesr.obj in the makefiles.
  • Introduce the new expected DOS version (5.38) to the versiona.mac file.
  • Add check_amis function to the sharer. If DOS version is returned as v5.26 and the multiplexer isn't found, accept. If it is returned as v5.26 and the multiplexer is found but function 11h isn't supported (returns al = 00h), accept. If the version is returned as v5.26 and the function 11h is supported, check the function return. If the version is returned as v5.38, the multiplexer must be found, the function 11h must be supported, and the function must return that the id is supported.

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.

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.

lDebug

Discussion

E. C. MaslochE. C. Masloch, 2025-08-30 23:39:33 +0200 Aug Sat

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=3392949

E. C. MaslochE. C. Masloch, 2025-08-30 23:56:41 +0200 Aug Sat

Bug was introduced into the v2.16 series on 2022-12-07 and fixed on 2023-10-17.

You could leave a comment if you were logged in.
blog/pushbx/2025/0830_a_variety_of_progress.txt · Last modified: 2025-08-30 17:34:53 +0200 Aug Sat by ecm