This is a very basic driver for the old Xircom cards, developed
using data gathered by spying on port communications (thanks go to
dosemu developers for including the port tracing facilities) 
and a good amount of experimenting.

I asked Xircom for the specs, but there was no response
and their web site states that they will not release
specs of obsolete products. Go read the site, the
reasoning is interesting and you might like to let
them know what your opinion is.

The driver is most probably hopelessly inaccurate in guessing
the meaning of the bits, contains a horrible timeout hack
repairing lost events, ignores locking issues, doesn't report
collisions and other errors and is not particularly effective
(measured speed 800 kB/s for receiving, but only 250 kB/s
for sending - no doubt there is a reason for the hiccups
the timer repairs, but I have no idea what it is). But hey,
it works for me.

This driver is free software; see source code for licences.
As usual, there is ABSOLUTELY NO WARRANTY and I will most
probably not develop it any further - I just wanted to
make use of some old card and to learn something new.

All code except direct interfacing with the card was
written by the authors of xirc2ps_cs driver - see xirc2ps_cs.c
from the pcmcia package for full details and credits.

                                 Stanislav Meduna
				 stano@trillian.eunet.sk
				 http://www.penguin.cz/~stano



Following text summarizes the data I was able to gather.



Card data:

Xircom, CreditCard 10Base-T, CE-10BC, 2.0/0008015396-012094,
0x105, 0x108

The ports are 16-bit. A 16-bit I/O on reg. x is equivalent to
8-bit LSB x and MSB x+1.

I/O ports (offset from base)
============================

Port  0:
-------

Looks like status register. On read the current status is
read. On write the 1 bits clear the set bits and (maybe)
define, which events we are interested in.

Star means the bits set by original drivers:

* bit 15: packet received
  bit 14:
  bit 13:
  bit 12:
* bit 11: some status change, goes active e.g. on cable disconnect
* bit 10:
* bit  9:
* bit  8: once seen, but no idea what it is
* bit  7: packed transmitted
  bit  6: goes active on cable disconnect and (maybe) on failure
          to send for whatever reason. It is not event-oriented,
	  e.g. on cable disconnect it stays active also after an ack.
  bit  5:
  bit  4:
  bit  3:
* bit  2:
* bit  1:
  bit  0:


Port  2:
-------

No idea, maybe interrupt-related. The original drivers set
this to zero before sending a packet and to 0x828f after
the card is filled with the packet data.

The last written value can be read subsequently, so it
probably does not report any status back.

Port  4:
-------

Some status register. Numeric values state the value
that was read every time.

  bit 15: 0
  bit 14: receiver buffer empty
  bit 13: 0
  bit 12: 0
  bit 11: 0
  bit 10: 1
  bit  9: 1
  bit  8: 0
  bit  7: 1 immediately after reset, 0 everytime else
  bit  6: 1 immediately after reset, 0 everytime else
  bit  5: 1 immediately after reset, 0 everytime else
  bit  4: 1 immediately after reset, 0 everytime else
  bit  3: 0
  bit  2: 0
  bit  1: 1
  bit  0: 0

Port  6:
-------

Some control register. Numeric values state the value
used by the original drivers. The register remembers
the last value written with the exception of bit
12, which always reads one).

  bit 15: zero for 10Base-2 (the CESETB2 tool sets this bit
          to zero and when set to one, there is nothing
	  send/received)
  bit 14: 0
  bit 13: 1
  bit 12: see below, always reads as one
  bit 11: see below. When set to 0, nothing is sent, after
          setting to 1 the bytes are sent. The packet
	  seem to be buffered when zero.
  bit 10: see below
  bit  9: 0
  bit  8: 0  setting to 1 affect send
  bit  7: reset (see below)
  bit  6: 1
  bit  5: 0
  bit  4: 1
  bit  3: 0  when set to 1, all pauses for ca. 4 seconds
  bit  2: 1  setting to zero affect send
  bit  1: 1
  bit  0: 0

The sequence on reset used by the original driver is following:

  bit  7 _|~~~~~~~~|__|~~|______
  bit 10 ____|~~|_______________
  bit 11 _______|~~~~~~~~~~~~~~~
  bit 12 ________________|~~~~~~

           ^  ^   ^
	   |  |   |---   port 11      loaded with 7 (no idea what this means)
	   |  |-------   port  8 - 15 zeroed (no idea)
	   |----------   port  8 - 13 loaded with MAC, first byte in 8



Ports 8 - 15 seem to alternate meanings according to control
bits in the register 7. The following is valid for normal
operations.

Port  8:
-------

Data register.

Write: 16-bit length to port 8, followed with length/2 of data.
       Then commit the packet using port 10.

Read:  If bit 14 of port 4 is zero, following can be read
       16-bit flag (no idea wht is here, but it has always been 0xXX20
       16-bit length
       data

If the length is odd, the last byte can probably be sent/received
using 8-bit I/O.


Port 10:
-------

Send command register. The packets are sent using 0x81 to
8-bit reg. 10:

  bit 7: send the packet (when 0, it will be buffered)
  bit 6:
  bit 5:
  bit 4:
  bit 3:
  bit 2:
  bit 1:
  bit 0: send the packet. If zero, all buffered packets will be
         sent, but then nothing more happens and bit 11 of port 0
	 goes to 1. If one, the last packet will be send and
	 the transmission will be acked by bit 7 of port 0.



Memory registers (offset from base)
===================================

Memory 0x806:

Must be written at least once to enable card's operation.
Original drivers write e.g. 0x55 here.

  bit 7:
  bit 6:
  bit 5:
  bit 4: must be 1 to enable LEDs
  bit 3:
  bit 2: enable interrupts
  bit 1: green LED
  bit 0: orange LED