Xref: utzoo comp.sys.ibm.pc:47220 comp.periphs.scsi:245
Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!hellgate.utah.edu!cs.utexas.edu!samsung!usc!sdsu!crash!pnet01!jca
From: jca@pnet01.cts.com (John C. Archambeau)
Newsgroups: comp.sys.ibm.pc,comp.periphs.scsi
Subject: Re: MFM and SCSI together ?
Message-ID: <1977@crash.cts.com>
Date: 27 Mar 90 05:36:02 GMT
Sender: root@crash.cts.com
Organization: People-Net [pnet01], El Cajon CA
Lines: 84

iverson@xstor.UUCP (Tim Iverson) writes:
>In article <1969@crash.cts.com> jca@pnet01.cts.com (John C. Archambeau) writes:
>>I based my assertion on trying to hang an ESDI and ST412/506 controller
>>at the same time on the same machine.  Doesn't work too hot.
>
>This is correct.  Both ESDI and ST506 typically attempt to be WD1003
>compatible, since clone BIOSes support that register set directly.  This is
>why most *ESDI* and ST506 boards have "IRQ and i/o port wars".  Most SCSI
>board vendors have chosen to *not* support the WD1003 register set and
>instead to put their own BIOS on the adapter.  This makes the boards more
>hardware compatible, but more expensive to design.
 
What if you're using an OS that can only use the BIOS at power on to boot such
as *nix?  Then you need a driver for each manufacturer's SCSI host adaptor to
run under this vendor's operating system.  Obviously the vendor isn't going to
provide it unless it is a commonly used piece of hardware.  The onboard
controller BIOS can not be used for something such as Unix.  So what do you do
then?  You have to go through what controllers are supported by the OS and
prey the one you want has a driver either provided by the manufacturer of the
controller or the vendor of the OS.  Anybody who needs SCSI such as hell isn't
going to use DOS with it since it would be a waste.

>>Also, I didn't say that what I said was the gospel truth, just an
>>educated guess considering I know some of the horrors of SCSI and the IBM
>>compatable domain.
>
>Unfortunetly, in the this area your educated guess is serious misinformation
>at best - at worst, it is a bald lie.  If you cannot restrict yourself to
>reporting facts, do not post.
 
The word here is recommendation.  Anything I post I wouldn't recommend doing
for a customer or myself.  We stay away from SCSI totally with the only
exception being this one customer that has everything SCSI for performance
reasons in the IBM compatable domain.  I am not convinced of how well SCSI is
supported in the IBM compatable domain.  Every manufacturer does their SCSI
host adaptor differently which means problems with respect to finding drivers
for alternate operating systems.

>>[...] Granted, you may be able to
>>do it, but also think from the practical standpoint, why would you want to? 
>>You have this slow drive that's running ST412/506 MFM and a SCSI controller
>>with possibly a Wren IV to VI running like a bat out of hell. I wouldn't do
>>it just for the sake of system performance [...]
>
>In your previous article, you lambasted vendors for second guessing the
>users' needs.  Here, you are guilty of that yourself.  Perhaps the user
>will use the quick subsystem for work and the slow one for backup (after
>all, it works and he already owns it).  Also, the presence of an ST506
>subsytem in a system with a SCSI subsystem in no way degrades the
>performance of the SCSI subsystem - the two are mutually exclusive.
>
>In a multitasking OS, if the subsystems are used concurrently, and if the
>SCSI H/A does 1st party DMA, then the 1003 compatible subsystem will
>degrade overall system performance more than the SCSI subsytem.  When the
>1003 subsystem is not being used, system performance is not impacted at
>all.  Running slowly during backups usually considered acceptable.
 
Multitasking operating systems don't use the BIOS.  Unless the onboard
controller BIOS is designed to run in 286/386 protected mode, you're going to
need a driver for the SCSI host adaptor you're using, whether it be OS/2 (gag)
or *nix.  Again, the problem of "where do I get that damned driver to run this
controller with this OS?" comes into play.  If there's no driver for the
controller, you are sunk.

>>As for Novell, the only thing that is 100% Novell approved is Novell's DCB
>
>This is another outright lie.  SDI markets both ESDI and SCSI (non DCB)
>subsystems that are 100% certified.  SDI also markets a 100% certified
>fileserver (basically a 33Mhz 386 optimized for disk i/o).

Try using anything other than Novell's DCB board with NetWare 386, you will
find that it will not work by longshot.  No drivers for any other board other
than the DCB.  This is from Novell, this is fact since we did it.
 
     // 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
 **--------------------------------------------------------------------------*
 */