The versions 0.9.4 - 0.9.8 of 8088_bios [1] seem to be affected by a bug I described in an GitHub issue [2]. It causes DS:0041 to be overwritten by the BIOS. Problem is, that DS points to whatever it is set when entering the BIOS and not to the BIOS data area. The bug is that the BIOS fails to set DS if it encounteres an unsupported function request. It sets DS correctly for supported functions.
In the case of Free FDISK, this behaviour trashes INT 10 vector. This is because FDISK uses the intr() function of the Watcom libc, and setting the segment values (DS, ES) of the REGPACK structure to zero before invoking intr(). This is recommended by the Watcom documentation to prevent loading of garbage segment selectors if running in protected mode [4]. Not exactly sure to what segment DS is set when the kernel calls INT 13. 0.9.4 seems to be the original version of the Book8088. The problem can be worked around by never calling any unsupported INT 13 function. For the FreeDOS kernel, this can be achieved by disabling LBA support. For example with the sys command: SYS CONFIG GLOBALENABLELBASUPPORT=0 For Free FDISK, this can theoretically be achieved by invoking as FDISK /X, where /X disalbles LBA support. However, for versions <= 1.3.13 INT13,41 is also called if invoked via /X, so the bug is triggered [3]. I prepare a FDISK update which disables calling INT13,41 if the user requests CHS only access. [1] https://github.com/skiselev/8088_bios [2] https://github.com/skiselev/8088_bios/issues/62 [3] https://github.com/FDOS/fdisk/issues/80 [4] https://open-watcom.github.io/open-watcom-v2-wikidocs/clib.html#intr > Am 05.02.2024 um 10:40 schrieb Eric Auer via Freedos-devel > <freedos-devel@lists.sourceforge.net>: > > > Hi Jim, > >>> http://www.bttr-software.de/forum/board_entry.php?id=21061 ... > > By now, the BTTR thread has figured out that the bug was > in the Xi8088 BIOS, not in XT-IDE: When calling unsupported > (bei neither XT-IDE nor the main BIOS) disk functions, the > main BIOS trashed the int10 vector. A fixed update exists, > as far as I understand the ongoing discussion :-) > > Eric > > > > > _______________________________________________ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
