Hello,
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 OS/2 Museum¹:
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.
Regards, —f
⁰: https://github.com/qemu/qemu/blob/eea8f5df4ecc607d64f091b8d916fcc11a697541/hw/block/fdc.c#L112-L163 ¹: http://www.os2museum.com/wp/the-xdf-diskette-format/