Path: utzoo!utgpu!watserv1!watmath!att!pacbell.com!mips!sdd.hp.com!ucsd!ucbvax!FTP.COM!jbvb
From: jbvb@FTP.COM ("James B. Van Bokkelen")
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Re: NCSA + Novell
Message-ID: <9101081603.AA26905@ftp.com>
Date: 8 Jan 91 16:03:49 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: jbvb@ftp.com
Organization: The Internet
Lines: 23


    We are using a native (i.e., non-CMU/PD) IPX module talking
    directly to a 3C501. We are also using NCSA Telnet with the
    direct-to-the-card config (i.e., again, no PD). After carefully
    explaining to a colleague why, due to contention for the H/W IRQ used
    by the network card, he wouldn't be able to get Novell and NCSA Telnet 
    to work simultaneously without a PD and the appropriate IPX-for-the-PD
    module, he proceeded to ignore this "wisdom" and load the Novell stack
    followed by the NCSA Telnet - works like a charm, apparently.
    ...
    Hence, the question "Why does this work?? 

The magic word is "3C501".  First, it has very little on-board state
(compared to something that uses an 8390 or 82586 LAN controller chip). 
This makes it much more likely that the two drivers initialize it the
same way.  Second, the card exists in various versions, and some (at
least) had quirks (to be charitable).  If a 3C501 acts odd, or you don't
see traffic for a while, the first reflex action taken is to reset it.
In our "Compatibility Sheet", we note that PC/TCP has this kind of "cold
war" coexistence with many kinds of software when using the 3C501...

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901