Am 14.07.2026 um 18:40 hat Christian Quante geschrieben:
> From: PC-DOS repro <[email protected]>
>
> Kevin, thank you -- that was a far closer read than I expected for a floppy
> patch, and all three points were right.
>
> 1/2 The SET_CUR_DRV() omission you spotted. It is real: every other
> handler latches the drive from fifo[1], READ ID does not, so it
> answers about whichever drive was selected last. A DOR write
> normally selects the drive as a side effect, which is why nobody
> has tripped over it. It goes first because 2/2 checks the medium
> of exactly that drive.
>
> 2/2 The main change, now with the fd_seek() return code you suggested
> instead of a second blk_is_inserted() in the caller. Nothing made
> it harder than it looked -- but it does drag fdctrl_format_sector()
> along, because a new return value would otherwise fall through its
> "default" and let FORMAT TRACK carry on as if nothing happened. So
> FORMAT on an empty drive now answers ST1.MA as well. I could not
> get a guest to reach that path: DOS gives up during media sensing
> and never issues the command, and a hand-written FORMAT TRACK needs
> the per-sector data phase to get there at all. It is the right
> answer semantically, but it is untested on a guest, and I would
> rather say so than bury it.
>
> The test comment is fixed too -- it claimed the preceding tests
> leave the drive empty, which is exactly the dependency you object
> to. The two tests now stand on their own; the wider ordering
> problem in fdc-test I left alone, as you asked.
If you feel like addressing the wider ordering problem in the tests,
too, you're welcome to do so. I just didn't feel it was fair to require
you to clean up unrelated existing code before I would merge your fix.
> Measured, empty 1.44M drive, INT 13h AH=02h on A: (SeaBIOS 1.17.0):
>
> before 0.11 s, AH = 0x20 (controller failure)
> after 0.21 s, AH = 0xC0 (no media)
>
> The extra 0.1 s is SeaBIOS working through the data rates now that READ ID
> no longer succeeds on the first try. Booting from a hard disk is unchanged
> -- the drive is not touched at all -- and no guest changes what it shows:
> DOS shows the same message for 0x20 as for 0xC0, and Windows 3.11 and
> OS/2 2.11 show exactly what they showed before.
>
> A SeaBIOS series is on its list [1] that probes the disk change line before
> media sensing; with it, the same read takes 0.11 s and answers 0x80 ("not
> ready"), which DOS and Windows both render correctly. The two are
> independent -- neither waits for the other.
>
> [1]
> https://mail.coreboot.org/archives/list/[email protected]/thread/K2QGADPOTAEEZRQS5T6PKZLDQUBO62HY/
>
> Christian Quante (2):
> hw/block/fdc: select the drive named by the READ ID command
> hw/block/fdc: report a missing address mark on an empty drive
Thanks, applied to the block branch (though I took the liberty to add
the new return value 5 to the fd_seek() comment while applying it).
Just in case it might be useful to know for you another time, I'd like
to mention that the convention for QEMU mailing lists is that new patch
versions are posted as new top-level threads because they won't be
missed as easily then. But not a problem for this one.
Kevin
