This project has been discontinued. The eth64 driver has been migrated into the sixnet project and donated to the Style SVN. The netlib will continue to support eth64 and source snapshots will be available upon request.

RR-Net support is functioning. Now on to IP.

I have added a current source snapshot to the site. This should allow for easier testing/evaluation.

IP and ICMP sources are begun. I am working towards a common architecture, so that new protocols will be easier to implement. My plan is that all of the overhead that CAN be handled by a single layer, WILL be handled by a single layer. For example, to send an ICMP message should only require the ICMP layer to build the ICMP part of the packet, while the IP layer builds the IP part of the packet, and the MAC layer builds the MAC part of the packet.

Today's Sources - REMOVED

The ARP system now detects and responds to incoming ARP requests, and will build and send ARP requests, as well as

Today's source, DASM compatible: ARP.asm

Started working on an ARP engine. It's heavily commented for those of you who are still working out how ARP works (like me until yesterday.)

Today's source, DASM compatible:REMOVED

After some difficulty with trying to adapt the routine from the uIP/Contiki Driver to work with some ARP source I was building, I decided to stop and simply write a packet_write demo routine just like the packet_read demo from yesterday. It simply writes a pre-built packet (In this case, and arp request) to the card and sends it. I picked it up with my network protocol analyzer (I use WinPCAP and Analyzer)

Today's source, DASM compatible: write.asm

Today I mounted my ETH64 and DUART in a single package with PC mobo risers. It looks nice and keeps the ETH and DUART from shorting on one another. I REALLY need to build a nice case for all of this.

I found a bug in my source. It didn't set the bank properly. For your enjoyment, my current source is now available. It initializes the card, reads packets in promisc mode, and dumps them to the screen. It picks up broadcast packets on my LAN. Your feedback would be appreciated.

Today's source, DASM compatible: read.asm

To initialize the card, the uIP driver does the following:

• First, check to see if the high-byte of the Bank Select Register returns #$33. This is done to verify that the card is actually present. From the chip's datasheet, page 41: "The upper byte always reads as 33h and can be used to help determine the I/O location of the LAN91C96"
• Next, it writes #$8000 to the Receive Control Register. This causes a soft reset. From the chip's datasheet, page 46: "SOFT_RST - Software activated Reset. Active
  high. Initiated by writing this bit high and terminated by writing the bit low. The LAN91C96 configuration is not preserved, except for Configuration, Base, and IA0-5 Registers. The EEPROM in both ISA and PCMCIA mode is not reloaded after software reset."
• The reset is completed by writing #$0000 to the Receive Control Register (see above)
• The system pauses for 4.4 ms
• Transmit is enabled by writing #$8001 to the Transmission Control Register. This sets FDSE and TXENA, which sets Full Duplex switched ethernet mode and enables transmission. From the chip's datasheet, page 42: "FDSE - Full Duplex Switched Ethernet. When set, the LAN91C96 is configured for Full Duplex Switched Ethernet, it defaults clear to normal CSMA/CD protocol. In FDSE mode the LAN91C96 transmit and receive processes are fully independent, namely no deferral and no collision detection are implemented. When FDSE is set, FDUPLX is internally assumed high and MON_CSN is assumed low regardless of their actual values." and from page 43: "TXENA - Transmit enabled when set. Transmit is disabled if clear. When the bit is cleared the LAN91C96 will complete the current transmission before stopping. When stopping due to an error,
  this bit is automatically cleared."
• Next, receive is enabled by writing #$0300 to the Receive Control Register. This sets STRIPCRC and RXEN, which strips CRC's from incoming packets and enables reception. From datasheet page 46: "STRIP_CRC - When set it strips the CRC on
  received frames. When clear the CRC is stored in memory following the packet. Defaults low." and " RXEN - Enables the receiver when set. If cleared, completes receiving current frame and then goes idle. Defaults low on reset."
• Next, #$1000 is written to the Configuration Register. This turns off wait states. From datasheet page 50: "NO WAIT - When set, does not request additional wait states. An exception to this are accesses to the Data Register if not ready for a transfer. When
  clear, negates IOCHRDY for two to three 20MHz clocks on any cycle to the LAN91C96."
• Next, $0900 is written to the Control Register. This turns on auto-release. From the datasheet, page 54: "AUTO RELEASE - When set, transmit pages are
  released by transmit completion if the transmission was successful (when TX_SUC is
  set). In that case there is no status word associated with its packet number, and successful packet numbers are not even written into the TX COMPLETION FIFO."
• Next, the MAC Address is set by writing it to the Individual Address Registers. From datasheet, page 52: "These registers are loaded starting at word location 20h of the EEPROM upon hardware reset or EEPROM reload. The registers can be
  modified by the software driver, but a STORE operation will not modify the EEPROM
  Individual Address contents. Bit 0 of Individual Address 0 register corresponds
  to the first bit of the address on the cable."
• Finally, #$0f is written to the Interrupt Mask Register. (See datasheet page 66)
  

Before I set out to write something useful for this device, it seems I should find a beginning point. I suppose a good place to start would be with AD's ETH64 driver. It seems to have all of the basics that I need, an init routine, a poll/read, and a packet write. Unfortunately, it is written in C and for uIP/Contiki. I will have to translate it to something useful (to me, anyway). In this case, my development environment consists of the following:

• Windows-based PC with DASM/Textpad for editing/compiling
• C2N232/c2nload for getting binaries onto the 64 -9/09/04 - Now use DUART/PCServer
• PAL C64C w/IDE64 and ETH64 for testing

Having purchased an ETH64 from Greg Nacu at the SWRAP 2004 Expo (pics), I set out to make it useful. Fortunately for me, most of the hard work has already been done. Doc Bacardi had already done extensive work with the RR-Net, all of which can easily be ported to work with the ETH64 instead (Doc writes beatiful, modular code). Also, Adam Dunkels had already built a TCP stack, and some network apps under Contiki.