Not so long ago, I have stumbled upon some rather disappointing
behaviour in the SeaBIOS floppy driver. After some investigations, I
concluded it would in fact be worthy of a bug report. So here it is.
The problem is that when SeaBIOS starts, it looks up the type of the
floppy drive in firmware configuration variables and internally stores
a maximum disk geometry corresponding to the type of the drive. This
geometry is later used to validate interrupt 0x13 requests and
internally convert them to use LBA sector numbers, which are later
converted back into CHS when communicating with the floppy controller.
This design – apart from being somewhat silly in itself, with the
shoehorned CHS-to-LBA-to-CHS conversion – prevents using SeaBIOS’s
interrupt 0x13 service with superformatted floppies, i.e. those with
geometries larger than typical for the initially detected drive type,
even if the drive itself could handle such floppies without problems.
Originally I ran into this problem in a VM setting, as I wanted to
create and use larger-than-usual floppy images (without ever actually
writing them to physical media); in QEMU source code, I noticed a table
of geometries⁰ that are matched against floppy image sizes so that
QEMU knows which geometry to present via the virtual floppy controller.
The largest image size that is transparently handled by QEMU is 3840
KiB, corresponding to a geometry 48 sectors per track × 80 tracks × 2
sides in a ‘2880 KiB’ drive. SeaBIOS will however refuse to access
sectors beyond the 36th (on whichever track), no matter what I do. And
unless I remember to configure the floppy drive to use the ‘2880
KiB’ type, I am unable to access even DMF disk images (21 sect/trk ×
80 trk × 2 sides) that are apparently supposed to be readable in
‘1440 KiB’ drives.
So I would like to ask that for floppy drives, the interrupt 0x13
service should skip geometry validation and the back-and-forth address
conversion, and pass the CHS coordinates unmodified to the floppy
controller. As I have no idea how this change would impact real
hardware (I have read some reports that superformatted floppies were
less reliable than normal ones and sometimes even damaged the drive), I
am not asking that validation be disabled on bare metal (!CONFIG_QEMU),
although I suppose it would be useful there as well.
For completeness though, I would also like to highlight XDF, which is a
superformat with a non-uniform sector size. With the appropriate
drivers installed, XDF disks are treated by the operating system as
relatively ordinary floppies with a virtual geometry of 23 sect/trk ×
80 trk × 2 sides × 512 B/sect. A virtual machine is usually able to
present this geometry directly via the floppy controller (since it
operates on flat disk images anyway), obviating the need for the
driver, so the abovementioned workaround should be enough for a VM. On
real hardware though, things are a little more complicated. Following
> Given XDF’s highly non-standard format, one might think that the
DOS-based XDF utilities needed to use direct FDC access. They did
not—instead, they showed just how far the standard floppy BIOS
services can be convinced to go.
> For formatting, the BIOS user supplies a buffer containing
per-sector parameters that the FDC then transfers during execution of
the FORMAT TRACK command. For reads and writes, XDF dynamically changed
the DPT (Diskette Parameter Table) and used the standard BIOS
read/write services to access one sector at a time.
I skimmed SeaBIOS floppy code, and apparently SeaBIOS only *sets* the
DPT once at boot time with parameters like the sector size hardcoded,
and later ignores it completely. Which means that if the XDF driver
operates as the blog post says, it is not going to work with SeaBIOS.
I imagine modifying the floppy driver to also take the DPT into account
would be much more involved, so I am not requesting that. (Not to
mention that I don’t even have the hardware to test.) But it sure
would be nice, so it’s probably worth being written down in a TODO
list somewhere. If there’s any.
SeaBIOS mailing list -- email@example.com
To unsubscribe send an email to seabios-le...@seabios.org