Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!think!mintaka!mit-eddie!uw-beaver!ubc-cs!alberta!dvinci!weyr!p3.f1.n396.z1.FIDONET.ORG!Jim.King
From: Jim.King@p3.f1.n396.z1.FIDONET.ORG (Jim King)
Newsgroups: comp.os.os2
Subject: Re: OS/2 and Hard Drives
Message-ID: <511.25CCC2B1@weyr.FIDONET.ORG>
Date: 3 Feb 90 15:19:15 GMT
Sender: ufgate@weyr.FIDONET.ORG (newsout1.26)
Organization: FidoNet node 1:396/1.3 - New Orleans Tech BB, New Orleans LA
Lines: 29


 >> Because by the time POST completes and the operating system bootstrap 
 >is 
 >> loaded, the INT 41H drive parameter vector is pointing at a "drive 
 >type" 
 >> that the WD1007 has constructed during POST.
 >
 >But if the drive params are 'constructed', as you say, where IS the
 >vector pointing to?  Surely it can't be in RAM?
 >
 >Hmmm, sudden realization:  The PS/2's with large ESDI disks have
 >slightly less than 640K free in lower memory.  If I remember
 >correctly,  this is where is stores the drive parameter table.
 >After reading your note, it all clicked in.  The ps/2 POST is
 >building the table there and then only reporting 639K free.
 >
 >Do you know how the WD1007 does it?

Yup, on the PS/2's the drive parameter table is in the Extended BIOS Data Area (which resides at the top 1K of the lower 640K).

The WD1007 has some very clever hardware to handle this.  It builds the parameter table in some RAM on the WD1007, then maps that RAM into the address space where the WD1007 BIOS resides.  For example (exiting to the DOS box briefly...) on my machine INT 41H is pointing at C800:1F50.

Many drive controllers and system BIOS's that allow custom drive types put the parameter table in the interrupt vector space.  For example, the Adaptec 2372 BIOS puts the parameters for drive 0 in the space normally used for interrupt vectors 60H through 63H..

--  
Jim King - via FidoNet node 1:140/22
UUCP: alberta!dvinci!weyr!396!1.3!Jim.King
Internet: Jim.King@p3.f1.n396.z1.FIDONET.ORG
Standard Disclaimers Apply...