Eric, > I have not yet seen a desktop BIOS which implements this, alas [disk > spin-down timeouts, etc.]. I do have an adware DOS tool for it, > showing a splash screen for a BBS or similar when you run it and of > course bigger than needed, but free.
Desktop BIOS routines are usually not-interested in saving power thru spin-down timeouts or other such "tricks". Laptop BIOS routines ARE interested, since their power is limited when using batteries. Thus it is mainly laptops we address here, and their BIOS routines DO have the needed hard-disk logic. >> Actually, UIDE has NOT changed any disk-configuration settings by >> the BIOS since late 2005, when I "got into TROUBLE" doing so with >> some BIOS programs! UIDE now only "reads" I-O and DMA addresses > > Interesting, but which trouble did which setting cause? With a few BIOS routines back in 2005 (maybe obsolete, now), setting any UltraDMA mode OTHER than what the BIOS set did not work! To be safe, I got RID of such mode-set logic in my drivers, back then. >> Any hard-disk function but 2/3/42/43 (reads and writes) is "passed" >> to the BIOS, so function 0 would not be so timed-out by UIDE. Nor >> would UIDE ever declare a "timeout" ... > > Why not? There is an error code (0x80) defined for that in int 0x13. Note in my drivers' UltraDMA "DoIO" subroutine, it is always waiting for either controller/drive ready or DMA end. If those "events" do not occur, hard to tell if the controller/disk has failed or if they just "took too long". I have assumed a disk will finish I-O in at most 400 msec, and if not, it was a hardware failure, not a timeout. So, I have never used BIOS code 080h. Same "situation" even if the "DoIO" timeout becomes 7 seconds, to handle disk spin-up. No way I can know if the hardware failed, so I doubt I can use code 080h. >> If DOS does 5 retries, as you indicate, this would cost the user a >> maximum of 35 seconds (my 7 seconds * 5 tries) and thus is NOT any >> sort of an indefinite "hang"! > > What I meant is that when the disk is in a state where only a reset > can make it continue, the driver will wait 7 seconds. If it is in a > state where nothing will make it continue (e.g. un-hotplugged it?), > DOS will take 35 seconds until it displays an error message. In the > 7 second case, the user will in the worst case see a delay of 7 sec > plus the time needed to spin up, but more likely only the always- > present delay caused by the time needed to spin up. Understood, if in fact DOS issues a drive-reset on any error. Also, note that my drivers do NOT allow "removable" or "hot-pluggable" HARD disks, since I cannot be sure all DOS kernels can handle media-change "events" in their HARD-disk logic! Jack R. Ellis ------------------------------------------------------------------------------ Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
