Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!rpi!dali.cs.montana.edu!milton!ogicse!emory!hubcap!ncrcae!ncr-sd!crash!pnet01!jca
From: jca@pnet01.cts.com (John C. Archambeau)
Newsgroups: comp.sys.ibm.pc.misc
Subject: Re: Mixing hard drive types: ESDI, MFM, IDE
Message-ID: <5675@crash.cts.com>
Date: 16 Nov 90 08:56:01 GMT
Sender: root@crash.cts.com
Organization: People-Net [pnet01], El Cajon CA
Lines: 78

kls30@duts.ccc.amdahl.com (Kent L Shephard) writes:
>In article <5569@crash.cts.com> jca@pnet01.cts.com (John C. Archambeau) writes:
>>kling@ICS.UCI.EDU (Rob Kling) writes:
>>>Any comments/explanations about why there might be incompatibilities
>>>if the appropriate drives are each connected to a proper controller for
>>>that kind of drive?
>>
>>Simple, because ESDI, IDE, and ST412/506 use the same port addresses.  An IDE
>>drive looks to your system like an ST412/506 drive to your system BIOS.
>>
>>What you could probably do is set your ST412/506 MFM controller card to the
>>secondary port address, but then you have a problem of setting it to the
>>second interrupt.  Not to mention that MS-DOS doesn't care to play with second
>>controllers.
>
>Wrong!  Buy a controller designed to act as a secondary controller in the
>system.  It WILL work if the controller has its own bios.  Since the
>device has its own bios MS-DOS WILL play with a secondary controller.

But try and find such controllers.  My WA3-16 (WD1003-WA2 clone, same chip
set) has the ability to be configured as a secondary controller, BUT it has no
on-board BIOS which means you need an OS that is 'aware' of a secondary
ST412/506 MFM controller to use this feature of the WA3-16 (same case applies
to WD1003's and WD1006's).

Now there's another problem with using my controller as a secondary controller
under let's say Xenix.  It's not a wise idea to have two controllers using the
same IRQ, so you have to punt that around.  But wait, you can't punt that IRQ
around, it's fixed.  The port address is no problem to punt around, but what
about that IRQ?  Well, you solder a jumper wire from the controller to the
desired IRQ line.  Very few hard drive controllers have the ability to punt
around the IRQ.  Something very desirable if you're going to have multiple
controllers in your machine.

>MS-DOS will play with ANYTHING provided you have a bios level driver or
>an installable device driver.

Never say anything.  There are ALWAYS (and that's the only given in the
computer industry) an exception.

One big exception I've noted is the XT floppy controller with on-board BIOS
for high density drives.  They don't seem to work to hot.  At least with my
experience with them.  Anything you say?  Well, gee, I must be having a bad
time of it all.

>I know because I have a DTC controller that works as the second controller
>in my system and I've also designed a couple of interface boards for PC's
>that were definitely non-standard and MS-DOS played just fine.

DTC you say?  Well, it may work just fine under MS-DOS, but Novell Netware
doesn't like it (at least ELS Level II doesn't).  When a controller won't even
COMPSURF, then I begin to wonder.  Swapped the controller for a WD1006 and it
ran with the same drive like a champ.

>>Only big exception is SCSI.  Your SCSI host adaptors are designed to work with
>>an existing ST412/506, ESDI, or IDE drive already in your system.
>
>SCSI is a good option because, if you ever change computer systems (Mac
>NeXT, Amiga, SUN) you can reuse the SCSI drive.

Maybe I should correct you.  Mac's use their own brain damaged implementation
of SCSI.  Drive makers such as Imprimis and Micropolis make a special version
of their SCSI drives just for Macs.  Note the letters in a Seagate model
number with NM in them (SCSI Mac).  Now there are some smart drives that you
can pull off of one machine and put on another, but there are no guarrantees
that it will work considering the brain damaged non-ANSI SCSI spec the Macs
use.
 
     // JCA

 /*
 **--------------------------------------------------------------------------*
 ** Flames  : /dev/null                     | Small memory model only for
 ** ARPANET : crash!pnet01!jca@nosc.mil     | Unix?  Get the (*bleep*) out
 ** INTERNET: jca@pnet01.cts.com            | of here!
 ** UUCP    : {nosc ucsd hplabs!hd-sdd}!crash!pnet01!jca
 **--------------------------------------------------------------------------*
 */