Message-Id: <199803090138.RAA12095@mailhost2.cac.washington.edu> From: "Ned Ulbricht" Organization: University of Washington To: Eli Zaretskii , djgpp AT delorie DOT com Date: Sun, 8 Mar 1998 17:35:56 -0800 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: hdparm lets your IDE disk spin down CC: djgpp AT delorie DOT com References: <34FF57C2 DOT 1B42 AT ee DOT washington DOT edu> In-reply-to: Precedence: bulk On 8 Mar 98, Eli Zaretskii wrote: > > On Thu, 5 Mar 1998, Ned Ulbricht wrote: [My first suggestion was to get a copy of the interrupt list. In the rest of this, I'm just going to write e.g. 2132 in interrupt list style.] > > Look at int 21h, ah=32 which gets the drive parameter block for a > > specific drive. The DPB associates drive letters with assigned device > > drivers. > > Can you explain how Int 21h/AH=32h helps to solve the problem of > associating a drive letter such as D: with the physical drive number > such as 81h? 2132 gives you the unit number within the device driver, > but that's not enough. No, it's not enough. But the system itself is able to resolve this problem, right? The reference I checked says that this is DOS's first step. And the DPB does get you past subst'd and assign'd drives which is something that's absolutely needed. (You could look at the CDS instead, but why?). > Some questions for which I cannot see (easy) solutions are: I certainly hope I didn't give the impression that I thought this is trivial! In fact, I suggested that this discussion move to comp.os.msdos.programmer for "part a) what to do", precisely so that people who have expertise and interest in this could look over shoulders & make comments. (Some people seem to work with the drives at low level all the time over in that n.g. :-) > - How do you know what is the number of the zeroth unit number > (usually 80h for C:, but how do you know it)? When isn't that true? All the documentation that I've seen so far says that bit 7 is used as a flag to indicate a (local) hd when using int 13 style calls. Of course, you might want to look in the CMOS first to see if there are any BIOS drives defined at all. > - What about disks which are partitions of a single drive? Even worse, the drive may be partitioned using Disk Manager or Drive Rocket. The only solution I can see is to hook into the drive handler chain either via 13 or 2F13 (as appropriate), insert a dummy request for the logical drive at some level above, note the physical drive that gets called at the 13 level, then unhook from the chain again. I'm still not sure about the best non-destructive dummy call to make or where it should be inserted into the calling sequence. If you did a read from high level or even used some of the 2144 calls, then DOS would make the 2132 call for you. OTOH, a status check of some type might do the trick. This might still be problematic--in fact I recall that some of the early partitioning software used several different approaches. > - What about disk(s) connected to secondary disk controller? There are two problems here. Many BIOSs only support 2 drives, however some support 4. Look at vectors 41,46 in R.Brown for a possible way to resolve that. > - What about CDs and SCSI drives and other atrocities? REDIR interface "network" drives can be identified by using 214409 and testing bit 0C of DX (there are other calls that'll return this info too). But a local IDE drive could be hiding behind SMARTDRV or other caching s/w, so use 2F4A10 BX=0000,BX=0003 to find the real logical drive number--and this has the side-effect of knocking out CD-ROMS. I keep going back to how to find the DDH since I got the vague impression from the original poster that he knew how to get the physical drive once he had the driver. I'm not really sure how this helps myself, but it could be found at this point by walking the DDH chain starting from either 2152 or 2F122C until the drive number matches what you got from SMARTDRV. > You could of course use the above call to get a pointer to the entire > chain of the DPB's, and then walk that chain, but that's hardly an > easy way, and I'd imagine it won't work e.g. on Windows 95. MS-DOS 7 shouldn't be a problem--use 21440D CL=6F (after first checking to make sure it's supported) & if R.Brown's right then you're home free. Finally, no matter what you do send EC to port 1F7 or 177 to positvely id it as an IDE drive. Anyhow, turn & turn about's fair play. You suggested reading the disk--how does that get you there? -- Ned Ulbricht mailto:nedu AT ee DOT washington DOT edu