The target platforms for a WIZnet stack are the various MCU families, like PIC's, AVR's or ARM's. A hardware stack does the work of the lower layers and the controller can do its application without restrictions. Hardware-based TCP/IP-stacks consume less memory and do not need high system-performance for a liquid work of the entire system. The conditions in small 8-bit controller systems are the same as in my Z80-based system : a maximum of 64 kB memory and low clock rates.

WIZnet made the following test in order to demonstrate the advantages and capabilities of the W5100, a W3150A+ gives the same performace. A program is running in the MCU, which echoes all data sent from a PC program, which calculates the bitrate. The table lists the Data-Throughput in Mbps of the chip on the application layer:

The controller of my experimental board is an ATmega 162 with 8 MHz, so the measured values should be similar in my case. This means for the project that the chip is very fast in the network! The Z80 system itself is probably the slowest link in the chain of transmission, as I already had suspected.

How does it works? The W5100 is in the address space of the controller, and can be addressed from 8000H - FFFFH. All given addresses of the memory map or datasheet has to be added an offset of 8000H. This must be done because of hardware requirements. Now could a controller-application write or read the W5100, and thus use the TCP/IP stack like the driver and example programs provided from WIZnet do.

See the following picture:

But that was not my goal : I wanted to program the stack by myself with an application running in the Z80 system, a native solution without programming restrictions! The link between the W5100 and the Z80 must look like the chip would be directly in the Z80 address space. Then, a network application can run in the Z80 system and the W5100 executes all network protocols of the TCP/IP-stack from the transport layer downwards.

The first obstacle was the electrical problem. A W5100 has a standard MCU bus interface and my system has a standard Z80 bus. Both are not compatible and cannot be connected directly. But the ATmega 162 has the necessary MCU bus interface and there was one big advantage : it was tested with the connected W5100 and it functioned. Never touch a running system! So this problem was solved by the experimental board itself.

Since the stack is like memory, all programming is done through read and write commands from the controller. When writing an address, you can trigger actions or put data on the stack. When reading an address, you can get status information or read back data from the stack.

A Z80 does this reading or writing of addresses exactly in the same way in its own address space and the 8-Bit controller ATmega 162 is fully compatible with the Z80 in reading and writing. It uses 16 bits for an address, 8 bits for a data byte and is working with Little Endianess in the organization of data in memory, so that is the ideal extended workbench for the Z80 system :-).

This consideration turned into the basis idea of the KCNet interface. All application and driver software can be done in the Z80 system, which works with the virtual addresses of the controller-system. Directly before the physical read or write commands are executed, the address and/or data have to be transfered to the controller-system unchanged! Then, the ATmega reads and writes the chip addresses of the W5100 in the MCU system and gives data back, if required.

What are the advantages of this approach:

• I didn't need other hardware, because the tested controller board met my needs :-)
• the Z80 software does the logical programming of the TCP/IP-stack, not the controller : I have my native Z80 solution
• I do not need real memory space of the Z80 system for a possibly direct connected WIZnet-stack (that would require much more additional hardware!)
• address- or data-structures of the Z80 system need no conversion, they can be transfered 1:1 and used from the controller directly, this ensures a high speed in the execution of commands
• every existing programming environment and language of the Z80 system is usable

The KCNet-Interface changes the WIZnet model.

"Application", "Socket API" and "Driver Program" run in the Z80 system. The KCNet hard- and software handles the transfer and execution of write- or read-commands. This is done at the lowest possible level, between the "Driver Program" and "MCU Interface".

The red line in the following picture indicates the location of the chain, where the transfer is carried out:

Since the ATmega reads and writes the chip addresses of the W5100, I had to connect the Z80 system with the MCU system. This connection had to be as fast as possible, to maintain much of the high W5100 data-throughput! In order to be universal and absolutely compatible with each Z80-System, only a standard-circuit of the Z80 family was acceptable for the link to the ATmega.

Because no peripheral interfaces with Mbps data-rates exist for my old system, the Z80-PIO came into the game at this point. This decision was taken very quickly, my Z80 system with 1,77 MHz clock rate is the bottleneck of the entire transfer-chain. In order to gain a certain usability of the network for the user, at least 10 kByte/s transaction rate was the aim. A Z80-SIO is not possible here, only with a fast parallel protocol were rates greater than 10 kByte/s feasible.

Now, the interface was complete with the PIO-ATmega connection. They communicate bidirectionally. The Z80-PIO is used in Mode 2, and the ATmega software emulates the PIO hardware-handshake protocol.

The next picture shows the lowest level of the KCNet hard- and software. All programs at the Z80 side use the Low-Level Interface-Driver KCN-ZPIO.INC for the communication. The ATmega software on the other side waits for commands, in order to read or write the physical addresses of the W5100: