Eric, > 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 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!! 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 UIDE or UIDE2 to run on all DOS systems. Checking the BIOS media- change status has always worked in my drivers for diskettes (despite Bertho's worries about "flaky" change lines!), and so I will leave my drivers that way. Finally, as noted before in this forum, UIDE and UIDE2 make NO run-time DOS "system calls" and I also want to keep THAT "generic" feature in my drivers, as well! >>> -- UIDE2 has only 16 spare bytes before it goes back over a 7K >>> .SYS file! But, I shall find a way! > > Thanks :-) 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, so they can "relate" the PCI device-addresses to the addresses posted via Int 48h requests. That way, I know the UltraDMA address to use for every controller, since UltraDMA addresses are NOT part of Int 48h -- BAD error by the EDD BIOS people, in 1995! If the "VirtualBox" people cannot fix the huge delay in their PIIX3 logic, UIDE or UIDE2 still have their /E switch and can still do disk caching, after the BIOS handles disk I-O. > If you prefer the BIOS way, would int 1a.b103 be an option? It > scans by PCI class so you do not have to loop over bus/device. My drivers are ALREADY doing a PCI scan by class-code, so the huge-delay problem is not related to this. > Note that for example PCISLEEP only uses raw I/O in getpci and > skips looping over functions if function 0 of a bus and device > number pair return "PCI ID -1". So you scan only 1 out of 8 in > such cases. Each bus has 32 device numbers to scan. Also, often > you have far less than 256 bus numbers in use, saves much time. Doesn't matter. A scan for devices by PCI class-code returns only devices that match the requested class/subclass/function, so I lose no time by checking unnecessary busses/devices. In any case, no one has ever complained about the speed of UIDE's or UIDE2's initialzation, except when running "VirtualBox"! Also, better if you refer to "UIDE" in general, since UIDE and UIDE2 assemble from the same UIDE.ASM source and do nearly all the same initialization functions. A few differences re: how they allocate XMS memory and where they load, but their device scanning and setup is 100% the same. Jack R. Ellis ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
