EISA boards

[John C. Archambeau]

cpcahil at virtech.uucp (Conor P. Cahill) writes:
>In article <6316 at crash.cts.com> jca at pnet01.cts.com (John C. Archambeau) writes:
>>This is the precise reason that I want to avoid EISA.  If you all thought I
>>was screaming because of the recommendations of EISA over MCA I got.  You
>>ain't seen nothing, if I would have gone EISA (haven't bought the system yet)
>>over MCA and something like this would have happened, I would have screamed a
>>hell of a lot more.  :)
>
>One example of some hardware incompatibility (and there was no obvious
>explanation for the problem) and you are sure that EISA is terrible?

Actually, no, I may consider EISA, but I want to eliminate all potential
problems before they happen.  One of which, I don't want to be a lab rat for
X's implementation of EISA on Y's flavor of Unix.

>Some things to remember with EISA at this time:
>
>	1.  It is fairly new, so there may be problems with some
>	    implementations (the same kinds of problems that exist with
>	    some ISA implementations).

The main problem is that with the new wave of EISA machines is that you are
going to be a lab rat.  Why be a lab rat?  Also, the problems with ISA have
been, for the most part, ironed out.

>	2. Most OSs have not yet been tested/modified to work correctly with
>	   EISA (don't know if this is true for ESIX, but ISC2.2 requires
>	   a fix disk to work correctly with EISA).

True, but shouldn't EISA be backwards compatable to ISA?  Put the EISA slots
in ISA mode and they should work fine, right?  Well, they don't seem to, do
they?  The one problem that I have is that the problem machine posted is an
ALR PowerCache 4e which is Novell and SCO certified.  Ok, barring that in
mind, if you don't take advantage of the special capabilities of EISA, your
ISA cards should work fine, right?  Wrong, this poor soul's tape drive
controller bombs his system.

>I'm not saying EISA is "the" way to go, just that like any new toy, you can't
>expect to run at the cutting edge of technology and not experience some 
>problems.
>
>>Such behavior is no where near acceptable for a Unix box.
>
>Yup.  But if the Unix vendor does not say thier product will work with 
>an EISA board, you are on your own.  The same goes for unknown ISA boards.

I read between the lines on that statement.  If a vendor doesn't support EISA,
I read that to be "our product doesn't support the full capabilities of the
EISA bus."  All of the EISA hype is that it is backwards compatable with ISA,
correct?  And this isn't some generic EISA board, but from a major 80x86
system vendor that has the seal of approval from Novell and SCO.  Should work,
based on all of what EISA is supposed to do.

Enough of the third degree.  Do you now see my point about why one should be
weary of EISA and why I am seriously considering MCA as opposed to EISA?

EISA may be just perfect for someone else, but I don't want to be a lab rat. 
Why be a lab rat when I can get a 386 or 486 machine with a system bus that
has seen the light of day longer than EISA?

I will admit that the tape drive controller may not be the problem with the
Powercache 4e and the WangTek tape controller, but it looks awfully
suspicious to me when the controller is pulled out of the EISA slot and works
better in the ISA slot.

The only real way to isolate if it's the Powercache's EISA bus is to build an
identical system on an ISA machine.  If it works on the ISA machine, then you
know it's the EISA bus on the Powercache.

     // JCA

 /*
 **--------------------------------------------------------------------------*
 ** Flames  : /dev/null                     | What to buy?
 ** ARPANET : crash!pnet01!jca at nosc.mil     | EISA or MCA?
 ** INTERNET: jca at pnet01.cts.com            | When will the bus wars end?
 ** UUCP    : {nosc ucsd hplabs!hp-sdd}!crash!pnet01!jca
 **--------------------------------------------------------------------------*
 */