Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!rutgers!gatech!linus!mbunix!jcmorris
From: jcmorris@mitre-bedford.ARPA (Joseph C. Morris)
Newsgroups: comp.os.minix
Subject: Re: All these hard disk problems
Message-ID: <15844@linus.UUCP>
Date: Thu, 22-Oct-87 13:42:18 EST
Article-I.D.: linus.15844
Posted: Thu Oct 22 13:42:18 1987
Date-Received: Sun, 25-Oct-87 01:39:49 EST
Sender: news@linus.UUCP
Reply-To: jcmorris@mbunix (Morris)
Organization: The MITRE Corporation, McLean, VA.
Lines: 25
Keywords: disks,Hardcard

References:


A recent posting to comp.os.minix observed that there is a large
number of special cases which have to be handled when using some of the
brand "X" hard disk controllers.  While IBM can be faulted to some degree
for not having put the best gee-whiz controller in their machines, it's
not really fair to blame it for the failure of the clone vendors to provide
products which meet the documented interface specs.  (Of course, there *are*
problems with undocumented specs, but that's another question.)

In any case, here's another gotcha: in a PC or XT with both a hard disk and
a Hardcard (the hard-disk-on-a-card) it turns out that the microcode in
the Hardcard is using interrupt vectors 7C-7D-7E-7F to store some pointers.
The vendor's documentation doesn't indicate that this is being done.
(The PC documentation identifies these vectors - at addresses 1F0-1FF -
as "unused".)  These data areas are used ONLY if the PC has both a normal
hard disk controller AND a Hardcard.  There is no problem if the Hardcard
is the only disk in the machine.  DOS itself isn't bothered by the use of
the memory locations, but if you have some other program using those addresses
you've got a problem.  In our case it was YTERM, which documents its use of
interupts 7D-7E-7F.
 
I don't know if MINIX will be affected, but with more people trying to make
Minix and DOS coexist and needing more disk space to do it in, someone 
is likely to be zapped by this.

Joe Morris