The possibility exists certainly, several solutions are known for 8-bit systems.

TCP/IP

The following article gives a short overview and should not be exhaustive. I will show the problems of existing TCP/IP implementations and explain the advantages of the KCNet-interface for my needs in an usual home network.

In principle, this subject has interested me for long and I have pursued the development very carefully for many years. Since 1996 I use the internet, I built my first BNC home network with 5 PC's and a Linux softwarerouter behind the cable-modem 2002. Today I drive a Gigabit home network with its own network-server and VoIP-hardwarerouter with WLan.There are 8 PC's in the network, which has a 16-MBit ADSL-connection to the internet.

The only thing missing in the home network was my KC85 system!

If you want to build a network, you must know, how to do it. If it works, you want to know how the technology behind it operates. Sometime, you are interested in the software also and come to the TCP/IP stack inevitably. Then, you must work through a lot of theory and unfamiliar names and terms, before you understand how the components work with each other. Therefore, the following pictures summarize the most important things and concepts shortly.

There are masses of documents about this topic in the internet. Very good and extensive overviews can be found for example at:

The TCP/IP Guide http://www.tcpipguide.com/free/index.htm
IBM Redbook "TCP/IP Tutorial and Technical Overview" HTML/Java version
Microsoft TechNet Library TCP/IP Fundamentals for Windows

 

OSI model


The OSI reference model is the fundamental networking model. It was published in 1984 by the ISO as standard ISO 7498. The model is a very useful tool for education and development. It defines a set of layers and a number of concepts for their use, that make understanding networks easier.

OSI splits the entire "network monster" in layers with individual tasks. Each of the modular components is responsible for a particular function. The particular function of one layer refers specifically to a set of communication rules, instructions and/or procedures. They describe the communication between specific software or hardware elements, running at the same layer on different machines within a network : the horizontal communication protocol of corresponding layers.

Interfaces are between the layered components for data transfers in both directions. Vertical communication is done up and down the protocol stack, every time anything is sent or received across the network. This occurs because the higher levels are implemented as logical functions in software. There is no actual physical connection.

TCP/IP Stack

In the case of a TCP/IP network, the TCP/IP reference model is used in discussions of this suite. It has many similarities to the OSI model, but also some differences. TCP/IP in general, covers many layers of the OSI model and provide services to other protocols, as well as services provided to end users directly.

The protocol services consist of the core functions, implemented by the main TCP/IP protocols: IP, TCP and UDP. These services are designed to actually accomplish the internetworking functions of the protocol suite. The IP protocol provides functions at Internet layer 2, such as addressing, delivery and datagram packaging, fragmentation and reassembly. TCP and UDP are concerned at the Transport layer 3 with encapsulating user data and managing connections between devices. Higher layer protocols use these services, allowing them to concentrate, on what they are intended to accomplish.

The other general types of service provided by TCP/IP are end-user services. These facilitate the operation at the Application layer 4, like www,  that users run to make use of the power of the Internet and other TCP/IP networks.

The function of the Network layer 1 and how it has to work, is not exactly spezified. It makes use of other existing protocols like Ethernet or Slip. The network layer protocol defines, how a host must be connected to a network for the transmission of IP-packets.

Data Encapsulation

Data Encapsulation is the hell of data flow through the layers. Every layer protocol adds / removes its own information as header in front of (or footer behind) the data of the next upper or lower layer. The entire contents of the higher layer message are encapsulated as the data payload of the message at the lower layer.

Addresses

An Ethernet-based TCP/IP network needs 4 addresses to transport data, from the Ethernet-line up to the Application layer and vice versa. This is very confusing for beginners, but necessary to implement the OSI model with independent components:
  1. physical  network address (MAC) on the network layer
  2. internet address (IP) on the internet layer
  3. transport protocol number on the transport layer
  4. port number on the application layer
Every network data packet finds the right way through TCP/IP networks with the help of these 4 addresses.

Terms

TCP/IP speaks its own language. Many terms there are for the unique identification of data in the individual layers. With such a specific term, it is clear where the data are in the TCP/IP stack, and what structures and contents they have. The picture shows the important terms for an Ethernet network.

KCNet Project

Because of the long preparatory period, I had enough time to think over a solution. In 2007, the following development goals were defined for the KCNet - Project:

  1. freely programmable TCP/IP stack without restrictions
  2. lowest possible memory usage
  3. low system load through the stack itself
  4. high stability and reliability
  5. standalone solution without other computer or server
  6. low system load through network activity
  7. high-speed transfer of data between host to host applications
  8. low response time and a felt fast interface for the user
  9. universal communication with hosts in- and outside the local network
  10. easy implementation of standard RFC-protocols
  11. convenient API for network programming on all layers
  12. interface-compatibility with as many Z80 systems as possible
  13. no need for login and/or authentification and a permanent connection for sharing data in the network
The feasibility of the first five goals was an absolute requirement for the start of the project, the rest falls in category "nice to have".

In the last years, it was somewhat quieter about 8-bit computer and TCP/IP, the most known solutions originated predominantly in the time between 1998 and 2002 as the internet became a mass-medium. The connection was done by analog modems over the serial RS-232 interface.

Today, modems are obsolete at home. The ADSL internet is constantly available. A (hardware) router with DSL-modem or cable-modem is the link. Often the router is included for little money or for free as an addition to the provider contract. Such a router manages the internet access data of the provider and connection establishment alone. It contains some important services for easy building of home networks. The entire computer technology behind the router is linked, usually via Ethernet and cable or wlan.

That's why a serial modem connection is not very helpful. What I wanted, was a direct Ethernet access over TCP/IP : the communication standard! This will give me two things in one: access to the ressources of the home network, and universal communication possibilities over the internet. Today, TCP/IP is no more only the standard for the internet communication, but also for the operation of an usual home network with Ethernet.

Beside RS-232 and modem there are other ways and means to implement TCP/IP functionality in a 8-bit system. Below a comparison of other known projects is carried out with the stated aims of the project "KCNet". There are three things to note in particular, if an universal solution should be created for many Z80 systems:
  1. how the data of the application are handed over to the stack (network API)
  2. the connection point of the system and TCP/IP-stack layer (network hardware-connection)
  3. the need and usage of system ressources like memory and I/O space (network driver and/or software)


PPP / SLIP

This is the best known and most used method for Z80 systems. The picture shows the software TCP/IP-stack sitting on top of a serial interface. Because almost every system had this interface, it was also the most obvious way.

PPP/SLIP

Here are some links to such projects : all of them have been more or less dead for years.

1999 - 2001:   CPC/IP - A TCP/IP stack for Amstrad CPCs

1999 - 2002:   ZSock - The Z88 TCP/IP stack

2001 - 2002:   EZ80 - TCP/IP Stack für Z80

  • Jens Dietrich
  • http://www.icplan.de
    (Netzwerk-Technik: "Embedded Internet Z80 Board")
  • SIO
  • SLIP
  • Z80 Assembler

1999 - 2005:   UZIX - UNIX Implementation for MSX

2000:             ICE - Internet Connectivity for Eight-bit ataris

1993 - 2004:   LUnix / LNG - LUnix next generation C64


The results were rather mixed and ranged from "You can send and receive bytes." to full TCP/IP-stacks with network programs. What speaks for and against PPP or SLIP if one takes into account the defined goals:

freely programmable - very good
memory usage - extremely high
system load through the stack - very high
stability and reliability - depends on memory usage
other computer or server needed - yes
system load through network activity - not significant
transfer speed of network data - very bad
response time and usability - very bad
communication capabilities - very good
implementation of standard RFC-protocols - depends on memory usage
convenient API for network programming - depends on memory usage
compatibility with other Z80 systems - depends on RS-232 hardware
login / authentification / connection - needed for PPP

The critical points are marked in red and were the reason for me not to attempt to do it in this way. Other people have tried, here are two quotes from Mr. Phil Karn (KA9Q), found in the files "tcpguide" and "descript.doc" of his TCP/IP package:

"The implementation is highly modular. For example, if one wants to build dedicated packet switch without any local applications, the TCP and UDP modules may easily be omitted to save space."

"Speed improvements. I'm rather disappointed with the speed of this code on the 820, although a 2.5 MHz Z-80 isn't the fastest machine in the world. Channel speed is completely dominated by the interrupt routines in line.c, and while I've made them as tight as I can, some improvement might be had by coding sections of them in assembler. However, I'd MUCH rather have DMA hardware available, as this is the only way to get the really dramatic speedup we need to run speeds like 56 kB and up."

One example, the common baudrate of 19.200 Baud of a standard RS-232 interface gives a transmission speed of 1.920 Byte/s.

(19200 Baud * 8 Bit) / 10 (Start+8N1) = 15.360 Bit/s = 1.920 Byte/s

The layers of the software TCP/IP-stack, where all network data must be processed, leads to a further slowdown of data transmission. The entire construction ends below 1 kB/s effectively (estimated) : not acceptable for me as a user of the system.

The high memory requirement for a software stack with network application, the low speed of a standard RS-232 interface in a Z80 system, and the high burden of the entire system through the stack itself, are the main reasons that a usable TCP/IP implementation for my system, excluded on this basis. This applies to all other low-clocked standard cp/m 2.x systems equally.


Ethernet Controller

The second possible solution is, so far not seen with a Z80 system, to take a suitable Ethernet-Controller and connect it with the bus of your system. This works like a PC network-card and allows direct access to a Ethernet network. The following picture illustrates this.

The software TCP/IP-stack sits on top of the hardware interface, which must be programmed from a driver for memory-mapped I/O or direct I/O. This depends on the elected Ethernet-controller.

Ethernet Controller

The "RR-Net" for the C64 is one example from the year 2003.

2003:  RR-Net - 10 MBit Ethernet Network-Card for C64

So far, not many software exists for this card. I cannot judge exactly this solution, but the second link above shows the "real thing" : a "contiki" based web server on a C64. By substituting the slow RS-232 interface with a fast Ethernet controller, a disadvantage is removed, all other circumstances remain similar as with PPP / SLIP.

freely programmable - very good
memory usage - extremely high
system load through the stack - high
stability and reliability - depends on memory usage
other computer or server needed - no
system load through network activity - can become high
transfer speed of network data - bad
response time and usability - bad
communication capabilities - very good
implementation of standard RFC-protocols - depends on memory usage
convenient API for network programming - depends on memory usage
compatibility with other Z80 systems - depends on hardware interface
login / authentification / connection - no

One must build a hardware-interface for the system, that would not really be an obstacle. But the high memory requirement for a software stack with network application, and the burden of the entire system through the stack itself are reasons to drop this way. If new hardware is required, there are other solutions.

Further problems can occur with this solution as well. The software stack must process all Ethernet-packets of the network, in order to find out whether they are intended for it. With high broadcast's traffic, this leads to a heavy system load and response time, and usability can decrease drastically!

 


Serial to Ethernet Adapter

That is another possibility to connect a system with RS-232 interface with an Ethernet network. The hardware-connection is quickly made, but there are strong limitations on the software side. The following picture represents the structure.

SerialToEthernet Adapter

The crucial disadvantage is that there is no direct access to the TCP/IP-stack. It is hidden behind the non-standard device-specific protocol of the adapter (firmware). The Z80 software will work with adapters from the same manufacturer only. The functionality is directly influenced by the instruction set of the device protocol. The stack is not freely programmable.

There is an attempt in the "The N8VEM Home Brew Computer Project" with such adapters:

2008 ... :  MSS100 - Serial to Ethernet Gateway / Device Server

  • James Moxham and Richard Haseman
  • RetroBrew Computers N8VEM
  • UART
  • not standardized and limited Device-Protocol over RS-232
  • Z80 Assembler

This project is in the very beginning and not reusable until now. So far, it was possible to establish a Telnet session, but there exists no API, just some experimental code.

freely programmable - no
memory usage - low
system load through the stack - no
stability and reliability - yes
other computer or server needed - no
system load through network activity - no
transfer speed of network data - bad
response time and usability - depends on RS-232 hard- and software
communication capabilities - depends on adapter firmware
implementation of standard RFC-protocols - depends on adapter firmware
convenient API for network programming - no
compatibility with other Z80 systems - only with the same adapter
login / authentification / connection - no
The biggest advantage of such adapters is that the TCP/IP stack is outsourced from the system. The Z80 has to process the network program only. This reduces the system load greatly. But such Ethernet-adapters are available for the serial interface only. The problem remains with the low transfer-speed from the system to the adapter, see calculation example PPP/SLIP.

The restricted functionality of the device protocol decides against this solution. It sits over the application level of the TCP/IP stack. If there is a command or application not implemented in the adapter firmware, it is impossible to write an according network program.

Because the device protocol of such a serial to Ethernet adapters isn't portable, this cannot become a solution for a common Z80 TCP/IP-interface.

The same problem exists with other MCU's like PIC's, AVR's or ARM's, which can do the TCP/IP-stack for a Z80 system. Without an exactly defined hard- and software-interface for both sides on one layer of the TCP/IP-stack, an universal TCP/IP binding for a Z80 system will never exist. This development effort must be done twice : this requires a lot of time, experience and knowledge.

You need a generic protocol in order to program without restrictions, if you use external hardware!

 


Hardware TCP/IP-Stack + Ethernet Controller

In 2003, I discovered the first information about the chips of the company "WIZnet", which had managed a complete TCP/IP-stack in an integrated circuit. That went in the direction, favored by me : the lowest time-critical and complex layers of the TCP/IP-stack reside in external hardware, and the KC85 must send and receive network data with a corresponding protocol (RFC) "only".

Hardware TCP/IP Stack + Ethernet Controller

In October 2006, I bought an experimental board with a WIZnet chip and started the KCNet project later:

2007 - 2008:  KCNet - Native TCP/IP Stack for Z80 Systems

  • Ralf Kästner
  • Z80 PIO
  • BSD like Socket API
  • Z80 Assembler

This way of connecting a Z80 system over a fast parallel connection to a hardware TCP/IP-stack removes all disadvantages of the other solutions : no red markers, what a surprise :-) :

freely programmable - very good
memory usage - very low
system load through the stack - no
stability and reliability - yes
other computer or server needed - no
system load through network activity - no
transfer speed of network data - high
response time and usability - very good
communication capabilities - very good
implementation of standard RFC-protocols - yes
convenient API for network programming - yes
compatibility with other Z80 systems - very good
login / authentification / connection - no
The TCP/IP stack is offloaded from the system, and the Z80 processes the network program on top of the TCP- or UDP-layer normally. The  system load remains at the level of an application program, because the hardware does the difficult and time-consuming work of the TCP/UDP-, IP- and network protocol-layers.

The Z80-PIO hands over the network data to the stack, and ensures high bidirectional transfer-speed with a very simple hardware-handshake. Because the PIO is a standard peripheral circuit for Z80 systems, the hardware-interface is highly portable.

With the existing API, the TCP/IP-stack behaves like memory for the Z80 system, and can be used very easy. The high-level socket CALL's let application programming be a snap for network programmers.

The 4 channels of the WIZnet stack can be programmed on the TCP/UDP transport layer, but on the IP-layer or network-layer (MAC) too.

For academic reasons, it would even be possible to write the stack in software and use the MAC-layer of the stack as connection to the network (hybrid mode), where the hardware limitation to 4 sockets no longer exists.

The low-level commands of the hardware interface form a generic protocol, and do not restrict a programmer in doing anything with the stack.

The software, which is required in order to use the stack, may be included in each network program, due to the small size. There is, compared to the first two solutions, almost no memory consumption.