> The rest of the "Extended BIOS Parameter Block" looks like it isn't relevant data, like the volume label or the volume's serial number
No, that's the exact reason why OS/2 checks the OEM ID. The volume label was initially used to detect disk swaps (so that if an application has open files on disk 1, it does not destroy data on disk 2 by writes after the user replaces the floppy in the drive, which could not be detected in hardware until much later, and even then not unless you were using a Mac, basically).
Of course, the volume label is user-set (so duplicates are possible), and more often not set than meaningful in any case. So, DOS 3.3 added the (unique-at-format-time) volume serial number. Which was always all-zeroes (or garbage) on pre-3.3 disks, hence the need for the OEM ID check.
Does that mean it needs to seek to and from the volume label/volume info blocks for every single read or write?
It sounds like that would kill performance, at a time when you needed all the performance you could get. I suppose it could be amortized, something like only check the volume headers if it has been more than 10 seconds since the last read/write.
user name checks out ;-)
thanks for sharing this knowledge.
Doesn't mention what hypervisor is used (qemu? bochs?) but if it speaks NBD then you can do:
$ nbdkit floppy /path/to/some/directory
It doesn't use mkfs.fat, instead a custom FAT generator, and I think people have used it with ancient guests (however I'd have to check to be sure, either way should be easy to patch).
Does nbdkit generate the correct OEM Label value? I don't believe so.
I thought someone had sent me a fix for this in the distant past, but I can't find the "MSDOSxxx" label in the source. However the custom generator should be easy to fix:
https://gitlab.com/nbdkit/nbdkit/-/blob/a2fe619c45a97fd89063...
However one definite restriction is it only serves FAT32 (not FAT16), which would be a dealbreaker for really old guests like this.
OS/2 2.1 (1993) cannot support FAT32 (1996) as it predates it.
maximum control over your DOS filesystems: Create the boot sector with nasm and have mformat -B (from mtools) fill in the disk geometry.
For devices with CHS addressing, information in the BPB is crucial for getting the CHS geometry. It has to match how the medium was formatted.
mkfs.vfat -F 16. Also a FreeDOS boot disk could work too, with Qemu.
Did you read the article?
Yes; and Qemu with FreeDOS with fdisk+format might first most of the issues.
How did you read the article and still suggest this?
Are you actually suggesting to script launching qemu to run a freedos image to run fdisk within that to generate arbitrary dos disk images on the fly? Just to output a few bytes different?
The entire job, once understood, is barely an echo command in bash.