You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
During my work on Enhanced DR-DOS's early boot stages I noticed that the EDR-DOS-specific load protocol expects the ROM-BIOS (int 13h) load unit in DL whereas FreeDOS load expects it in BL.
Studying the sources of the patched FreeDOS SYS delivered as EDR-DOS SYS v3.5 (source archive mirrored here), including their boot sector loaders, I found that the two different FAT32 loaders both were patched to set DL, instead of setting BL.
(The common part of the FreeDOS and EDR-DOS boot sector loader for FAT12/FAT16 sets both registers, exempting it from this bug.)
The upshot is that when installing a FAT32 boot sector loader using the FreeDOS SYS build and using the /OEM:EDR switch the loader will still set BL and generally not set DL correctly, breaking the load protocol expected by the older EDR-DOS kernels (corresponding to my 2023 August revision and earlier).
The same is true inversely: Installing a FAT32 loader using the EDR-DOS SYS build and using the /OEM:FD switch will lead to the loader not correctly setting BL.
This problem does not affect the lDOS iniload or lDOS drload stages as these never use the load unit passed in a register, opting to read it from the boot sector's BPB New field for the load unit instead. The 2023 December build of my EDR-DOS repo uses one of these lDOS stages as the first stage after the sector loader so they aren't affected by being loaded with the wrong load unit register.
SYS doesn't track which load unit register to use (for the FAT32 FreeDOS-native loaders):
test al,al ; test the boot drive
jz floppy_boot ; skip if floppy boot
mov al,2 ; it's drive C:
floppy_boot:
mov init_drv,al ; set boot drive
FAT32 isn't usually used on diskettes. So any nonzero value in DL will lead to setting the drive C: as the boot drive, only the value zero would unexpectedly set drive A: instead.
During my work on Enhanced DR-DOS's early boot stages I noticed that the EDR-DOS-specific load protocol expects the ROM-BIOS (int 13h) load unit in DL whereas FreeDOS load expects it in BL.
Studying the sources of the patched FreeDOS SYS delivered as EDR-DOS SYS v3.5 (source archive mirrored here), including their boot sector loaders, I found that the two different FAT32 loaders both were patched to set DL, instead of setting BL.
(The common part of the FreeDOS and EDR-DOS boot sector loader for FAT12/FAT16 sets both registers, exempting it from this bug.)
The upshot is that when installing a FAT32 boot sector loader using the FreeDOS SYS build and using the
/OEM:EDR
switch the loader will still set BL and generally not set DL correctly, breaking the load protocol expected by the older EDR-DOS kernels (corresponding to my 2023 August revision and earlier).The same is true inversely: Installing a FAT32 loader using the EDR-DOS SYS build and using the
/OEM:FD
switch will lead to the loader not correctly setting BL.This problem does not affect the lDOS iniload or lDOS drload stages as these never use the load unit passed in a register, opting to read it from the boot sector's BPB New field for the load unit instead. The 2023 December build of my EDR-DOS repo uses one of these lDOS stages as the first stage after the sector loader so they aren't affected by being loaded with the wrong load unit register.
SYS doesn't track which load unit register to use (for the FAT32 FreeDOS-native loaders):
kernel/sys/sys.c
Line 424 in db71b1a
The FreeDOS-native FAT12/FAT16 loaders set both registers:
kernel/boot/boot.asm
Line 359 in db71b1a
The FAT32 CHS 8086 loader sets BL only, patched for EDR SYS to DL only:
kernel/boot/boot32.asm
Line 272 in db71b1a
Same for the FAT32 LBA 386 loader:
kernel/boot/boot32lb.asm
Line 245 in db71b1a
The text was updated successfully, but these errors were encountered: