On Sat, 17 Apr 1999, Riley Williams wrote:
> Hi Luke.
>
> >>> 1. You refer to an "NE2000" card. Presumably you're aware that
> >>> those normally don't work in an XT as they require an AT style
> >>> connector and the similar NE1000 card with its XT style
> >>> connector has to be used instead.
>
> > My main concern for development is to have a card which:
>
> > Most people can get hold of, or already have.
>
> I can't speak generally, but certainly in this part of Scotland, and
> in the south Lincolnshire area of England, clones of both the NE1000
> and NE2000 are easily available. However, according to posts I've seen
> on the Linux-Kernel mailing list, NEx000 clone cars are essentially
> unknown in the USA, and the varius 3Cxxx cads are the ones that are
> easy to get hold of...
>
> > Will work with my hub.
>
> In that case, were you aware of the following:
>
> 1. The basic difference between an NE1000 card and an NE2000 card
> is that the NE1000 ports have to be read in 8-bit chunks, and
> the NE2000 ports normally have to be read in 16-bit chunks.
>
> 2. Both NE1000 and NE2000 cards come in thee following varieties
> (most of which I have examples of):
>
> 1. BNC connector for coax segments at 10 Mbps.
>
> 2. RJ45 connector for CAT-5 cable at 10 Mbps.
>
> 3. 15-pin D-type connector for whatever suits.
>
> 4. Any two of the above, selected by jumpers.
>
> 5. Any two of the above, auto-detected.
>
> 6. All three of the above, auto-detected.
>
> As a result, your second concern is basically irrelevant.
None of 4 my ne1000's, nor any I have ever seen have RJ-45 connectors.
>
> > An ne1000 driver can be done later, but to make sure that
> > everybody can join in for now, the more popular the card the
> > better.
>
> That sort of decision appears to be a geographically based one, so may
> not produce the result you are expecting...
An ne2000 is a lot easier to get hold of than an ne1000
> > To start with, I intend to write the driver, and then some code
> > that will tell me when a packet has arrived, if it is for this
> > machine, and what protocol it is using. And I'll go from there.
> > (I haven't read that far ahead ;-)
>
> Probably a better decision would be to split networking into two
> layers, with the upper layer doing everything that can be done without
> accessing the card itself, and the lower layer doing only that which
> can't be done without accessing the card...
That is what I meant. There is no point at all having some generic code
being re-written. So that when a packet comes in, the driver passes
strait to the function that decides if it is at the right machine.
The whole picture comes in several layers.
Luke(Boo) Farrar.
