2025-11-09

• Document tsc.eld in the manual.
• quiet.asm: Drop unused msg.org left over from aformat.asm
• Document quiet.eld in the manual.
• reserve.asm: Drop the separator spam.
• Document reserve.eld in the manual.
• Document kcmdline.eld in the manual.
• Bugfix: In rr.asm, make sure to call prephack before dohack. Would crash after an early R WORD [...] = value command then pressing Control-C to the debugger terminal, as unhack would restore all-zeroes into the int 23h vector.
• Update news-r10:
  • Init crash when loaded as DEVICE= on MS-DOS v5.
  • JP signature for bootloading MS-DOS v7.
  • Optimise to cache FAT sector during seek.
  • Optimise to have ELDs provide a 512-byte sector buffer.
  • rr.asm crash after Control-C due to missing prephack call.

In December the last release, r9, will become one year old (2024-12-21). So it is about time to prepare release 10.

I do want to include the lDOS boot experimental updates in the new debugger release, which implies adding them to the non-experimental lDOS boot repo. With the updated testing scripts I am now fairly sure that the experimental revisions are ready, but I haven't committed to them yet.

This includes the lDOS boot32.asm FSIBOOT5a revision. Unlike FSIBOOT4 to FSIBOOT5, the new revision is compatible either way with the prior. This is because the FSIBOOT5 first stage preserves si:di, but never uses it on its own, so it is safe for the second (FSIBOOT) stage to never set these registers and always use the lsvFATSector variable.

I am happy that all non-test Extensions for lDebug seem to be documented in the manual now. Some polish to these sections could still be useful.

I wrote about this in its own post. Basically, all daily build zipballs were unpacked, then the entirety of them were repacked into one lzipped tarball, compressed solidly. I sorted the files according to their basenames to make them cheaper to compress.

To access any of the builds that were not the most-recent one as of today, the tarball needs to be downloaded (2.1 GB) and the relevant files unpacked. In a test run, extracting a single file took as long as 8 minutes, albeit this time won't be linear to the amount of files specified.

The whole idea of this was to save space on the server. It comes out as saving about 20 GB, due to:

• Compressing solidly (better),
• Compressing using LZMA (better),
• And compressing all build revisions together (better!).