Jack, kernel people (now CCed),
When DOS detects an unreliable floppy change line hardware,
it should use the floppy label / serial / similar to detect
changes in software ...
How does DOS ever detect that any hardware is unreliable??
I do not know, but earlier in this thread, somebody said that
the numbering of FAT filesystem exists, among other reasons,
to help DOS detect floppy changes even if there is no change
line available. As you know, int 13.15 can even report that
a floppy has no change line at all. MS DOS might, on top of
that, have a list of BIOS versions with weak change lines?
Related kernel sources: init_readdasd, make_ddt, maybe also
DosDefinePartition. Apparently FreeDOS has drive types hard-
disk, floppy with change line, and other here...
Int 13.16 which actually queries the change line can return
invalid command, drive not ready / not present, no change or
change line active or not supported. NOTE that calling the
check also clears the status, so only ONE caller will notice
each change and only ONCE! Lbacache takes special care here.
Related kernel sources: FL_DISKCHANGED, fl_diskchanged,
floppy_change, mediachk, diskchange... If you have NO change
line, diskchange returns not changed if you very recently
accessed the disk, and unknown otherwise, I believe?) For
M_DONT_KNOW, mediachk returns disk changed iff the serial
of the filesystem changed compared to the current DDT info.
Finally, media_check is described to trigger on unknown,
changed or definitely changed. It does setinvld and calls
the D_BLDBPB block device driver function and converts the
BPB to DPB then. Note that int 21.7302 get ext dpb calls
flush_buffers, flags a fake disk change, calls media_check.
DosGetFree can behave similarily depending on arguments...
Maybe update_dcb is also related. I think D_BLDBPB is done
by rqblockio and the bldbpb function and getbpb, which also
calls RWzero to re-read the boot sector?
As you see, a very long chain of events exists around all
DOS block device related things, but that is necessary to
be fully compatible with MS DOS... You also see that I did
NOT mention calls to int 13.0 disk reset here - I have not
seen any (apart from fl_reset / FL_RESET calls in reaction
to I/O errors deeper in the RWzero chained LBA_Transfer).
I agree that it is nice to disable floppy caches, but maybe
the kernel actually does something detectable in REACTION to
detecting a floppy change? For example it might issue an Int
13h drive reset command which in turn can be caught by the
UIDE2 driver and treated as a flush cache for THAT drive
event? ...
What do you mean maybe?? You and others are the kernel
experts for FreeDOS, not me, as I still run V6.22 MS-DOS!!
As you see above, handling of floppies and their changes is
a complicated thing which is not easy to walk through, even
for me :-)
Also, I say again that I am NOT interested in any specific
logic from the MS-DOS kernel, or the FreeDOS kernel, or in
fact ANY kernel, for detecting diskette changes. My worry
is that such logic may NOT be generic, and I want...
As far as I can tell, you could make int 13.0 (disk reset)
and reads of the boot sector flush events. That might flush
a bit more often than necessary, but at least not LESS often
than necessary, assuming that you ALSO trap int 13.16 return
values already and trigger flushes when you see change line
activity :-)
UIDE2 to run on all DOS systems. Checking the BIOS media-
change status has always worked in my drivers for diskettes
See above - if you ACTIVELY call int 13.16, you could hide
the floppy change from DOS because int 13.16 returns changed
status only for the first call after a disk change even with
working change lines...
Finally, as noted before in this forum, UIDE and UIDE2 make
NO run-time DOS system calls and I also want to keep THAT
I agree that it is good to not call DOS in a DISK cache and
actually it should not be necessary to call DOS either :-)
Note that things might be different for block device based
caches instead of BIOS / hardware based caches like ours...
By the way, any chance to work around the VirtualBox
huge-delay problem?
Not without knowing WHY they take such a huge delay! In any
case, UIDE and UIDE2 must scan for PCI-bus devices...
If I understand your code correctly, you scan all 256 bus,
32 device and 8 function locations which can be expressed,
using the BIOS. You could save a lot of time by scanning
only those bus numbers that are used and not scanning sub
functions for devices that are installed at all. It also
is a lot faster to use mechanism #1 port I/O and not call
the BIOS for each access, but you might be using the BIOS
deliberately to also support ancient mechanism #2 boards?
If the VirtualBox people cannot fix the huge delay...
I think UIDE2 now takes 2-3 minutes on VirtualBox when
that uses a virtual PIIX3 chipset, so if you really do
a scan of all locations, scanning only those locations
where a
