Wiznet makers

How to Add TCP/IP Networking with WIZnet W5500 to UniFLEX on a 6809/6309 Eurocard System?

Summary

The UniFLEX project adds modern TCP/IP networking to a Motorola 6809/HD6309 Eurocard computer by combining Berkeley-style socket calls in the operating system with a CPU09GPP I/O processor and a 09NET daughterboard built around the WIZnet W5500. 

The W5500 provides the Ethernet MAC/PHY, hardwired TCP/IP processing, eight independent hardware sockets, and packet buffering, while the GPP processor translates UniFLEX socket operations into W5500 SPI transactions. This architecture keeps networking practical on a system whose main CPU operates at only a few megahertz and whose kernel memory is tightly constrained.

What the Project Does

UniFLEX is a reconstruction and extension of the Technical Systems Consultants UniFLEX operating environment for Motorola 6809 and Hitachi HD6309 processors. The modern hardware is implemented as Eurocards and includes CPU and memory-management boards, monitor and system RAM, IDE storage, floppy interfaces, serial I/O, RAM disks, and dedicated I/O processors. With an HD63C09, the CPU design runs at a 4 MHz E-clock.

The operating system includes multitasking, multiple processes, virtual memory in 4 KB pages, swapping, DMA, interrupt-driven I/O, pipes, signals, process protection, and a large set of SWI3 system calls. The project is deliberately open at both hardware and software levels, making it particularly useful for studying operating-system architecture and low-level computer engineering.

Networking was added during 2023–2024. UniFLEX gained socket-level operations corresponding to Unix interfaces including socket(), connect(), bind(), listen(), accept(), read(), write(), close(), recvfrom(), and sendto(). The calls can be used from assembly and through a socket library for the McCosh C compiler.

The hardware path is built around the CPU09GPP generic I/O processor. CPU09GPP communicates with the main UniFLEX CPU through 1K × 8 dual-port RAM and supports communication in both directions. Its local expansion connector is used for daughterboards such as 09NET. The repository describes the CPU09GPP + 09NET combination as providing up to eight simultaneous TCP/IP or UDP sockets.

The resulting architecture is:

UniFLEX application → Berkeley-style socket call → UniFLEX kernel → dual-port RAM mailbox → CPU09GPP → SPI → W5500 → Ethernet

Networking is used for more than simple TCP client programs. Utilities include ifconfig, netstat, nettime, w2sock, and sock2r. A netblock driver can expose up to two remote block devices over TCP/IP, with Linux, macOS, Windows, or another UniFLEX machine acting as the storage server. The project reports that UniFLEX can boot, run, and even swap using these network-backed block devices.

Where WIZnet Fits

The Ethernet controller used by 09NET is the WIZnet W5500.

The project log explicitly states that the CPU09GPP networking expansion was designed with fast SPI hardware and a W5500 network module. The W5500 is therefore not an architectural suggestion or replacement option; it is part of the implemented UniFLEX networking system.

W5500 integrates a hardwired IPv4 TCP/IP engine, 10/100 Ethernet MAC and PHY, eight independent hardware sockets, and 32 KB of internal TX/RX memory. The host accesses it through SPI, with the W5500 supporting SPI clock rates up to 80 MHz. TCP, UDP, IPv4, ICMP, ARP, IGMP, and PPPoE are handled by the controller rather than by a conventional software TCP/IP stack running on the host processor.

That distinction matters in UniFLEX. The HD6309 main system can run at a 4 MHz bus clock, while the repository also notes that kernel memory is limited enough that not every optional kernel feature can be included at the same time. Moving TCP/IP state handling and packet buffers into the W5500 avoids requiring the main UniFLEX kernel to contain a complete software networking stack.

The W5500 does not replace all network software. UniFLEX still has to implement Unix-style file descriptors and socket semantics, while CPU09GPP has to interpret requests, maintain communication state, access W5500 registers through SPI, and return results to the main processor.

This creates three distinct layers:

UniFLEX CPU: Unix socket semantics

CPU09GPP: network I/O processor and W5500 control

W5500: TCP/IP engine, hardware sockets, buffers, MAC/PHY

The eight W5500 sockets map particularly well to the operating-system design. The project allocates eight per-socket parameter areas in dual-port RAM, while W5500 itself provides eight independently usable hardware sockets.

Implementation Notes

The W5500 connection is documented directly in the repository's Progress file:

“The pop-up has fast SPI hardware and a W5500 network module.”

Path: Progress
Related hardware: Hardware/CPU09GPP/09NET/

This is important because CPU09GPP is not simply forwarding raw Ethernet frames to UniFLEX. The GPP processor directly operates the W5500 over SPI and handles much of the device-side socket state.

The first implementation considered using W5500 interrupts extensively. During development, that design was simplified:

“I dropped the interrupts from the W5500 module in favor for fast polling.”

Path: Progress

Fast polling was practical because W5500 access is handled by the dedicated GPP processor rather than by the main UniFLEX CPU. The change reduced the complexity of the GPP networking firmware while keeping network processing outside the main operating-system execution path.

Communication between the main CPU and CPU09GPP uses mailbox messages stored in dual-port RAM. The same shared RAM includes a 512-byte FIFO for transferring payload data between the processors. When UniFLEX executes socket(), the request is transferred to the GPP processor, which reads W5500 registers through SPI, validates the state, and opens the corresponding hardware socket. UniFLEX then creates the associated file entry so normal OS file operations can be used on that network endpoint.

The implementation also reserves eight 32-byte socket parameter areas in dual-port RAM. Each area contains cached W5500 socket information such as socket status, command state, IP information, and port configuration. Keeping this information visible in shared RAM also makes debugging the interaction between the two processors easier.

Once a TCP connection is established, normal UniFLEX read(), write(), and close() operations can operate on it. UDP support was subsequently added through recvfrom() and sendto(). This preserves the Unix programming model even though TCP/IP itself is being executed by the W5500 hardware.

The project reports an early TCP file-transfer test of almost 4 MB in roughly 30 seconds, corresponding to more than 100 KB/s. That number reflects the complete UniFLEX/GPP/W5500 path rather than the maximum Ethernet or W5500 throughput, but it demonstrates that the architecture provides useful network performance on the 6809/6309 platform.

Practical Tips / Pitfalls

Keep the SPI path electrically clean. The project encountered data corruption caused by crosstalk on an early 09NET board revision. Components were moved and high-frequency traces were shortened in the revised layout.

Respect the W5500 power requirements. The project powers the W5500 networking module from 3.3 V and notes the usefulness of its 5 V-tolerant I/O when integrating it with the older logic environment. WIZnet also specifies 3.3 V operation with 5 V I/O tolerance for the W5500 chip.

Treat all eight sockets as finite OS resources. UniFLEX file entries, GPP socket parameter areas, and W5500 hardware socket numbers must remain synchronized when sockets are opened, closed, or aborted.

Polling is an intentional architectural choice here. W5500 interrupt handling was tested during development, but fast polling on the dedicated GPP processor produced a simpler implementation without adding polling load to the main UniFLEX CPU.

Size data exchange around the shared-memory boundary. The GPP link includes a 512-byte FIFO, so large transfers have to be segmented between the UniFLEX process, shared RAM, and W5500 socket buffers.

Network storage needs stronger failure handling than ordinary sockets. netblock can participate in filesystem access and even swapping, so link loss, server failure, TCP timeout, and socket recovery can affect the operating system more severely than a failed user-level TCP connection.

FAQ

Q: Why does UniFLEX use the WIZnet W5500?

The W5500 provides TCP/UDP processing, eight hardware sockets, 32 KB of internal network memory, and an integrated Ethernet MAC/PHY without requiring a full software TCP/IP stack on the UniFLEX CPU. That is particularly useful for a 6809/6309 computer running at only a few megahertz with limited kernel memory. The eight W5500 sockets also correspond directly to the eight-socket model implemented by the UniFLEX networking subsystem.

Q: How is the W5500 connected to the UniFLEX hardware?

The W5500 resides on the 09NET expansion used with CPU09GPP and is accessed through fast SPI hardware. The W5500 SPI side requires clock, MOSI, MISO, and chip-select signalling, while the module also needs its power and Ethernet connection. CPU09GPP then communicates with the main UniFLEX CPU separately through 1K × 8 dual-port RAM, so the main processor does not access the W5500 SPI interface directly.

Q: What exactly does the W5500 do in this project?

The W5500 maintains the actual TCP and UDP hardware sockets, performs IPv4/TCP/UDP protocol processing, buffers transmitted and received Ethernet data, and provides the Ethernet MAC/PHY interface. CPU09GPP controls those sockets through SPI, while the UniFLEX kernel translates them into Unix-style descriptors and calls such as socket(), connect(), bind(), listen(), accept(), read(), write(), recvfrom(), and sendto().

Q: Can beginners follow the W5500 networking implementation?

It is best approached after learning basic 6809/6309 assembly, SPI, shared-memory communication, TCP/UDP concepts, and Unix file-descriptor semantics. The design is nevertheless useful for computer-science education because each layer is visible: an application makes a socket system call, the kernel converts it into a request, CPU09GPP exchanges that request through dual-port RAM, and W5500 executes the network operation. The original project explicitly positions the open hardware and software system as a learning platform.

Q: How does the W5500 approach compare with a software TCP/IP stack such as LwIP?

With LwIP, the processor would normally run IP, ARP, TCP/UDP state machines and packet-buffer management in software on top of an Ethernet MAC driver. W5500 implements these protocols in hardware and provides its own socket buffers and eight hardware connection contexts. A software stack offers greater protocol flexibility, but on a low-megahertz 6809/6309 system it would consume CPU time and RAM that UniFLEX already uses for processes and kernel functions. W5500 trades that flexibility for a compact socket-oriented hardware interface that fits this architecture well.

Source

Original Project: Kees Schoenmakers — UniFLEX, a 6809/6309-compatible UniFLEX hardware and software project on Eurocards. UniFLEX GitHub Repository

Networking Development Record: The repository Progress file documents the CPU09GPP networking design, W5500 module, SPI implementation, polling architecture, shared-memory communication, socket mapping, and early performance tests.

System Architecture: README2 documents CPU09GPP, the CPU09GPP + 09NET configuration, networking utilities, and the netblock driver.

W5500 Reference: WIZnet documents the W5500 as a hardwired TCP/IP Ethernet controller with eight simultaneous hardware sockets, 32 KB TX/RX memory, integrated 10/100 Ethernet MAC/PHY, and SPI operation up to 80 MHz. WIZnet W5500 Documentation

License: GPL-3.0.

Tags

#W5500 #WIZnet #UniFLEX #6809 #HD6309 #CPU09GPP #09NET #Ethernet #TCPIP #Retrocomputing #ComputerScience