Table of Contents
Late October: Comments on lDOS boot iniload
2025-11-01
lDOS boot experimental
- Drop references to end2 + 512 (this is no longer relevant as the late multi/progress inits now use a comparison to end3 rather than depending on two sectors being read).
- Drop a comment on multi_sector_read changing si. It does, but we no longer need to preserve si as it isn't used to cache the currently loaded FAT sector any longer.
- Comment on a subtraction in new cluster code of multi-sector loader, noting that the resulting di is nonzero.
- Expand comments on multi_sector_read, including the protocol comment.
- Name the ldHasLBA flags as ldhlfLBA and ldhlfForceSingleSector. Preparation for adding more flags.
- Update comments on multi_sector_read and multi_sector_read_lba.
- Optimisation (not just comments): Push si earlier in multi_sector_read, sharing this instruction for CHS and LBA readers.
- Drop obsolete comment left over from read_sector in multi_sector_read_lba.
- Optimisation: Do not set bx again in multi_sector_read_lba, just push es instead.
- Optimisation: In multi-sector LBA reader, set cl to set up cx as the retry counter. ch is already zero at this point.
- Clarify the warning message for end3 overflowing the expected end3 at 4096 bytes (4 KiB) into the file.
- ETA: Expand yet more comments, including some protocol comments.
Musings on a new program
I'm considering a new kernel program that would allow to install resident programs at the top of the Low Memory Area, to then chain to a different kernel. This could re-use parts of the "FreeDOS" (actually any kernel) loader in lDebug, and maybe even the line I/O of lDebug. Importantly, it would run at the bottom of the LMA, perhaps at segment 60h. To load a kernel it could relocate its code to stay within the top 20 KiB of the available LMA (after any resident programs installed), within the LMA top reservation.
This could make use of the incoming FAT buffer from iniload. (This would require clear semantics for passing the FAT buffer and its contents.) Before the final load, relocate the FAT buffer down to lower than the top reservation to pass it to the chained kernel.
A new executable format could be loaded by this program, with memory above a certain segment all available.
A remaining question is how much of the debugger to include, such as script file reading, serial I/O, the expression evaluator, or even Extensions for lDebug (either a subset or more fully).
Perhaps the debugger itself could be loaded by this program?
Some more possible use cases:
- Program which depicts int 13h unit 01h (drive B:) as present and not ready. For ETHFLOP.
- Program that retries int 13h read accesses (function 02h or 42h) to make FreeDOS boot loaders succeed where they would otherwise fail.
