gwr@linus.UUCP (Gordon W. Ross) (12/16/89)
I have noticed that recent discussions about the wini driver and its
adaptation to differing hard disk geometries have not included any
mention of the PC BIOS hard disk parameter vectors.
The best way to determine the hard disk geometry at boot time (on a
PC/AT compatible) is to examine the BIOS hard disk parameter tables.
All PC/AT compatible (and 386/AT) systems have boot-time
initialization code in the system BIOS that sets two interrupt
vectors (0x41, 0x46) to point at parameter tables for the first and
second hard disk, respectively. The content of these tables is
described below.
These tables are the best source of information about hard disk
geometry for two reasons:
First, many hard disk controllers include a controller BIOS with a
boot-time routine that installs correct disk geometry parameters in
some area of RAM and then points the parameter vectors at those new
parameters. Adaptec and Western Digital controllers for RLL and ESDI
drives are usually configured to do this "parameter fixing."
Note that when the controller changes the hard disk parameters, the
values indicated by the CMOS RAM are no longer valid.
Second, these hard disk parameter tables use a 16-bit word to store
any cylinder number quantities and are therefore not limited to a
10-bit cylinder number as is BIOS int 0x13 sub-function 8.
Though MS-DOS can't deal with cylinder numbers greater than 1024,
some other systems that want to know the true disk geometry use
these parameter tables to determine the disk geometry.
(AT&T Sys V/386 Rel 2 does it this way.)
Unfortunately, I haven't had time to work on the at-wini driver.
I am posting this information in hopes that someone will use it to
make the at-wini driver figure out the disk parameters at boot time.
Gordon W. Ross (E025) ARPA: gwr@linus.mitre.org
The MITRE Corporation UUCP: {decvax,philabs}!linus!gwr
Burlington Road, Bedford, MA 01730 (617) 271-3205
Attached is a description of the PC/AT BIOS hard disk parameters.
/****************************************************************
* The structure declaration below represents the layout of the
* PC/AT BIOS hard disk parameter tables. Interrupt vectors
* 0x41 and 0x46 point to parameter structures for the first and
* second hard disks, respectively. This information was found
* in the "IBM PC/AT Hardware Technical Reference Manual."
*
* Note that the number of cylinders is not limited to a
* ten-bit quantity in this structure, so it is possible to
* have num_cyl > 1024 (even though MS-LOSS can't handle it).
****************************************************************/
typedef unsigned short word; /* a 16-bit quantity */
typedef unsigned char byte; /* an 8-bit quantity */
struct BIOSHDParms {
word num_cyl; /* NUMber of CYLinders (arm positions) */
byte heads; /* tracks per cylinder */
word xt3; /* PC/XT (unknown use) */
word wpc_cyl; /* Write PreCompensation CYL */
byte xt7; /* PC/XT (unknown use) */
byte control; /* control bits for retry (ignore) */
byte xt9, xtA, xtB; /* PC/XT (unknown use) */
word off_cyl; /* power-OFF Landing CYLinder */
byte sectors; /* sectors per track */
byte reserved; /* IBM says "for future use" */
}
--
Gordon W. Ross (E025) ARPA: gwr@linus.mitre.org
The MITRE Corporation UUCP: {decvax,philabs}!linus!gwr
Burlington Road, Bedford, MA 01730 (617) 271-3205yip@ztivax.UUCP (Dr Yeung-Cho Ip) (12/18/89)
In article <83311@linus.UUCP> gwr@linus.mitre.org writes: >The best way to determine the hard disk geometry at boot time (on a >PC/AT compatible) is to examine the BIOS hard disk parameter tables. > The "init_params" routine in the original at_wini.c does exactly that! >First, many hard disk controllers include a controller BIOS with a >boot-time routine that installs correct disk geometry parameters in >some area of RAM and then points the parameter vectors at those new >parameters. The problem with our ADAPTEC controller board was, that MINIX overwrites the controller generated disk geometry parameters at boot up. When the "init_params" routine in the at_wini driver tried to read the RAM location, wich is referenced to by the vector 0x41, it allways got wrong disk parameters. We fixed this quick and dirty by hardcoding the right parameters into our at_wini.c . Hope that helps Michael Franzen Michael Franzen, c/o yip@ztivax, Siemens AG, Munich
yip@ztivax.UUCP (Dr Yeung-Cho Ip) (12/20/89)
Sorry for posting this here, but I couldn't reach Bruce through net mail. Hello Bruce, in your letter you wrote: > Where does the controller leave the parameters? I would like to stop Minix > overwriting them for version 1.5. > > I suspect they are being put in the interrupt table (below 0x00400) since > Minix doesn't touch (much of) 0x400-0x5FF and everything above there is > touched by DOS. You're right. The quick and dirty changes I mentioned in my message are nearly one and a half year old. Yesterday, I had a closer look on the way our ADAPTEC controller works, and I found out that it writes the disk parameters to the locations 384 (decimal) upwards. In addition, I altered the at_wini.c so that it now correctly handels this case Since I don't know whether all ADAPTEC and Western Digital controllers use the same locations, my approach differs from your suggestion. I altered the constant VECTOR_BYTES so that the kernel (main) saves the disk parameters to vec_table prior to overwriting them. The at_wini then reads the parameters from this table, provided the pointer at 0x41 points to the low ram lokations. I will post this new at_wini.c in a few minutes. Michael Michael Franzen, c/o yip@ztivax, Siemens AG, Munich
jca@pnet01.cts.com (John C. Archambeau) (12/24/89)
yip@ztivax.UUCP (Dr Yeung-Cho Ip) writes: > >Sorry for posting this here, but I couldn't reach Bruce through net mail. > >Hello Bruce, > >in your letter you wrote: > >> Where does the controller leave the parameters? I would like to stop Minix >> overwriting them for version 1.5. >> >> I suspect they are being put in the interrupt table (below 0x00400) since >> Minix doesn't touch (much of) 0x400-0x5FF and everything above there is >> touched by DOS. > >You're right. The quick and dirty changes I mentioned in my message are nearly >one and a half year old. Yesterday, I had a closer look on the way our ADAPTEC >controller works, and I found out that it writes the disk parameters to the >locations 384 (decimal) upwards. > >In addition, I altered the at_wini.c so that it now correctly handels this case >Since I don't know whether all ADAPTEC and Western Digital >controllers use the same locations, my approach differs from your >suggestion. I altered the constant VECTOR_BYTES so that the kernel (main) >saves the disk parameters to vec_table prior to overwriting them. The >at_wini then reads the parameters from this table, provided the pointer at 0x41 >points to the low ram lokations. > >I will post this new at_wini.c in a few minutes. > >Michael > >Michael Franzen, c/o yip@ztivax, Siemens AG, Munich On an IBM AT, one can get the parameters from the CMOS RAM. This is well documented in Phoenix's BIOS manual for the AT/XT machines. (Again, I forget the title, but the BIOS manual is out there, and everything is well documented). // JCA /* **--------------------------------------------------------------------------* ** Flames : /dev/null | My opinions are exactly that, ** ARPANET : crash!pnet01!jca@nosc.mil | mine. Bill Gates couldn't buy ** INTERNET: jca@pnet01.cts.com | it, but he could rent it. :) ** UUCP : {nosc ucsd hplabs!hd-sdd}!crash!pnet01!jca **--------------------------------------------------------------------------* */