Re: [Freedos-user] if not exist MD XXX
Hey, if not exist mydir/nul md mydir Doesn't work on XP (I think?), but that's the typical DOS way. This kept bothering me for some reason, so I checked now. It appears to work just fine on MSW NT command lines, executing the command after if not exist dir\nul if and only if that directory doesn't exist. In NTVDM, it does work as well (only?) using the COMMAND.COM supplied with NT; however, with other COMMAND.COMs (including FreeCOM) it indeed doesn't work: device names (such as NUL and CON) apparently aren't found. So while checking for a directory's existence with this method might work in non-DOS NT batch scripts, it can't be relied upon because the NTVDM's DOS interfaces appear not to find device names. Regards, Christian -- 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
[Freedos-user] UIDE vs drive power management spin down timers
Jack, [others: this is a bit long/technical, the summary is that it is both easy and safe to use shallow drive power management.] The problem is WHERE does UIDE or any other driver wait for a sleeping, i.e. stand-by hard disk to awaken again?? The ATA specs do not make this clear. Can UIDE simply issue a drive-select command to the disk and await ready for it? Or, does UIDE actually have to issue a seek or read, and then retry that command when first it fails?? As far as I remember, DOS always considers retrying the read. I seem to remember that MS DOS would crash by showing a non- useful variant of the critical error dialog if it runs out of retries, e.g. when using a TSR to make writes always fail, as opposed to failures which go away when retrying. If you can determine a reliable way for ALL disks to come out of stand-by mode, i.e. at what point UIDE should have a long time-out value, I can program that. But, it must be COMMON to all drives, NO exceptions, or it might cause just as much TROUBLE as it resolves! You can use FDAPM to spin down disks at once: It sends the raw command (e0, standby) for that to the first 4 disks when you select spin down and sends immediate idle (e1, idle) to wake up disks explicitly. However, the latter is not needed as the disk will automatically spin up when accessed again. BIOS, DOS (FreeDOS) and lbacache seem to have no problem with this but of course it would be better to first check the disk self-id, to only send those commands to drives which care for them. The I/O sequence for the primary controller is: out 0x1f6,0xa0 for master or b0 for slave (non-lba command here) wait (just a tiny bit) out 0x1f7,command (0xe0 standby/spin down - 0xe1 idle/spin up) wait (again) ... repeat for port 0x176 / 0x177 for secondary controller. Related commands: e6 suspend/sleep (you want to avoid this, as waking up would need a drive reset), e5 check power state (does not cause a wake up), ec read self-id (read port 0x1f0 many times to get 512 bytes of data as soon as drive ready?) and last but not least e3 set idle / spin-down timer :-) My notes say Seagate Barracuda use 8-12 Watts between idle and working-and-seeking while using 25 Watts for a few secs while spinning up, 1 Watt in standby and even less in sleep. The fact that I cannot grep standby-specific error handlers in lbacache probably means two things: Lbacache does not have to retry I/O itself, because DOS does that already and second neither DOS nor BIOS try to reset harddisks when I/O fails, nor does lbacache do that for them. I think if your disk is in sleep / suspend or even bus tri-state mode, it would be as if it is not really there at all and the BIOS would run in a bad timeout or similar as it just does not expect that case. In short: Please check whether fdapm spindown has adverse effects on anything in UIDE context and implement sending a 0xe3 set idle timer to X minutes UIDE command line option (where you convert X to a suitable byte of N*12 if N at most 20, otherwise X = 240 + round(N/30) with a maximum N = 330), at your choice either for sending the 0xe3 to all drives or only to certain drives based on a choice of the user or 3rd only to drives for which setting the idle timer is useful, based on checking the drive's self-id at UIDE driver start. To already answer some possible questions: CD/DVD drives do not seem to have problems with the immediate standby or immediate idle, but hdparm -I does not list anything on this topic for my DVD drive (only lists supported PIO / DMA modes) while the report for my harddisk is far more verbose: Queue depth: 32 Standby timer values: spec'd by Standard, no device specific minimum ... Recommended acoustic management value: 254, current value: 128 (this is about how fast and noisy seeks should be done etc) Supported features for the harddisk: SMART, Power Management, Write Cache, Look-Ahead, Automatic Acoustic Management, 48-bit LBA, Cache Flush, SMART Logging and SMART Self-Test, NCQ, 3Gb/s SATA, Host-initiated bus(?) (says interface) Power Management, (optional) Persistent Settings (preserve over reboot etc), various SMART SCT I/O and a number of other features. No power saving related features are reported for my CD/DVD drive and running smartctl -d ata -a for it for example just returns the model, support for ATA7, no SMART support. Trying with -d sat (SCSI to ATA layer, 16 byte variant) is even worse, the drive does not even give a model name then. As I am evil, I just sent -y standby, --idle-immediately as well as --idle-unload (also parks heads?) and -Y sleep to my CD/DVD drive via hdparm anyway. Drive reactions/symptoms: None that I noticed at all for --idle-*, a tiny delay for -y and a bigger delay together with a kernel log message saying that the SATA link got reset when I used the -Y command :-p Setting the idle timeout (hdparm -S) for my CD/DVD drive, which as mentioned claims to not support any
Re: [Freedos-user] Basic question on UIDE
Hi Cordata, All this talk about UIDE prompted me to investigate this tool. It looks interesting. How does the caching work for disk writes? I assume that when the cache is full the next sector read in will cause the oldest sector to be written out? Neither UIDE nor lbacache nor cdrcache will pool / delay writes, so writes always happen immediately unless the built-in write cache of your drive is used (many newer drives have one). You could use the DR-DOS NWCACHE for delayed / pooled writes. If you want to run some experiments about how much which NWCACHE setting helps, let me know so I can suggest some settings that I would be interested in :-). Is there any sort of a timer which will flush the cache to the hard drive periodically? How do you make sure that the RAM cache is written to the disk? My personal guess is that it would be safe to limit the amount of dirty (not yet written) cache data to ca 8-128 kB, which should already give quite noticeable speed improvements and flush pending writes after 0.3 to 2.5 seconds or at program exit or at (int 19) reset or when ctrl-alt-del is pressed, whichever happens first. As you know, DOS has no shutdown menu item so people just assume it is fine to switch off or hard reset the computer at any time, but are unlikely to do so exactly at the moment when they write to disk and are likely to first return to the prompt before switching off. As you can see, it is still relatively complex to check for all the suggested flush triggers and drives have their own cache anyway, so neither UIDE nor lbacache took the risk and effort to supply a delayed / pooled write scheme themselves... It would be interesting to have one for slow USB flash memory but then UIDE and lbacache do only cache BIOS int13 drives by default so you would want to cache more cdrcache style or use special DOS USB drivers which include or invoke caching explicitly. A modern BIOS will make USB sticks etc which are already present at boot visible as int13 disks but note that you cannot unplug/exchange drives while DOS is running then. Regards, Eric -- 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
Re: [Freedos-user] if not exist MD XXX
Hi Christian, if not exist mydir/nul md mydir Doesn't work on XP (I think?), but that's the typical DOS way. This kept bothering me for some reason, so I checked now. It appears to work just fine on MSW NT command lines, executing the command after if not exist dir\nul if and only if that directory doesn't exist. In NTVDM, it does work as well (only?) using the COMMAND.COM supplied with NT; however, with other COMMAND.COMs (including FreeCOM) it indeed doesn't work: device names (such as NUL and CON) apparently aren't found. As far as I remember, the DOS findfirst API is supposed to find character devices (such as NUL) in any (existing) directory, so this would depend more on DOS than on COMMAND, but I am not sure. Eric -- 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
Re: [Freedos-user] if not exist MD XXX
Hi Eric, As far as I remember, the DOS findfirst API is supposed to find character devices (such as NUL) in any (existing) directory, so this would depend more on DOS than on COMMAND, but I am not sure. Without any further investigation, I'd say that's part of it. However, aside from the MSW program cmd.exe (which obviously doesn't use NTVDM-DOS's FindFirst) the NTVDM-COMMAND program (which at least partly works as V86-mode DOS program) does find the devices too. I guess it might not use the NTVDM-DOS interfaces internally and hence finds the devices. This would indicate NTVDM-DOS's FindFirst and FindNext are broken (incompatible) in some way as you suggested. I didn't get into the specifics earlier 'cause I didn't think it was necessary. Regards, Christian -- 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
Re: [Freedos-user] Basic question on UIDE
All this talk about UIDE prompted me to investigate this tool. It looks interesting. How does the caching work for disk writes? UIDE uses Write Through caching, meaning all output data is written to disk immediately. For SATA/IDE disks handled internally by UIDE, if data fits in one cache block (75% of the time, for 64K blocks used by larger caches), data is moved to that block and output from there. UltraDMA is 32-bit and will do I-O from anywhere in memory, so direct cache I-O is possible. If output crosses over more than one cache block, data is written from the user output buffer, or from a 64K XMS buffer if the user's buffer is unsuitable for UltraDMA (odd address etc.), then moved to cache afterward. For smaller UIDE caches using less than 64K cache blocks, or when I-O crosses over multiple blocks, all I-O occurs on the FIRST block (NO fragmented reads/writes!) and UIDE moves data to the required cache blocks later. Diskettes, SCSI and other disks, whose I-O is handled by their drivers, cause UIDE to call the BIOS (or a callback subroutine for a user driver) then cache data after that call returns to UIDE. I experimented with Write Back caching (delayed writes) but never got it to work, and decided that it needed too many hooks into DOS, e.g. timer, Ctrl/Alt/Del vector, etc.For Write Through caching, UIDE needs to hook only the Int 13h vector for hard-disks, which is more reliable than snaking through the whole DOS system as SMARTDRV or Norton NCACHE2 must do. There is also a problem of power-failure whose only true solution is a U.P.S. (Uninterruptible Power Supply) and I shall NOT be the one to recommend such things for UIDE users! Finally, modern hard disks all have their own on-board write caches which pretty-much eliminate the need for a Write Back cache -- Note how fast deleting a large directory now occurs, with or without UIDE, and you will conclude that the disk write-cache must be helping for many operations! I assume that when the cache is full the next sector read in will cause the oldest sector to be written out? Absolutely! UIDE has a least-recently-use (LRU) linked-list which is part of its cache-block tables, and that list is updated for every I-O. When the cache is full, the cache block at the tail of the list, i.e. the LRU entry, is made free. This occurs at the end of every input or output, so UIDE always has a free cache block to use on the next I-O. Simpler logic, handling things that way! Is there any sort of a timer which will flush the cache to the hard drive periodically? No, and none is required, as UIDE does not delay any writes at all! How do you make sure that the RAM cache is written to the disk? I simply output all data IMMEDIATELY -- NO delayed writes at all! That is both the beauty and the benefit of using only Write Through caching -- NO possibility of data LOSS, due to waiting too long and suffering a power-failure, a bumbling user on the keyboard, etc. as with a Write Back cache like SMARTDRV and NCACHE2! They may still be a bit faster, for some compiler or database operations. But UIDE compensates by being a very FAST Write Through cache, using only 5K of assembly-language (NO wretched C here!), with up to a 4-GIGABYTE cache capacity! None of the older caches can get that high! I poked around in the documentation but did not find this information. Sorry, the source file for UIDE does say that it uses Write Through caching, but I did not put this in the README, which others will note is already technical ENOUGH! 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
Re: [Freedos-user] UIDE vs drive power management spin down timers
Eric, I read through and understood all your comments about hard-disk power management, etc. My problem is: I am not-interested in being the one who does power management. If DOS or the BIOS wants to save power thru putting disks into stand-by mode, let them do it. UIDE is a disk I-O driver, not a power-management tool, and I desire to keep such things OUT of UIDE's logic! Re: handling disk drives which ARE in stand-by mode, if all I need to do is allow some more time for them to spin-up, that is relatively easy. UIDE's CD/DVD logic currently allows 7 secs. for spin-up and 3 seconds for track-to-track seeks, which I had forgotten -- I had not looked at that logic for almost 5 years! Assuming 7 seconds should be long enough! for a hard disk, as well, I can simply use that value as a timeout during disk I-O, not the current 400-msec timeout. Shall experiment re: this idea. Might cause some confusion among UIDE users, who will now see a 7-second delay in some error handling. But, if UIDE needs only a timeout change to handle sleeping hard disks, it might be worth updating only 1 byte in its DoIO subroutine! 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
Re: [Freedos-user] UIDE vs drive power management spin down timers
Jack, I read through and understood all your comments about hard-disk power management, etc. My problem is: I am not-interested in being the one who does power management. If DOS or the BIOS wants to save power thru putting disks into stand-by mode, let them do it... There is not much to do there, as you only tell the disk once and then the disk itself does the rest. But it would be good to know from you that UIDE is (as predicted) happy to wait a moment for idle disks to spin back up as that in fact does not need any explicit handling by UIDE anyway. However, I would be happy if UIDE could do the sending of the idle timer config command to the disk because: It already does raw drive I/O anyway and it already has some command line parser anyway so it would only take a few more (non-resident) bytes to let UIDE send this command when the user puts the corresponding command line option during UIDE start-up. That way, no separate tool would be needed which would duplicate existing UIDE logics. UIDE is a disk I-O driver, not a power-management tool, and I desire to keep such things OUT of UIDE's logic! Yet UIDE already probably does drive setup communication with the disk for selection of the right communication speed so my point is it would be only a small step to make it possible to send other drive (e.g. idle timer) setup commands with it. relatively easy. UIDE's CD/DVD logic currently allows 7 secs. for spin-up and 3 seconds for track-to-track seeks, which I had forgotten -- I had not looked at that logic for almost 5 years! Interesting. So it can in fact report a time-out, but that should simply make DOS try again. As FreeDOS tries 5 times, you get much more than 3 or 7 seconds in the end, depending on which timeouts are used for int 13 functions 0, 2, 3, 42 and 43. Long enough :-) Assuming 7 seconds should be long enough! for a hard disk, as well, I can simply use that value as a timeout during disk I-O, not the current 400-msec timeout. Shall experiment re: this Thanks - and see above. idea. Might cause some confusion among UIDE users, who will now see a 7-second delay in some error handling. Good question. This would only make delays longer for errors that would never end without explicit error handling but I understand that users could still notice. For example I remember that using CompactFlash CF cards with a (purely mechanical) IDE adapter plug can have such hangs for low quality cards - in particular when you combine that plug with a SATA-IDE adapter with cheap chipset. So I guess such hangs would get longer with longer timeouts, as it might take the driver longer to give up the access attempt and decide to give the drive a smack of reset to reactivate it no matter whether it is the driver or just DOS which says reset. But, if UIDE needs only a timeout change to handle sleeping hard disks, it might be worth updating only 1 byte in its DoIO subroutine! Nice, thanks :-) Eric PS: Of course a stall/crash of a CF/SD/... card affects any OS. -- 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
Re: [Freedos-user] UIDE vs drive power management spin down timers
Eric, ... My problem is: I am not-interested in being the one who does power management. If DOS or the BIOS wants to save power thru putting disks into stand-by mode, let them do it... There is not much to do there, as you only tell the disk once and then the disk itself does the rest. Amen!, so let the user handle this thru the BIOS setup routines and let the BIOS tell the disk what to do during system boot! BIOS vendors have many more programmers than just me by myself! But it would be good to know from you that UIDE is (as predicted) happy to wait a moment for idle disks to spin back up, as that in fact does not need any explicit handling by UIDE anyway. UIDE's CD/DVD logic is happy to wait for up to 7 seconds, and I will look into changing its disk logic from 400-msec to 7 seconds as well. However, I would be happy if UIDE could do the sending of the idle timer config command to the disk because: It already does raw drive I/O anyway and it already has some command line parser anyway so it would only take a few more (non-resident) bytes to let UIDE send this command when the user puts the corresponding command line option during UIDE start-up. That way, no separate tool would be needed which would duplicate existing UIDE 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 for a disk from the BIOS, then runs a disk however the BIOS set it up. That, also, is something I want to LEAVE up to the BIOS, as I don't want any MORE trouble by changing BIOS settings again! UIDE is a disk I-O driver, not a power-management tool, and I desire to keep such things OUT of UIDE's logic! Yet UIDE already probably does drive setup communication with the disk for selection of the right communication speed so my point is it would be only a small step to make it possible to send other drive (e.g. idle timer) setup commands with it. No, sir! UIDE does NOT change any communication-speeds nor ANY other BIOS settings for disks, not since 2005, as I noted above! relatively easy. UIDE's CD/DVD logic currently allows 7 secs. for spin-up and 3 seconds for track-to-track seeks, which I had forgotten -- I had not looked at that logic for almost 5 years! Interesting. So it can in fact report a time-out, but that should simply make DOS try again. As FreeDOS tries 5 times, you get much more than 3 or 7 seconds in the end, depending on which timeouts are used for int 13 functions 0, 2, 3, 42 and 43. Long enough :-) 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 -- CD/DVD errors currently post only general error in such cases, and hard-disk errors would post only whatever hardware error applies to that part of DoIO which noted the timeout, likely a DMA error for most cases. Not a big problem. Disk/CD/DVD errors are few and far between, and people already know that a lot of DOS programs will only display Error!, leaving exactly WHAT error it was for diagnostic programs, etc.! ... Might cause some confusion among UIDE users, who will now see a 7-second delay in some error handling. Good question. This would only make delays longer for errors that would never end without explicit error handling but I understand that users could still notice. For example I remember that using CompactFlash CF cards with a (purely mechanical) IDE adapter plug can have such hangs for low quality cards - in particular when you combine that plug with a SATA-IDE adapter with cheap chipset. So I guess such hangs would get longer with longer timeouts, as it might take the driver longer to give up the access attempt and decide to give the drive a smack of reset to reactivate it no matter whether it is the driver or just DOS which says reset. 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!I would indicate in UIDE's README that an actual [rare!] disk error may now take that long, before DOS gives-up on it and reports something to the user. But, if UIDE needs only a timeout change to handle sleeping hard disks, it might be worth updating only 1 byte in its DoIO subroutine! Nice, thanks :-) That was only my Thought while eating breakfast! this morning, but I shall test it out, later today! 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
[Freedos-user] Interesting Chinese (english) DOS stuff plus system programmer book for dos.
http://johnson.tmfc.net/dos/index.html -- 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
Re: [Freedos-user] UIDE vs drive power management spin down timers
Jack, There is not much to do there, as you only tell the disk once and then the disk itself does the rest. Amen!, so let the user handle this thru the BIOS setup routines and let the BIOS tell the disk what to do during system boot! BIOS vendors have many more programmers than just me by myself! I have not yet seen a desktop BIOS which implements this, alas. 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. 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? 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. 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. That was only my Thought while eating breakfast! this morning, but I shall test it out, later today! Have a nice afternoon then :-) Eric -- 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
Re: [Freedos-user] Interesting Chinese (english) DOS stuff plus system programmer book for dos.
That is a very good link ... Thank You. Regards, Ferry --- On Sat, 5/14/11, Alvin P. Schmitt schmitt.al...@gmail.com wrote: From: Alvin P. Schmitt schmitt.al...@gmail.com Subject: [Freedos-user] Interesting Chinese (english) DOS stuff plus system programmer book for dos. To: freedos-user@lists.sourceforge.net Date: Saturday, May 14, 2011, 9:01 AM http://johnson.tmfc.net/dos/index.html -Inline Attachment Follows- -- 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 -Inline Attachment Follows- ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user -- 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
Re: [Freedos-user] UIDE vs drive power management spin down timers
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