From: PC-DOS repro <chrischaan66@googlemail.com>
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.
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/seabios@seabios.org/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
hw/block/fdc.c | 54 +++++++++++++++++++++++++++-----
tests/qtest/fdc-test.c | 70 +++++++++++++++++++++++++++++++++++++-----
2 files changed, 109 insertions(+), 15 deletions(-)
--
2.53.0