How Does a 1980s Z80 Retro Computer Get Real TCP/IP Networking?(NedoOS)

How Does a 1980s Z80 Retro Computer Get Real TCP/IP Networking?

A multitasking operating system for ZX Spectrum-compatible computers talks to a WIZnet W5300 hardware TCP/IP chip using nothing but the Z80's native IN/OUT instructions — turning a decades-old 8-bit architecture into a machine that can ping, telnet, browse the web, and play network games.

COMPONENTS Hardware components

📌PROJECT DESCRIPTION

 A Real Multitasking OS for a Computer From 1982

NedoOS is a multitasking operating system for ZX Spectrum-compatible computers — Z80-based machines descended from Sinclair's 1982 original, still built and sold today as FPGA recreations like ZX Evolution, Pentagon 2.666, and ATM Turbo 2+. First released in 2018 and still actively maintained (this mirror syncs nightly from the project's SVN repository), NedoOS runs up to 16 simultaneous tasks, includes programming environments for assembler, BASIC, Pascal, C, and its own NedoLang, and provides filesystem support for TR-DOS floppies, SD cards, USB flash drives, and FAT12/16/32 IDE hard drives.

What makes it relevant here is that this multitasking OS also does real networking — not a toy demo, but a documented, general-purpose kernel network API (OS_NETSOCKET, OS_NETCONNECT, OS_WIZNETREAD, OS_WIZNETWRITE, OS_NETSHUTDOWN, OS_GETDNS/OS_SETDNS) that user-space programs call the same way they'd call any other syscall. A ping utility, a telnet client, a DNS resolver, an HTTP browser, and even network-enabled games are all built directly on top of it.

🔍 Talking to the W5300 With Nothing but IN and OUT

The chip behind the hardware path is the WIZnet W5300 — unlike the SPI-based W5100/W5500 family more commonly seen in maker projects, the W5300 exposes its registers over a parallel 8/16-bit bus, which happens to map naturally onto a retro computer's memory-mapped I/O world. NedoOS's kernel/w5300.asm and kernel/w5300ini.asm drive it with exactly that: the Z80's IN/OUT instructions against a handful of I/O ports (a register-address-select port and a socket-config port, both offset from a configurable base address), with no SPI, no bit-banging, and no external glue logic beyond what's already on the expansion card.

The driver reconstructs a complete WIZnet socket state machine in Z80 assembly: Sn_MR/Sn_CR/Sn_SSR for mode, command and status, Sn_PORTR/Sn_DPORTR/Sn_DIPR for local and destination addressing, and Sn_TX_*/Sn_RX_* for the TX/RX ring buffers — the same register set WIZnet documents for the chip, just accessed through IN A,(C) and OUT (C),A instead of SPI transactions. Because the Z80 is slow relative to 100 Mbps Ethernet, the bulk-transfer routines are hand-unrolled — the RX/TX loops execute eight INI/OUTI pairs per iteration specifically so the CPU can keep pace with the chip's buffers.

Generated diagram: the same register set WIZnet documents for the W5300, accessed as plain Z80 I/O ports.

🌐 One Syscall API, Two Completely Different Backends

NedoOS doesn't force every installation to have a W5300 card. The kernel also ships kernel/espnet.asm, a second networking backend built around an ESP8266/ESP32 module running espnet, the project's own binary socket protocol (currently v1.27, per protocol.h) carried over a plain UART link — not the text-based AT command set some Wi-Fi modules use, but a compact binary frame format purpose-built for this kernel. A companion firmware sketch, espnet.ino, describes itself in its own header comment as "binary socket firmware for ESP32, ESP32-C3, and ESP8266."

The interesting part is that both backends sit behind the exact same five-call kernel API. ping, telnet, the DNS resolver, and the HTTP browser call OS_NETSOCKET, OS_WIZNETREAD, and OS_WIZNETWRITE without knowing or caring whether the bytes are actually going out through W5300 hardware sockets or being framed and shuttled across a serial link to an ESP8266/ESP32 speaking espnet. Reading src/ping/ping.asm, the actual ICMP ping utility, shows exactly this: it opens a raw socket with OS_NETSOCKET, sends and receives ICMP echo packets with OS_WIZNETWRITE/OS_WIZNETREAD, and never references W5300 or espnet registers directly.

Generated diagram: the same five syscalls, two unrelated pieces of hardware underneath.

🧩 Why a Hardware TCP/IP Chip Matters Here

On a modern MCU, a hardware TCP/IP offload chip like the W5300 is mostly about saving flash, RAM, and CPU cycles that a software stack would otherwise consume. On a Z80 clocked at a few megahertz — designed in the 1970s, with no hardware multiplication and a handful of 8/16-bit registers — the case is considerably stronger: implementing TCP's retransmission timers, congestion handling, and checksum logic entirely in Z80 assembly, on top of everything else NedoOS's scheduler is already doing for up to 16 concurrent tasks, would be a substantially harder undertaking than what this driver actually does. Because the W5300 already contains a complete hardwired TCP/IP stack, the Z80 side only needs to move command bytes and buffer contents through a handful of I/O ports — the driver's real job is register bookkeeping and buffer copying, not protocol implementation.

The espnet path similarly offloads protocol handling to the companion module's own binary-socket firmware.

🧭 Where It Fits — Value and Limits

The value here is a genuinely unusual demonstration of a WIZnet chip's range: the W5300's parallel-bus interface, usually paired with FPGA boards or ARM/STM32 designs in WIZnet's own reference material, turns out to be just as much at home behind a 1980s-style Z80 I/O bus. For anyone curious about what a hardware TCP/IP socket engine looks like with literally no abstraction layer between it and the CPU's IN/OUT instructions, this driver is about as close to the metal as it gets — and the dual-backend design (hardware W5300 vs. UART-based espnet) is a clean, minimal pattern for any project that wants to support both "the fast card is installed" and "just use whatever Wi-Fi module is cheap" without duplicating application code.

The limits are the honest ones that come with a decades-old CPU and a small, community-maintained project: throughput is bounded by how fast a few-MHz Z80 can move bytes through INI/OUTI, not by the W5300's own 100 Mbps ceiling; the W5300 path requires the specific ZXNETUSB expansion card (or equivalent wiring) rather than being universally available on every ZX Spectrum-compatible board; and, as with most long-running hobbyist projects with a small maintainer base, the pace of updates depends on the ZX Spectrum-clone community around nedoos.ru and nedopc.org rather than a company roadmap.

📚 Project History and Credits

NedoOS's networking is a small piece of a much older and larger effort. The idea was drafted in 2007 with a first, never-tested kernel; serious development began in 2018, when the kernel, the cmd shell, the nv file manager, and part of a Scratch-like tool were written — the project's own changelog (nedoos.new, 147 dated entries) opens that same year and reads like a multitasking OS being hardened in real time: a standalone command-line build on November 7, 2018, multitasking three days later on November 10, a YIELD macro on November 12, and per-task current directories and drives by November 15 ("directory reads have no global state — directories can be read multitaskingly," per the log). Version numbers tied to SVN revisions appeared in 2019; the kapps (C application) ecosystem matured through 2021; and the network stack — including the ESP8266 backend discussed above — was hardened through 2022. The project remains active today: this GitHub mirror syncs nightly from the upstream Subversion repository at svn://nedoos.ru.

The manual's licensing terms allow free distribution of the program and source, while porting the code to another platform asks for the project lead's approval. Two design choices from the architecture are worth calling out alongside the networking story: there is no separate hardware timer for scheduling — the 50 Hz video interrupt is the scheduling tick — and every task carries its own small "user kernel" copy in its low 16 KB memory window, which is what makes the CP/M-style restart vectors (rst 0, rst 0x08, and so on) work consistently across up to sixteen concurrently running programs.

🔗 Related WIZnet Maker Projects

• ZXNETUSB is the expansion card this exact driver targets — a W5300-plus-USB-host/device ZXBUS card for ZX Evolution-family computers, designed by Vadim Akimov, Roman Chunin, and Dmitry Martyshkin. That post covers the hardware card itself; this piece is its natural software counterpart, going through how NedoOS's kernel actually drives the chip that card carries.
• RC2014 Wiznet 5300 wires the same W5300 (via a WIZ830MJ module) onto a completely different retro platform — the RC2014, a modern Z80 backplane computer built from discrete logic rather than an FPGA. The shared thread is direct, low-level W5300 access on retro Z80 hardware; the difference is the bus and glue logic each platform needs (RC2014 handles timing via the W5300's configurable data-hold register and skips level-shifting since the chip's I/O is already 5V-tolerant).
• KallistiOS is the closest architectural comparison from a different retro platform: an open-source SDK/lightweight OS for the Sega Dreamcast that added official WIZnet W5500 support in a December 2025 pull request. The key difference is where the TCP/IP stack lives — KallistiOS uses the W5500 in MACRAW mode purely as a link-layer Ethernet adapter and runs its own IPv4/IPv6 stack in software, while NedoOS's W5300 driver leans on the chip's hardware TCP/IP sockets directly and keeps no software protocol stack of its own.

❓ FAQ

Q. Is this a toy demo, or does networking actually work end-to-end? It's functional and has shipped user-facing tools: a ping utility with packet-loss and RTT statistics, a telnet client, a DNS resolver, and an HTTP browser are all built on the same kernel network syscalls described here.

Q. Do I need the WIZnet chip, or can NedoOS network over Wi-Fi instead? Either works. The W5300 (via the ZXNETUSB card) is one backend; an ESP8266/ESP32 module running the project's own espnet binary socket protocol over UART is the other — not AT commands, but a compact custom frame format. Application code calls the same syscalls regardless of which is installed.

Q. Why W5300 instead of a more common chip like the W5500? The W5300 uses a parallel 8/16-bit bus rather than SPI, which maps directly onto the kind of memory-mapped I/O port space a Z80-based retro computer already uses for every other peripheral — no SPI controller or bit-banging driver is needed.

Q. Does the Z80 run its own TCP/IP stack? No. The W5300 path uses the chip's built-in hardwired TCP/IP stack; the Z80 side only issues commands and moves buffer data through I/O ports. The ESP8266 path similarly offloads protocol handling to the module's own AT-command firmware.

Q. What computers can actually run this? ZX Spectrum-compatible boards in the ATM Turbo 2-derived family: ZX Evolution (including its "baseconf" variant), Pentagon 2.666LE, and ATM3, among others, depending on which build script is used.

1980년대 Z80 레트로 컴퓨터는 어떻게 진짜 TCP/IP 네트워킹을 할까?

ZX Spectrum 호환 컴퓨터용 멀티태스킹 운영체제가 Z80의 순정 IN/OUT 명령만으로 WIZnet W5300 하드웨어 TCP/IP 칩과 통신합니다 — 수십 년 된 8비트 아키텍처를 ping, telnet, 웹 브라우징, 네트워크 게임까지 되는 기계로 바꿔놓은 사례입니다.

COMPONENTS 하드웨어 구성 요소

📌PROJECT DESCRIPTION

 1982년생 컴퓨터를 위한 진짜 멀티태스킹 OS

NedoOS는 ZX Spectrum 호환 컴퓨터 — Sinclair의 1982년 오리지널에서 이어져, 오늘날까지도 ZX Evolution, Pentagon 2.666, ATM Turbo 2+ 같은 FPGA 재현 보드로 만들어지고 판매되는 Z80 기반 기계 — 를 위한 멀티태스킹 운영체제입니다. 2018년 첫 출시되어 지금도 활발히 유지 관리되고 있으며(이 GitHub 미러는 프로젝트의 SVN 저장소에서 매일 밤 동기화됩니다), 최대 16개의 작업을 동시에 실행하고, 어셈블러·BASIC·Pascal·C, 그리고 자체 NedoLang까지 프로그래밍 환경을 제공하며, TR-DOS 플로피, SD카드, USB 플래시 드라이브, FAT12/16/32 IDE 하드디스크까지 파일시스템을 지원합니다.

여기서 중요한 부분은, 이 멀티태스킹 OS가 진짜 네트워킹까지 한다는 점입니다 — 장난감 데모가 아니라, 사용자 프로그램이 다른 syscall과 똑같은 방식으로 호출하는 문서화된 범용 커널 네트워크 API(OS_NETSOCKET, OS_NETCONNECT, OS_WIZNETREAD, OS_WIZNETWRITE, OS_NETSHUTDOWN, OS_GETDNS/OS_SETDNS)입니다. ping 유틸리티, telnet 클라이언트, DNS 리졸버, HTTP 브라우저, 심지어 네트워크 게임까지 전부 이 위에 직접 구축되어 있습니다.

🔍 IN과 OUT만으로 W5300과 대화하기

하드웨어 경로를 담당하는 칩은 WIZnet W5300입니다 — 메이커 프로젝트에서 더 흔히 보는 SPI 기반 W5100/W5500 계열과 달리, W5300은 병렬 8/16비트 버스로 레지스터를 노출하는데, 이게 마침 레트로 컴퓨터의 메모리 매핑 I/O 방식과 자연스럽게 맞아떨어집니다. NedoOS의 kernel/w5300.asm과 kernel/w5300ini.asm은 정확히 그 방식으로 칩을 구동합니다: Z80의 IN/OUT 명령을 몇 개의 I/O 포트(설정 가능한 베이스 주소에서 오프셋된 레지스터 주소 선택 포트, 소켓 설정 포트)에 대해 실행할 뿐, SPI도 비트뱅잉도 확장 카드에 이미 있는 것 이상의 외부 글루 로직도 필요 없습니다.

드라이버는 Z80 어셈블리로 완전한 WIZnet 소켓 상태 머신을 재구성합니다: 모드·명령·상태를 위한 Sn_MR/Sn_CR/Sn_SSR, 로컬·목적지 주소 지정을 위한 Sn_PORTR/Sn_DPORTR/Sn_DIPR, TX/RX 링 버퍼를 위한 Sn_TX_*/Sn_RX_* — WIZnet이 이 칩에 대해 문서화한 것과 동일한 레지스터 집합을, SPI 트랜잭션 대신 IN A,(C)와 OUT (C),A로 접근할 뿐입니다. Z80이 100Mbps 이더넷에 비해 느리기 때문에, 대량 전송 루틴은 손으로 직접 풀어놓았습니다 — RX/TX 루프는 CPU가 칩의 버퍼 속도를 따라잡을 수 있도록 반복마다 INI/OUTI 쌍을 여덟 번씩 실행합니다.

생성된 다이어그램: WIZnet이 W5300에 대해 문서화한 것과 동일한 레지스터 집합을, 평범한 Z80 I/O 포트로 접근합니다.

🌐 하나의 syscall API, 완전히 다른 두 백엔드

NedoOS는 모든 설치 환경에 W5300 카드가 있어야 한다고 강제하지 않습니다. 커널에는 kernel/espnet.asm이라는 두 번째 네트워킹 백엔드도 들어있는데, ESP8266/ESP32 모듈이 espnet이라는 이 프로젝트 자체의 바이너리 소켓 프로토콜(protocol.h 기준 현재 v1.27)을 평범한 UART 위에서 주고받는 방식입니다 — 일부 Wi-Fi 모듈이 쓰는 텍스트 기반 AT 커맨드 방식이 아니라, 이 커널 전용으로 설계된 컴팩트한 바이너리 프레임 포맷입니다. 동반 펌웨어 스케치인 espnet.ino도 자체 헤더 주석에 스스로를 "ESP32, ESP32-C3, ESP8266용 바이너리 소켓 펌웨어"라고 명시하고 있습니다.

흥미로운 점은 두 백엔드 모두 정확히 동일한 다섯 개짜리 커널 API 뒤에 있다는 겁니다. ping, telnet, DNS 리졸버, HTTP 브라우저는 OS_NETSOCKET, OS_WIZNETREAD, OS_WIZNETWRITE를 호출할 뿐, 실제 데이터가 W5300 하드웨어 소켓을 통해 나가는지 아니면 espnet 프로토콜로 프레이밍되어 시리얼 링크를 거쳐 ESP8266/ESP32로 가는지 전혀 신경 쓰지 않습니다. 실제 ICMP ping 유틸리티인 src/ping/ping.asm을 보면 정확히 이런 모습입니다: OS_NETSOCKET으로 raw 소켓을 열고, OS_WIZNETWRITE/OS_WIZNETREAD로 ICMP echo 패킷을 주고받을 뿐, W5300이나 espnet 레지스터를 직접 참조하는 일이 전혀 없습니다.

생성된 다이어그램: 같은 다섯 개의 syscall, 그 아래에는 서로 전혀 다른 두 하드웨어.

🧩 왜 여기서 하드웨어 TCP/IP 칩이 중요한가

현대 MCU에서 W5300 같은 하드웨어 TCP/IP 오프로드 칩은 주로 소프트웨어 스택이 잡아먹었을 플래시·RAM·CPU 사이클을 아껴주는 역할을 합니다. 그런데 1970년대에 설계되어 하드웨어 곱셈기도 없고 8/16비트 레지스터 몇 개가 전부인, 몇 MHz로 동작하는 Z80에서는 이 차이가 훨씬 더 결정적입니다: TCP의 재전송 타이머, 혼잡 제어, 체크섬 로직을 Z80 어셈블리로 전부 구현하는 일은, NedoOS의 스케줄러가 이미 최대 16개의 동시 작업을 위해 하고 있는 다른 모든 일 위에 얹기에는, 실제로 이 드라이버가 하는 일보다 훨씬 더 어려운 작업이 됐을 겁니다. W5300이 이미 완전한 하드와이어드 TCP/IP 스택을 담고 있기 때문에, Z80 쪽은 명령 바이트와 버퍼 내용을 몇 개의 I/O 포트로 옮기기만 하면 됩니다 — 이 드라이버가 실제로 하는 일은 프로토콜 구현이 아니라 레지스터 관리와 버퍼 복사입니다.

이런 역할 분담 덕분에, OS와 네트워킹 스택 전체가 최신 웹페이지 하나보다도 작은 메모리에 들어가는 기계 위에서, ping 유틸리티와 telnet 클라이언트, HTTP 브라우저가 각각 작고 독립적인 .com 프로그램으로 실제 존재할 수 있게 됩니다.

🧭 이 프로젝트가 자리하는 위치 — 가치와 한계

여기서의 가치는 WIZnet 칩의 활용 범위를 보여주는 꽤 특이한 사례라는 데 있습니다: WIZnet 자체 레퍼런스 자료에서는 보통 FPGA 보드나 ARM/STM32 설계와 짝을 이루는 W5300의 병렬 버스 인터페이스가, 1980년대 스타일의 Z80 I/O 버스 뒤에서도 똑같이 잘 어울린다는 걸 보여줍니다. 하드웨어 TCP/IP 소켓 엔진이 CPU의 IN/OUT 명령과 그 사이에 문자 그대로 아무 추상화 계층도 없이 어떤 모습인지 궁금한 사람에게, 이 드라이버는 거의 최대한 밑바닥에 가까운 사례입니다 — 그그리고 하드웨어 W5300과 UART 기반 espnet을 함께 지원하는 이중 백엔드 설계는, "빠른 카드가 꽂혀 있는 경우"와 "그냥 저렴한 Wi-Fi 모듈을 쓰는 경우"를 애플리케이션 코드 중복 없이 함께 지원하고 싶은 어떤 프로젝트에도 참고할 만한 깔끔하고 최소한의 패턴입니다.

한계는 수십 년 된 CPU와 소규모 커뮤니티 유지 프로젝트에 따라오는 정직한 것들입니다: 처리량은 W5300 자체의 100Mbps 한계가 아니라 몇 MHz짜리 Z80이 INI/OUTI로 바이트를 얼마나 빨리 옮길 수 있는가에 좌우되고, W5300 경로는 모든 ZX Spectrum 호환 보드에서 범용으로 되는 게 아니라 특정 ZXNETUSB 확장 카드(또는 그에 준하는 배선)가 필요하며, 유지보수 인원이 적은 대부분의 장기 취미 프로젝트가 그렇듯 업데이트 속도는 회사의 로드맵이 아니라 nedoos.ru와 nedopc.org를 중심으로 한 ZX Spectrum 클론 커뮤니티의 활동에 달려 있습니다.

📚 프로젝트 역사와 기여자

NedoOS의 네트워킹은 훨씬 더 오래되고 큰 작업의 작은 한 조각입니다. 아이디어는 2007년에 처음 구상되었고 한 번도 테스트되지 않은 첫 커널이 그때 나왔습니다. 본격적인 개발은 2018년에 시작되어 커널, cmd 셸, 파일 관리자 nv, Scratch 스타일 도구의 일부가 이때 작성되었습니다 — 프로젝트 자체 변경 로그(nedoos.new, 147개의 날짜별 항목)도 같은 해에 시작되는데, 마치 멀티태스킹 OS가 실시간으로 단단해지는 과정을 보는 듯합니다:

2018년 11월 7일 커맨드라인 단독 빌드 

→ 사흘 뒤인 11월 10일 멀티태스킹 추가 

→ 11월 12일 YIELD 매크로 

→ 11월 15일에는 작업별 현재 디렉터리·드라이브까지 구현됩니다(로그에는 "디렉터리 읽기는 전역 상태가 없다 — 디렉터리를 멀티태스킹하게 읽을 수 있다"라고 적혀 있습니다). 

SVN 리비전과 연동된 버전 번호는 2019년에 등장했고, kapps(C 애플리케이션) 생태계는 2021년에 걸쳐 성숙했으며, 위에서 다룬 ESP8266 백엔드를 포함한 네트워크 스택은 2022년에 걸쳐 강화되었습니다. 

프로젝트는 지금도 활발합니다 — 이 GitHub 미러는 업스트림 Subversion 저장소(svn://nedoos.ru)에서 매일 밤 동기화됩니다.

매뉴얼의 라이선스 조항에 따르면 프로그램과 소스코드의 자유 배포는 허용되지만, 다른 플랫폼으로의 포팅은 프로젝트 책임자의 승인을 받아야 합니다. 네트워킹 이야기와 함께 짚어볼 만한 아키텍처상의 설계 선택이 두 가지 있습니다: 스케줄링을 위한 별도의 하드웨어 타이머가 없고 50Hz 비디오 인터럽트 자체가 스케줄링 틱이라는 점, 그리고 모든 작업이 하위 16KB 메모리 윈도우에 자기만의 작은 "유저 커널" 사본을 가지고 있어서 CP/M 스타일 restart 벡터(rst 0, rst 0x08 등)가 최대 16개까지 동시에 실행되는 프로그램들 사이에서도 일관되게 동작한다는 점입니다.

🔗 관련 WIZnet Maker 프로젝트

• ZXNETUSB는 바로 이 드라이버가 대상으로 하는 확장 카드입니다 — Vadim Akimov, Roman Chunin, Dmitry Martyshkin이 설계한, ZX Evolution 계열 컴퓨터용 W5300 + USB 호스트/디바이스 ZXBUS 카드입니다. 그 글은 하드웨어 카드 자체를 다루고, 이 글은 그 카드가 탑재한 칩을 NedoOS 커널이 실제로 어떻게 구동하는지를 다루는 자연스러운 소프트웨어 짝입니다.
• RC2014 Wiznet 5300은 동일한 W5300(WIZ830MJ 모듈 경유)을 완전히 다른 레트로 플랫폼 — FPGA가 아니라 개별 로직으로 만들어진 현대적인 Z80 백플레인 컴퓨터인 RC2014 — 에 배선합니다. 공통점은 레트로 Z80 하드웨어에서의 직접적인 저수준 W5300 접근이고, 차이점은 각 플랫폼이 필요로 하는 버스와 글루 로직입니다(RC2014는 W5300의 설정 가능한 data-hold 레지스터로 타이밍을 맞추고, 칩의 I/O가 이미 5V 톨러런트라서 레벨 시프팅을 생략합니다).
• KallistiOS는 다른 레트로 플랫폼에서 가장 가까운 구조적 비교 대상입니다 — 세가 드림캐스트용 오픈소스 SDK/경량 OS로, 2025년 12월 풀 리퀘스트를 통해 WIZnet W5500 공식 지원을 추가했습니다. 핵심 차이는 TCP/IP 스택이 어디에 있는가입니다 — KallistiOS는 W5500을 MACRAW 모드로 순수 링크 계층 이더넷 어댑터로만 사용하고 IPv4/IPv6 스택을 자체 소프트웨어로 구현하는 반면, NedoOS의 W5300 드라이버는 칩의 하드웨어 TCP/IP 소켓을 직접 활용하고 자체 소프트웨어 프로토콜 스택은 전혀 두지 않습니다.

❓ FAQ

Q. 이거 장난감 데모인가요, 아니면 네트워킹이 실제로 끝까지 동작하나요? 실제로 동작하며, 사용자용 도구까지 나와 있습니다: 패킷 손실률과 RTT 통계를 보여주는 ping 유틸리티, telnet 클라이언트, DNS 리졸버, HTTP 브라우저가 모두 여기서 설명한 것과 동일한 커널 네트워크 syscall 위에 구축되어 있습니다.

Q. WIZnet 칩이 꼭 있어야 하나요, 아니면 Wi-Fi로도 네트워킹이 되나요? 둘 다 됩니다. W5300(ZXNETUSB 카드 경유)이 하나의 백엔드이고, UART 위에서 이 프로젝트 자체의 espnet 바이너리 소켓 프로토콜을 쓰는 ESP8266/ESP32 모듈이 다른 백엔드입니다 — AT 커맨드가 아니라 전용으로 설계된 컴팩트한 바이너리 프레임 방식입니다. 어느 쪽이 설치되어 있든 애플리케이션 코드는 동일한 syscall을 호출합니다.

Q. W5500 같은 더 흔한 칩 대신 왜 W5300인가요? W5300은 SPI가 아니라 병렬 8/16비트 버스를 사용하는데, 이게 Z80 기반 레트로 컴퓨터가 다른 모든 주변장치에 이미 쓰고 있는 메모리 매핑 I/O 포트 공간에 그대로 대응됩니다 — 별도의 SPI 컨트롤러나 비트뱅잉 드라이버가 필요 없습니다.

Q. Z80이 자체적으로 TCP/IP 스택을 돌리나요? 아니요. W5300 경로는 칩에 내장된 하드와이어드 TCP/IP 스택을 사용하고, Z80 쪽은 I/O 포트를 통해 명령을 내리고 버퍼 데이터를 옮기기만 합니다. ESP8266 경로도 마찬가지로 프로토콜 처리를 모듈 자체의 AT 명령 펌웨어에 맡깁니다.

Q. 실제로 어떤 컴퓨터에서 돌아가나요? ATM Turbo 2 계열에서 파생된 ZX Spectrum 호환 보드들입니다: 빌드 스크립트에 따라 ZX Evolution("baseconf" 변형 포함), Pentagon 2.666LE, ATM3 등에서 동작합니다.