Doom Fever/Doom_Fever-1995_Maple_Media.iso/dmutil/drivers.zip/3C503.NOT

Text File | 1989-07-29 | 6KB | 132 lines

README.503
27 July 89
Bob Clements, K1BC
[Updated: 27 July 89 for thick/thin Ethernet choice.]

This is the README file that goes with the 3C503 device driver,
3C503.ASM and 3C503.COM.

I wanted to include this file for two reasons:
   1) to give credit where credit is due, and
   2) to say something about this implementation's details.

CREDIT WHERE CREDIT IS DUE:

The ancestry of this driver is as follows.  The effort was inspired
by Phil Karn's TCP/IP implementation, NET.EXE.  Phil included a
built-in driver for the 3C501 in early versions of NET, up to around
version 871225.30 or so.

I wrote a driver (in C) for the WD8003E which I released in
version 871225.25.EW.  I based this on technical information which
my dealer, Ken Hahn of Micros Unlimited in Woburn MA (a 3-Com
network distributor), was able to get from Western Digital after
some effort.  Credit to Ken and to Western Digital.

Shortly after that, Phil saw the need to support more devices without
modifying NET.EXE and he decided to do it by way of the "Packet
Driver" specification publicly promoted by FTP Software of
Cambridge MA, to whom we owe due credit, too.

Russ Nelson at clarkson.edu began implementing and collecting
drivers written to that specification, including a derivative of
Phil's 3C501 driver.  Russ wrote the outer levels of the driver
to meet the FTP Software spec.  Credit to Russ for that and for
the job of collecting other drivers to go with it.

I rewrote the built-in C version of the WD8003E driver in
assembler, fitting it into Russ's structure (as a TSR),
and released it back to Russ for inclusion in his collection.

I wanted to write a version for the 3-Com 3C503 because the 3C501
was continually rumored to be becoming obsolete.  Further, since
it uses the same National DS8390 controller chip as the WD8003E,
I figured it couldn't be TOO different.  Ken and I had been unable
to get programming info for the 3C503 through sales channels or
usenet.  I lamented this fact publicly in early December on usenet.
3-Com saw the note and immediately provided the necessary info
to me.  They sent me a pre-publication draft of the 3C503's
technical manual and some sample code for a different environment.
Credit to 3-Com in the persons of Jack Moses and Eric Siegel.

After a delay due to vacation (K1BC/KH6), winter lethargy and
work schedules, I finally got around to writing the driver in
February 1989.  Sure enough, it wasn't TOO different from
the WD8003E driver.  But see the next section.

To all the above named persons, "Thank you".


DETAILS ABOUT THIS IMPLEMENTATION:

The 3C503 is rather versatile.  It allows you to move packets to/from
the card in three ways:  1) By a shared memory buffer;  2) By using
a DMA channel of the PC bus;  3) by I/O instructions per byte or word.
As it comes from the factory, the card has the shared memory jumper
set to "disabled".  This probably prevents phone calls from people
who have address conflicts with their video cards or disk bootstraps.
3-Com's software includes code to handle all three cases, depending
on the rest of the configuration.

I chose to implement ONLY method 1 above for this initial version
of the driver.  Not only is this the fastest transfer method but
it is the method used for the WD8003E driver that I did before.
So I had less work to do.  You MUST set the shared memory to one of
its four possible enabled addresses.  Pick one that doesn't conflict
with your other hardware.  The segment numbers available are:
c800, cc00, d800 and dc00.  The driver can read your selection
from the card, so you don't have to tell it.

The 3C503 has jumpers for the above memory addresses and for the I/O
port addresses.  It occupies a block of 16 addresses at one of a
number of jumperable bases.  The default is 300.  You can change
it if you have to.  Supply the actual address as an argument
when you start the driver.

The 3C503 interrupt level is programmable.  No jumpers.  Only
levels 2,3,4 and 5 are supported by the hardware.  Tell the driver
what level you want as an argument when you start the driver.
The default level is two.

The card has both a thin-net (coax) connector and a thick-net
(external transceiver) connector.  The selection for which
connection to use is done by software.  No jumpers.  In the first
version of this driver, I failed to provide a way to select
which connection to use, and I got a lot of email about that.
Now, you select which you want by a flag on the command line
after the I/O port address.  A zero means to use the external,
thick-net, connector.  A non-zero number means to use the coax
connector for thin-net.  The default is to use thin-net, which
was the only choice on the old driver.

I start the driver on my system with the following line:
    C:>  3c503 0x7e 2 0x300 1
which means "Install on software interrupt 7E (for NET.EXE to use),
use interrupt level 2, find the board at ports 300-30F, and
use the thin-net coax connector".


There are differences between the way WD's and 3-Com's software
handle the DS8390.  I changed some of them over to 3-Com's way
for this driver and left some as I had them in the WD driver.
So far, they seem to be working OK.  For one thing, they treat
the "boundary" register differently.  Details available on request.

3-Com also includes a lot of garbled-packet detection in their
driver, based on their experience of failures of the DS8390
under heavy load.  They describe some pretty bizarre things.
I have not included that logic in this driver, since the IP and
TCP checksums should save you in the applications I am
writing for.

So my point is that this driver is not as complete an implementation
as the one 3-Com provides for their network systems.  I take the
blame for these compromises.

Note added July 1989:
This driver now supports the set_rcv_mode function of the packet
driver spec, but does not yet support set/get_multicast_list.

Bob Clements,  K1BC,  [e-mail],  [e-mail]