Mail Archives: djgpp/1998/03/08/20:39:45
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
- Raw text -