The CS8900 is a Ethernet MAC chip - it handles the Ethernet layer. This includes received packet filtering, collision detection and recovery, media access and checksum generation. It also handles the line interface stuff like encoding and much of the filtering. You can see from the simplicity of this design it is a comprehensive chip that requires very few support components.
The CS8900 is actually designed to drop directly onto an PC's ISA bus with no support components. It has all the ISA address decoding inbuilt. This is why you will find that A8 and A9 are held high and all other address lines (except those addressed by the hc11) are held low. The default base IO address of the 8900 is 300H (this is a common IO range in the ISA bus). In ISA designs you need to add a serial EEPROM to store config information (inc. the IO base address when you change it from 300H). This is not needed for hc11 designs as we can store it all in the hc11 and init on startup. In the application notes they even give an ISA PCB layout - even your local used car salesman could roll out Ethernet cards using the info they give (they supply drivers for most OS).
In addition to ISA support, with DMA and all the things needed for a decent (in ISA terms) transfer rate, the kinds folks at Crystal (now Cirrus) included an 8 bit mode in the CS8900. This design uses the chip in 8 bit mode. There is a brief, but sufficient Cirrus application note (AN181) for using the 8900 in 8 bit mode.
The CS8900 chip's 8 bit mode has many limitations, the end result of which is you will never get a data high transfer rate. There is no DMA, no interrupts (they say, although I think you might be able to do it still) and you have to read the packets out of the chip byte by byte.
All this is fine for the kind of applications that an small micro like the hc11 or 8051 targets. I initially set the packet size limit to 256 bytes, but BOOTP uses something bigger as a minimum so I moved to 512 bytes.
If I'm too brief for you here, read the 8900 documents - there are many of them and they have all the detail you need. There is an series of articles in Circuit Cellar starting in issue 122 (September 2000) about using the CS8900 with a Rabbit development kit.
There are several interfaces detailed to different host CPUs here. As you can see from the circuit diagram there are very few components. The majority of the bus control signals on the CS8900 are held inactive. These include - D8-15, MEMR, MEMW and DMA request signals. The address bus is tied to decode 300H-30fH as 0H - FH (A0-3 connected to the CPU, A8-9 tided high, A4-7 & A10-19 tied low) The Reset, AEN, IOR and IOW are driven by a GAL for flexibility.
The remainder of the circuit is straight from the CS8900 application notes - refer there for more details. The line isolation and interface components comprise most of the circuit with some biasing components. There is also a liberal quantity of power supply decoupling capacitors. Finally a pair of LEDs are included to give link and traffic status.
Packets are received and buffered by the CS8900. The software polls the receive status bit and responds when the 8900 receives a packet.
Ethernet II packets are fairly simple in structure - I'll be brief here, there is more detail in the references given below. The packets have a destination address, a source address, a protocol type and a checksum. In this design we tell the 8900 to check and discard the checksum - packets that fail checksum are also silently discarded.
In this design we tell the 8900 to listen for broadcast packets (destination address of FF:FF:FF:FF:FF:FF) and packets targetted our MAC address. As part of the initialisation process we program our MAC address into the 8900. Ethernet board manufacturers register for a range of MAC addresses for their boards - each board is supposed to be unique. Normally the MAC address would be stored in the EEPROM. Since this is a hobby design you get to choose one and we program it directly on startup. Currently this design uses 54:6F:6D:28:__:29. The __ is determined by reading the lower 4 bits of port E to create a node ID (port E floats low so the default is 0). The value is converted to an ASCII representation of the value - node 0 has a MAC address of 54:6F:6D:28:30:29, node 1 has 54:6F:6D:28:31:29 etc. The ASCII of this is "Tom(0)" and "Tom(1)" - change it to suit your needs. This allows multiple boards on the same network with the same code, all you need to do is set the node id differently.
I mentioned above that we receive ethernet broadcast packets in addition to packets targeted to our address. Broadcast packets are used for lots of things in ethernet, one of the uses is to locate a device on the network (see ARP below). A limitation of this design (and the 8900 in 8 bit mode) is that it will struggle survive on a busy network. This is because if the number of broadcast packets is too high the device will be flat out reading them out of the 8900 and the receive buffer will overflow. There is no choice here unfortunately, you can't effectively do TCP/IP over ethernet without ethernet broadcast packets.
So, in summary we receive all ethernet packets destined for our MAC address and broadcast packets.
Packet Transmission is fairly simple with the CS8900. The hc11 tells the 8900 the length of the packet and the waits for space in the internal buffer. Once space is available the packet is written, byte by byte into the 8900. The 8900 has been configured to start sending the packet when all bytes have been received (it can start earlier if you can write that fast which we can't). The 8900 handles media access etc. and sends the packet when the network is idle.
ARP is a protocol used to locate IP addresses on an ethernet network. ARP request packets are sent to the ethernet broadcast address requesting the MAC address of a known IP address. This design implements a simple singel entry ARP table. It remembers only the last ARP response, if sending to a new address, it must first ARP that address.