Excelan boards

[tcs%usna.uucp at BRL-BMD.ARPA]

Several people wanted info on the Excelan boards when we got ours
working.  Well, one of ours is definitely working and I'm fixing
software  (2.9BSD) for the others.  Since I'll be away during the
holidays, I thought posting this now would be helpful.

We have three boards, one in a Vax 11/780 and two in pdp11's.  The Vax
is running 4.2 and the 11's are running 2.9.  I have installed the
Excelan card in the 4.2 system and the driver supplied by Excelan
seems to work fine!  I say seems because I am in the process of
installing the 8010 on-the-card TCP/IP software in our pdp11's and don't
have any other systems on the cable.  I have been able to run ttcp
(Test TCP program; I have a 4.2 version) and have the vax talk to itself
via the interface. The 4.2 driver is available for the asking from
Excelan.  Requests should go to excelan!george (George Powers).  George
claims that they have measured performance on the order of 600Kbits/sec
and are working on improving it.

The card uses message buffers to communicate with the host (like
the DEC DEUNA, except a queue for each direction) and has
a programmable interrupt vector (like dmf32's).  This insulates
the programmer from changes in the hardware.  It is a quad sized,
6 layer pc.

Now, about the 8010 protocol software.  It looks reasonably good
(to a novice, anyway).  I am having some problems getting it to
run on 2.9 though.
1. 2.9 edits the assmebly output of the c compiler to convert spl(x)'s
into in-line code for speed.  The compile rules for the drivers (yes,
it is actually 5 drivers for various functions) had to be changed
in the Makefile to do the same.
2. The drivers use buffers stolen from the disk cache.  Since the
systems they were written for don't have (or use) b_xmem (from buf.h),
a significant number of changes need to be made to run on a pdp11.
I am in the process of doing that now.  If one were to use internal
buffers, this could be avoided, but that would limit its portability
since other pdp11 sites may not have enough kernel data space available.
3. 2.9 also maps the buffer cache out of kernel space.  Any time a
the data in a buffer is referenced, the buffer must be mapped in and 
mapped out.  Using dedicated buffers in the drivers would eliminate
this.
4. Since 2.9 has network header files, etc. some of them conflict with
the header files in the 8010 software.
5. The 8010 software uses the 4.1c semantics.  George tells me that
they are working on a 4.2 version.

Porting the 8010 software to a more reasonable architecture than the pdp11
should be easy.  It seems that most all the newer systems don't
use b_xmem at all and b_un.b_addr is a long.  Does anyone know
of any systems where that isn't true?

Overall, I'm impressed at the intermediate evaluation stage.  I'll
post additional info after our network is running.
	-tcs