I described this problem in some detail in a blog post: https://pushbx.org/ecm/dokuwiki/blog/pushbx/2024/0204_various_freedos_boot_sector_loaders_memory_overlap_cases
Basically, the FAT sector at segment 2000h overlaps with part of the load file data if the file (rounded up to cluster size) exceeds 126.5 KiB. This is defined here in the CHS FAT32 loader:
Either the file data will overwrite the saved FAT sector, or a newly-read FAT sector will overwrite the file data. On drives with 128 KiB/cluster, the latter is more likely as the root scan is unlikely to read a second cluster. And if this happens and the actual file data is less than 126.5 KiB, then this bug is benign, the load will appear to just work. This explains why I didn't notice this bug before when I introduced support for 256 sectors/cluster to the loaders.
My suggestion is to change the FAT buffer to reside at segment 2200h:0 (linear 22000h, 136 KiB) instead, which allows to use /L load segments from 60h to 200h without the overlap occurring. The blog post also discusses how higher /L parameters to the FAT12/FAT16 loader may also cause an overlap; the solution is similarly to move up the cluster list to segmented 1FE0h:2200h (happens to also be linear 22000h, 136 KiB). I will prepare a Pull Request for these changes (and the corresponding updates to the memory layout maps) soon.
I described this problem in some detail in a blog post: https://pushbx.org/ecm/dokuwiki/blog/pushbx/2024/0204_various_freedos_boot_sector_loaders_memory_overlap_cases
Basically, the FAT sector at segment 2000h overlaps with part of the load file data if the file (rounded up to cluster size) exceeds 126.5 KiB. This is defined here in the CHS FAT32 loader:
kernel/boot/boot32.asm
Line 69 in 431be02
Either the file data will overwrite the saved FAT sector, or a newly-read FAT sector will overwrite the file data. On drives with 128 KiB/cluster, the latter is more likely as the root scan is unlikely to read a second cluster. And if this happens and the actual file data is less than 126.5 KiB, then this bug is benign, the load will appear to just work. This explains why I didn't notice this bug before when I introduced support for 256 sectors/cluster to the loaders.
My suggestion is to change the FAT buffer to reside at segment 2200h:0 (linear 22000h, 136 KiB) instead, which allows to use /L load segments from 60h to 200h without the overlap occurring. The blog post also discusses how higher /L parameters to the FAT12/FAT16 loader may also cause an overlap; the solution is similarly to move up the cluster list to segmented 1FE0h:2200h (happens to also be linear 22000h, 136 KiB). I will prepare a Pull Request for these changes (and the corresponding updates to the memory layout maps) soon.