FreeDOS kernel - implements the core MS-DOS/PC-DOS (R) compatible operating system. It is derived from Pat Villani's DOS-C kernel and released under the GPL v2 or later. Please see http://www.freedos.org/ for more details about the FreeDOS (TM) Project.
The ISFAT32 macro seems to be involved, which tests dpb_fatsize for zero.The INT25/26 calls eventually succeed after querying the DPB via INT21,32 (after the DPB is rebuilt?!?), leading to the assumption that the dpb is not fully initialized after system boot (at least dpb_fatsize is likely zero, so ISFAT32 triggers erroneously).
This is originally from Willi Spiegl, noticing that he could not format a 500MB primary on the second disk with T2403, but the bug is likely to be older.
Minimal assembler example to verify 0x0207 is returned:
.model small
.stack 512
.data?
read_buf db 512 dup(?)
.data
sect_num dd 0
count dw 1
buf_off dw offset read_buf
buf_seg dw seg read_buf
.code
.startup
mov al,3 ; drive D:
mov bx,offset sect_num
mov cx,0ffffh
int 25h ; read from it
int 3 ; and bail out to lDebug
end
Kernel returns 0x0207 in AX if INT 25/26 is called on an uninitialized FAT-16 partition, making format.exe fail to format a FAT-16 partition (see screenshots, formatting a 500MB FAT-16). This is at least for kernel versions 2043-master. Partition table is good. Error value suggests INT25/26 gives up at the following lines: https://github.com/FDOS/kernel/blob/8552d833bbca657591fa8e6f7276d307d7d0c7c6/kernel/inthndlr.c#L1835-L1840
The ISFAT32 macro seems to be involved, which tests dpb_fatsize for zero.The INT25/26 calls eventually succeed after querying the DPB via INT21,32 (after the DPB is rebuilt?!?), leading to the assumption that the dpb is not fully initialized after system boot (at least dpb_fatsize is likely zero, so ISFAT32 triggers erroneously).
This is originally from Willi Spiegl, noticing that he could not format a 500MB primary on the second disk with T2403, but the bug is likely to be older.
Minimal assembler example to verify 0x0207 is returned: