NetISA

> An ISA coprocessor that tries to give old PCs a way to talk to the modern internet.

Open-source 8/16-bit ISA card. CPLD owns the bus, ESP32-S3 owns the crypto, the host gets a small TSR and an INT 63h API. Targets every x86 from a 4.77 MHz 8088 up. Software stack runs end-to-end in DOSBox-X; CPLD logic passes 160/160 testbench. Bench assembly is next, and I am fully expecting at least one thing to go wrong immediately.

Where things stand: Parts on the bench since 2026-04-23. CPLD logic passes its testbench. DOS stack and ESP32 firmware work against a stub backend. Real hardware bring-up is the next phase, where things are most likely to break.

Why a coprocessor

Trying to do modern TLS on an 8088 (or even a 386) does not work well. You get something painfully slow or something that barely holds together.

The reference points: WinGPT got TLS 1.3 working on Windows 3.1 by porting WolfSSL to a 486DX2-66. Crypto Ancienne brings TLS to classic Mac OS, AmigaOS, and IRIX; on a 25 MHz 68030 a single handshake takes about 20 seconds. Both disable certificate verification and use fake entropy to make it fit. Below a 486, the asymmetric key exchange math does not finish before the server times out.

Hardware WiFi cards like PicoMEM solve the radio problem but not the crypto problem. They emulate an NE2000 on the ISA bus and bridge to WiFi; TLS still runs on the host. Proxies like FrogFind and Browservice work universally but require a second modern machine.

NetISA puts TLS termination on the card. The ESP32-S3 has hardware-accelerated AES, SHA, RSA, and ECC, a real hardware RNG, and 8 MB of PSRAM for certificate chains. The host sends and receives plaintext. An 8088 at 4.77 MHz can talk to any HTTPS API because it never touches the cryptography.

Hailing frequencies

If everything works the way I think it should, a NetISA system can:

Fetch content from modern HTTPS sites in text-mode browsers
Talk to APIs that require TLS 1.2/1.3
Send and receive email over IMAPS/SMTPS
Interact with Mastodon, Matrix, or IRC-over-TLS
Download software from HTTPS-only sources
Sync files via WebDAV-over-HTTPS
Push data to MQTT-over-TLS brokers

The goal is not modern browsing on a 486. The goal is more like: a 486 can still exist on today’s internet without cheating.

DOS side

The DOS stack targets 8088 real mode (Open Watcom 2.0, small memory model) and runs on anything from a 4.77 MHz XT through a Pentium. At least in DOSBox-X.

NETISA.COM: 678-byte TSR that hooks INT 63h. Under 2 KB resident.
NETISA.EXE: launcher with WiFi scanning, signal-strength bars, password entry, card status, system info.
INT 63h API: C wrapper library covering system, WiFi, DNS, sessions, certificates, crypto, events, and diagnostics.
Stub layer: fake data layer for testing without hardware. Simulates WiFi networks, connection states, and delays.

Suite apps

The DOS apps that exercise the NetISA API live on their own pages. Each is open source, each runs against the stub backend in DOSBox-X today.

Animated: Cathode v0.5 text-mode browser cycling through five pages: start page, about:portal curated text web, NPR news, OpenBSD man server, barelybooting.com — CATHODE. Real HTML over HTTPS, rendered in 80×25 text mode.

Animated: NetISA control panel main menu showing WiFi Setup, Card Status, and About options with keyboard navigation — NETISA.EXE control panel. WiFi setup, card status, system info.

Other suite apps: HEARO (music player). Planned: COURIER (email), CRATE (cloud filesystem), KIOSK (package manager), RADIO (XT-class streaming).

Firmware

The ESP32-S3 firmware handles the network side. PSTROBE ISR and register file architecture are unchanged from the hardware spec.

WiFi manager. APSTA mode with auto-connect, network scanning, setup AP (“NetISA-Setup”).
HTTP client. Up to 4 concurrent TLS sessions using the ESP-IDF certificate bundle.
HTML parser. State machine that converts HTML to CP437 cell streams for Cathode.
Web config. Embedded HTTP server at 192.168.4.1 with WiFi setup, OTA updates, and status.
Security. WPA2 AP, constant-time auth, OTA password protection, memory barriers on shared state.

Specs

Bus interface	8/16-bit ISA (XT through 486)
Bus logic	Microchip ATF1508AS CPLD, TQFP-100, 128 macrocells, native 5 V, 10 ns pin-to-pin
Processor	ESP32-S3-WROOM-1U-N8R8 (dual-core Xtensa LX7, 8 MB flash, 8 MB PSRAM)
WiFi	802.11 b/g/n, external bracket-mount antenna (metal cases are not RF-friendly)
TLS	1.3 with hardware AES-128/256, SHA-256/384/512, RSA-4096, ECC, hardware RNG
Ethernet	Wiznet W5500, 8 hardware TCP sockets, 10/100 Mbps (v1.5, pads on v1 board)
Host CPU	Any x86: 8088 4.77 MHz through Pentium+
DOS driver	678-byte TSR, < 2 KB resident, INT 63h API
I/O decode	Full 16-bit, no aliasing on AT+ systems
Configuration	Physical jumpers for base address, IRQ, safe mode. No Plug-and-Play.
License	MIT (software) / CERN-OHL-P (hardware)

Verification

160/160 Verilog testbench tests passing (iverilog): address decode, IOCHRDY wait states, watchdog timeout, IRQ retrigger, back-to-back cycles, mid-cycle reset, alias rejection.
95 of 128 macrocells used, 61 of 84 pins.
Timing slack: +39.5 ns setup, +5.0 ns hold at 16 MHz. Zero total negative slack.
Zero bus contention events across the simulation suite.

Whether that translates to working hardware is another question.

What comes next

The current plan ships as a DOS peripheral using Session Mode: the card owns TCP/IP and TLS, the host talks at the session level. The firmware and CPLD are designed so native drivers (Windows 95/98 NDIS, Linux net_device) can be added later without hardware changes. Whether I actually get there depends on how the first prototype goes.