Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84 SMI; site sun.uucp
Path: utzoo!watmath!clyde!bonnie!akgua!sdcsvax!sdcrdcf!hplabs!oliveb!ios!qubix!sun!wmb
From: wmb@sun.uucp (Mitch Bradley)
Newsgroups: net.lan
Subject: Re: IBM PC networking
Message-ID: <1742@sun.uucp>
Date: Sat, 13-Oct-84 17:24:51 EDT
Article-I.D.: sun.1742
Posted: Sat Oct 13 17:24:51 1984
Date-Received: Mon, 15-Oct-84 01:53:31 EDT
References: <682@cadmus.UUCP> <63@redwood.UUCP>
Organization: Sun Microsystems, Inc.
Lines: 75

Regarding the Intel 82586

> (and no
> wonder it took them so long to make it work). ((In fact, last time I looked,
> it STILL wasn't working at 10 Mbit/s, but surely they've fixed that by now,
> haven't they? ;-} Can someone tell me? ))
> 

It has been working at 10 MHz for over a year.

> It's simply too complex. The best part about it is the buffer handling (you
> can separate the transmit header from the body), but the Mostek/AMD "Lance"
> has all of the needed functionality in the buffer handling area (including
> command and data chaining) but is a lot simpler to use. (The "Lance" was
> clearly built to do Ethernet.

Certainly, it's too complex.  Ironically, though, most of the bugs in the
early revs of the silicon were not due to the configurable net parameters,
but in the buffer handling.  The LANCE is certainly cleaner and simpler,
but the reality of the situation is that useable silicon was
available for the Intel chip more than 1 year before the LANCE.

> 
> Surprisingly, the one configurable parameter that is needed desperately is
> missing. The "Lance" lets you select Big-Endian vs Little-Endian byte order
> within a 16-bit word ("byte swap" or not on transmit/receive data, without
> affecting command descriptors), a feature that the 82586 sorely needs when
> handling DoD/IP or XNS (both of which are "Big-Endian"). The 82586 is
> "optimized for operation with the iAPX 186 bus [80186] but can be used
> with other general purpose processors." [p. 2-2] It's gonna be REAL fun
> to use with a 68000... ;-}
> 
> Someone PLEASE correct me if I am wrong on this point, as it is critical
> to avoid the overhead of swapping bytes in software before/after you
> transmit/receive.  Although I looked through the User's Guide and the Data
> Sheet carefully, I found no mention of byte order, except one very clear
> picture of the address bytes which shows it to be "Little-Endian" (the first
> byte sent is bits 7-0, the second byte is 15-8, etc.). It may very well be
> that the only reasonable way to use the 82586 (even with a 80186) is to
> reverse the high and low bytes in the wiring of the board, though this will
> totally confuse the programming of the control and descriptor blocks (which
> contain addresses in them).  Still, it is perhaps better to do that than to
> flip all the data.
> 

It is really not that hard to use with a 68000.  Since the 82586
has a multiplexed address/data bus, you have to have address and data
latches anyway to demultiplex the bus. (also true of the LANCE)
The data latches can be used to always swap the bytes. 
It does confuse the control block programming, but
this doesn't turn out to be so terrible.  The flag bits are no problem,
since they can be defined as C bit fields, but the addresses do have to
be swapped.  Even if the the byte order within a word could be programmed,
the software would still have to take special precautions with the
24 bit buffer addresses, since the highest byte in the address is at the
highest address.  In any case, it is a pain, but one that is very easy
to localize and be done with.

You are certainly right that the data should be swapped in hardware.

All of your points are correct, but I believe you err in your fervor.
My experience with the 82586 has shown that its problems are not
insurmountable, nor do they cause negative impact on system performance.
And, I emphasize, despite its complexity, it did beat the LANCE to
market by more than a year.  (Yes, the SEEQ chip was there even sooner,
but it requires a LOT of external hardware if you want to receive
back-to-back packets).

I suspect that making the parameters software-settable was no harder
that hardwiring them into the mocrocode.  And, if Multibus II systems
end up using the part for talking to the Multibus II serial bus,
it may turn out to have been a good move by Intel.

Cheers,
Mitch Bradley