Packet Driver for BICC 4110-2 AT and MCA controllers

ISOLINK <packet_int_no> <options>
  options: [defaults]
    /I<hw-int-level> [2]
    /P<I/O port address> [280]
    /D<DMA channel #> [0]
    /R<# recv buffs> <recv buff size> [16 256]
    /T<# xmit buffs> <xmit buff size> [1 0]
    /X

The /R option specifies the number of buffers the driver reserves for
the Lance chip.  If a buffer is too small, the arriving packet
overflows into the next buffer until the packet is received
completely.  If all buffers are full when a packet arrives, a MISS
error occurs and the packet is effectively lost.  Nothing can easily
done about this.  The error is indicated by incrementing error_in
count which can be displayed with a packet driver statistics program
(like FTP, Inc.  INET DEBUG or Russ Nelson's STAT).  The default
chosen may be to small...

The /X option instructs the driver to relocate itself and all buffers
into the first segment in extended memory (HMA - still addressible in
real mode).  The driver uses Microsoft's HIMEM.SYS to enable the
chip's A20 address line.  HIMEM.SYS is available from Microsoft (I
think it's automatically distributed with Windows/286) or from the
SIMTEL archives.  The A20 line is enabled once and left enabled
PERMANENTLY, a technique Microsoft explicitly discourages! According
to them certain applications rely on 1MB memory wrap.  I suggest to
avoid such applications anyway.  Specifying the /X option allocates
the HMA to the driver who does not necessarily use it most
efficiently; it is then unavailable to other programs (e.g.  Windows)
who could make better use of it. With the /X option the driver uses
all the remaining HMA for receive buffers (largest number of buffers
at least as long as requested).

The /T option specifies a number of transmit buffers.  If the outgoing
packet fits into a single buffer, it is copied and the Lance
instructed to send it out.  The network application resumes
immediately in this case.  If the packet does not fit, it is sent
directly from the user supplied address and the driver waits until it
has been sent out.

On the PS/2 the configured values for /I and /P replace the defaults
indicated, so that it does not make sense to specify them.


PROBLEMS
========

Still to be done:
  - Errors are counted in a rather primitive manner
  - terminating the driver does not reset the Lance chip and
    does not free the HMA
  - could one do useful things while waiting for the packet
    to be transmitted?


I'm too busy on other things to chase a persistent bug in the
driver: when using NCSA telnet to a VAX 8530 running Ultrix and doing a
'ls -l /etc' the session hangs. Tracing shows the VAX keeps sending
packets from time to time, and the driver upcalls the handler routine
but nothing happens. Perhaps a packet lost/corrupted somewhere.
I'm afraid this may also happen in other circumstances.
Perhaps somebody will fix it some day. Alas, I probably won't!


Anyway, feel free to send comments or suggestions to rtb@cernvm.cern.ch