NetISA

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

Trying to do modern TLS on an 8088 (or even a 386) is just not going to work well. You either get something painfully slow or something that barely holds together. So instead of forcing the host CPU to do that work, NetISA moves it somewhere else.

• A CPLD (ATF1508AS) handles ISA bus timing and exposes a register interface
• An ESP32-S3 handles WiFi, TCP/IP, and TLS using its built-in crypto hardware
• The DOS side talks to it through a small TSR like it’s just another device

No serial bottlenecks, no second machine acting as a proxy, and no software TLS on a 4.77 MHz CPU. That is the design. Whether real hardware behaves the same way is the open question, and that is the next phase.

Why a coprocessor

Every retro networking project I looked at before starting NetISA hits the same wall: TLS. The modern internet requires HTTPS, which means TLS 1.2 at minimum, and running TLS on a vintage CPU is slow at best.

The best data point for the software floor is WinGPT, which got TLS 1.3 working on Windows 3.1 by porting WolfSSL to Open Watcom Large model on a 486DX2-66. Crypto Ancienne brings TLS to classic Mac OS, AmigaOS, IRIX, and a dozen other platforms; on a 25 MHz 68030 a single handshake takes about 20 seconds. Both projects 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, but TLS still has to run on the host. Proxies like FrogFind and Browservice work universally but require a second modern machine.

NetISA takes a different approach: move TLS termination onto 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.

The full prior-art writeup with technical detail and a project index is in the architecture spec and the README.

What this should unlock

If everything works the way I think it should, a NetISA system would be able to:

• 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 Discord, 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. Whether that actually works in practice is still to be proven.

What actually works right now

Right now this is all running without real ISA hardware, using a stubbed backend:

• DOS TSR and API are working
• Applications (browser, Discord client, etc.) run against simulated responses
• ESP32 firmware (WiFi, HTTP, HTML parsing, config UI) is complete
• CPLD logic passes the testbench (160/160)

So the software side is in decent shape. None of that guarantees it works once real signals are involved.

What does not work yet

• No physical card assembled (parts are on the bench; soldering iron is next)
• No validation on real ISA machines
• No real bus timing verification
• No actual TLS session from DOS over the card

That’s the next phase, and also where things are most likely to break.

DOS software

The full DOS software stack targets 8088 real mode (OpenWatcom 2.0, small memory model) and runs on anything from a 4.77 MHz XT to a Pentium. At least in DOSBox-X it does.

• 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, and system info.
• Screen library: shared VGA text buffer rendering. Direct writes to 0xB800:0000 with CP437 box drawing.
• 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.

Cathode v0.2: text-mode web browser (sort of)

Cathode fetches real HTML pages over HTTPS via the NetISA card, parses them through a streaming HTML parser, and renders structured content in 80×25 text mode. No JavaScript, no CSS, no regrets. It’s good at articles, documentation, wikis, and directory pages. It’s bad at everything else. 40 KB EXE.

• Streaming HTML parser: headings, paragraphs, links, bold/italic/code, lists, blockquotes, preformatted text, horizontal rules, entities, image alt text
• HTTP/1.0 fetch with redirect following, UTF-8 to CP437 mapping, relative URL resolution
• Find on page (Ctrl+F) with match highlighting and N/Shift+N cycling
• Bookmarks with disk persistence (Ctrl+D to save, Ctrl+B to view)
• 200-row scrollback, scroll bar, Tab/Shift+Tab link navigation, back/forward history
• CP437 block-art CATHODE logo on start page

Discord v2: text-mode client

A ground-up rebuild of the Discord client. 128 messages per channel, multi-line compose, find in messages, PC speaker notifications, and CP437 emoji reactions. 37KB EXE. Runs with stub data in DOSBox-X.

• 8 channels with 128 messages each on far heap, unread counts, scroll bar
• Multi-line compose (Shift+Enter), word-wrapped messages, 8 hash-based author colors
• Ctrl+F find in messages with match highlighting and N/Shift+N cycling
• PC speaker notifications: blip for current channel, chirp for unread, F9 to toggle
• CP437 reactions (hearts, smileys, notes) and thread reply indicators
• Help overlay (F1), user list overlay (Alt+U), DISCORD.CFG settings persistence

Claude for DOS

A text-mode Claude AI chat client that talks to the Anthropic API over TLS 1.3. Includes a 3-mode agent system for running DOS commands from the conversation. This one was partly an excuse to see what happens when you put an LLM on an 8088.

• Chat, Ask, and Auto agent modes (F4 to cycle)
• Far-heap message pool for small memory model
• Word-wrapped chat rendering with newline support
• [EXEC] tag parsing for command execution with output capture
• Iterative agent loop with 5-deep safety cap

Firmware

The ESP32-S3 firmware handles the networking side. It preserves the PSTROBE ISR and register file architecture from the hardware spec; the ISA bus interface is unchanged.

• WiFi manager: APSTA mode with auto-connect, network scanning, and a 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
• Command dispatch: Maps all 8 INT 63h function groups via FreeRTOS queue between ISR and task cores
• Security: WPA2 AP, constant-time auth, OTA password protection, memory barriers on shared state

Specs

Design verification

The CPLD logic has been through a fairly thorough testbench. Whether that translates to working hardware is another question entirely.

• 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

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 that native drivers (Windows 95/98 NDIS, Linux net_device) could be added later without hardware changes. Whether I actually get that far depends on how the first prototype goes.

Links

• Source archive (source, schematics, build log)
• Architecture specification (the full design document)
• YouTube: @BarelyBooting (build videos)