Bell Tech Unix Review #2

[Karl Denninger]

In article <250 at belltec.UUCP> dar at belltec.UUCP (Dimitri Rotow) writes:
>...
>>     on the disk. I'm stuck with 17. BT says I need a special rom that will
>>     define a drive type that has 26 sectors per track. I should by this from
>>     intel, they say. Intel says, "a what? never heard of it!".
>
>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.  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 ... 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), 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.

Me thinks you are incorrect.
 
First, *most* clones and Real Blue IBM Machines DO NOT have entries for RLL
drives.  This is because everyone and their brother does it a little
differently.  Some use 25 sectors per track, Adaptec uses 26, and I have
also seen 27.  Having ROM entries for all possibilities would exhaust the
ROMs storage capacity -- and STILL be far too limited.  There are new drives
(and controllers) being introduced all the time.  Should we have to update 
our ROMs every time another drive or controller hits the market?  Of course not!

Better machines DO know about ESDI drives -- but I've yet to run into a
"mainstream" clone with RLL drives in the ROM tables.  (There undoubtably 
are some, but none that I have seen).  Even in these cases, the ESDI support
I've seen does not cover the range of drives available -- you STILL need to 
be able to override drive types even in these machines.

MSDOS uses (and always has) the (correct) BIOS calls to get disk geometry.  
The *ONLY* time anything should interrogate CMOS directly for drive types is 
on the initial POST-initiated boot sequence (ie: no code in the machine yet; 
this comes from the boot loader in ROM).  If you're doing a direct 
interrogation of the CMOS, you're doing it wrong.  The POST builds a disk 
parameter block -- which can be (and is) intercepted by controllers like the 
Adaptec.  If you get your parameters from this RAM-based location, it is 
ALWAYS RIGHT providing your controller is reasonably intelligent.

This is why MSDOS can run on an XT, where it still needs to know disk
geometry but has not a byte of CMOS ram anywhere in the system.....


SCO Xenix, MSDOS, and many others are well versed in the proper way to
access disk parameters.  It is *NOT* done by going through the BIOS ROM 
tables.  These were specifically designed to be overridden if necessary.  In
fact, the only correct purpose of the disk type tables in ROM is to allow 
the system to find the boot sector on the fixed disk!

Are you telling the world at large that your OS cannot deal with a drive 
that is not in the ROM tables?  I would find that limitation immediately 
disqualifying for your version of UNIX (tm) -- our needs are too diverse to
live with such a limitation.

Of course, it does make a very good case for purchasing your hardware,
doesn't it?  

Don't blame the hardware for what is an obvious software flaw.  Fix the
geometry read routine....

--
Karl Denninger (ddsw1!karl) Data: (312) 566-8912, Voice: (312) 566-8910
Macro Computer Solutions, Inc.    "Quality solutions at a fair price"