Copied from my mail to the freedos-devel list.

On at 2024-06-02 19:45 +0200, E. C. Masloch wrote:

On at 2024-06-02 13:31 +0200, Bernd Böckmann via Freedos-devel wrote:

[…]

Thinking of this LBA, non-LBA thing we might investigate if it is possible to merge the LBA and non-LBA FAT32 VBR code into one. But that is for another topic. We also might replace the loaders with some other one. If I remember correctly ECMs lDOS loaders have the capability…

As we say, speak the devil's name and here she is!

I prepared an overview of the lDOS FAT32 + FSIBOOT4 loaders on my blog: https://pushbx.org/ecm/dokuwiki/blog/pushbx/2024/0602_barely_any_work_in_the_may_june_week#ldos_fat32_boot_sector_loader_for_freedos

Comments and additional questions are welcome both in this thread or in the comment thread of the blog.

Not listed in the article is the lDOS boot.asm (FAT12/FAT16) loader. This one also supports the _COMPAT_FREEDOS set but it requires disabling some of the loader's features to make the relocation code fit in the allowed space. That is why I mention in the article that none of the loader's features need to be disabled to use _COMPAT_FREEDOS for my boot32.asm as a consequence of the two-stage approach.

As usual, my code is FLOSS and in the case of lDOS boot + instsect + lmacros it builds with only NASM (a recent-ish version of the assembler may be required).

I recently updated my lDOS boot repository, only uploaded in an "experimental" location for now. Here's the current filelog of boot32.asm. The update uses the experimental identifier FSIBEX04 for now, but it will transition to FSIBOOT5 and be uploaded into the non-experimental repo once I'm satisfied with the update.

What this does is basically stuff a new handler into the FSIBOOT stage, filling it entirely (0 bytes unused), which aids the first stage loader if it wants to find the size of the usable Low Memory Area. This is required for the _COMPAT_FREEDOS set as implemented so far. Technically a first stage that expects an FSIBOOT4 stage would also work with the FSIBOOT5 stage. The FSIBOOT4-expecting first stage could be patched to accept an FSIBOOT5 stage instead. However, I decided the protocol revision should be incremented to insure that the new entrypoint is present.

(Present doesn't necessarily mean supported; the first stage loader that expects to use one of the new FSIBOOT5 entrypoints is ready to handle no-op functions that are made of only of a "retn" instruction. The second new entrypoint for now is such a no-op function, reserved for future extensions.)

With the space saved in the first stage, this allows to enable the proper LBA check (int 13.41) as well as the Xi8088 ROM-BIOS bug workaround (setting DS = 40h) (FreeDOS kernel issue, BTTR Software forum entry) for that check by default. So it follows the "go everywhere, do everything" mantra for lDOS-related programs: 8086-clean, (33-bit) LBA with the proper check and workaround or fallback to CHS, full support for what I assume as the FreeDOS load protocol, detects CHS geometry using int 13.08, and it detects hidden sectors passed by an MBR loader in a partition table entry. The LBA, query geometry, and partition info support can be patched out by the lDOS instsect program as before, using /L NONE, /Q NONE, or /P NONE. The proper installation of a two-stage FAT32 boot sector loader with an FSIBOOT stage is implemented in the instsect program as well. This could be adapted as an option for FreeDOS SYS if desired.

Regards,
ecm