Xref: utzoo comp.unix.microport:1128 comp.unix.xenix:2844 Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!bellcore!tness7!bigtex!james From: james@bigtex.uucp (James Van Artsdalen) Newsgroups: comp.unix.microport,comp.unix.xenix Subject: Re: Bell Tech Unix Review #2 Message-ID: <5076@bigtex.uucp> Date: 1 Aug 88 00:43:42 GMT References: <195@focsys.UUCP> <250@belltec.UUCP> Reply-To: james@bigtex.UUCP (James Van Artsdalen) Organization: F.B.N. Software, Austin TX Lines: 59 In article <250@belltec.UUCP>, dar@belltec.UUCP (Dimitri Rotow) wrote: > Larry, surely you know that virtually the entire PC AT world lives and > dies by the contents of the disk table in the BIOS ROM. Everything except MS-DOS, which cares not a whit what's in ROM. > For three > years now disk drive support for DOS and a host of other operating > systems has expected an accurate list of disk drives in the BIOS ROM Except for MS-DOS, which doesn't care what's in ROM. > ... it's a way of life in the AT world. Yes, I know that it's neat to > have an O/S that doesn't care about the contents of the ROM (within > limits), Such as MS-DOS, which doesn't care what's in ROM (anyone notice a pattern?) > but part of the value of buying the *right* clone is getting > a well rounded disk drive table in the BIOS. Lots of clones these > days have RLL and ESDI type sectors per track in their BIOS ROMS. I don't mean to flame Bell Technologies, because Microport and SCO also appear to have this same problem, along with Novell and who knows what else. I've never been able to determine what lead all of them to do things wrong - IBM's AT technical reference manual clearly shows that using the ROM is the wrong way to do things. The INT 41h and INT 46h vectors (addresses 0:0104 and 0:0118) point to BIOS Disk Parameter Tables. These tables define the geometry of the drive. These tables do not necessarily reside in ROM, and in fact often do NOT do so with modern disk controllers. The correct way for unix to boot and configured its drivers is to have the boot sector copy the two table entries to a safe place (since loading unix may overwrite them). These values should then be used by the boot sector to read the kernel loader, and should be used initialize the hard disk driver. At no point is there ever any cause to directly read the ROM for disk geometry! In particular, there IS NO CAUSE to to pay attention to the drive type number - that number is considered a private BIOS value whose ONLY use is to build the Disk Parameter Tables. Many modern disk controllers are designed to overcome deficiencies in the BIOS ROM tables. Western Digital, OMTI and Adaptec have several controllers that do this. They correctly build accurate Disk Parameter Tables in RAM at POST time. BIOS and DOS then proceed to use these values. Were the various unix vendors to (1) use the Disk Parameter Table values instead of digging in ROM and (2) to allow enough table space inside the driver (what a novel thought - dynamically allocate the track buffer based on the geometry of the drive instead of using a statically allocated array!), we wouldn't have the situation now where DOS can easily use the latest ESDI, RLL and SCSI technology, while unix almost seems to be stuck with the old 17 sec/trk drives... -- James R. Van Artsdalen ...!ut-sally!utastro!bigtex!james "Live Free or Die" Home: 512-346-2444 Work: 328-0282; 110 Wild Basin Rd. Ste #230, Austin TX 78746