Writing a Human68k driver for a Wi-Fi module via the serial port

Adding Wi-Fi to a Sharp X68000 is an appealing way to connect a period computer to modern services without changing its character. The practical route is to attach an ESP8266, ESP32, or similar module to the machine’s RS-232C serial port, then write a Human68k driver that presents a predictable interface to software. The difficult part is rarely the radio link itself. It is the boundary between old serial hardware, Human68k’s device model, and contemporary TCP/IP behaviour.

A useful design should survive dropped characters, module resets, slow boot times, and applications that assume a fixed-speed modem. It should also leave enough CPU time for games, file transfer, terminal programs, and disk operations. For Australian collectors working with scarce hardware in Sydney, Melbourne, Brisbane, or smaller regional towns, a serial Wi-Fi bridge can be easier to source than an original network board, while preserving the machine’s original expansion slots.

Decide what the driver should provide

The first design decision is whether the driver will offer a raw serial stream, a modem-like command interface, or networking services. A raw stream is the simplest option: Human68k programs read and write bytes, while the Wi-Fi module handles TCP connections through AT commands. This is useful for terminal access, remote shells, and custom utilities, but every application must understand the module’s command syntax.

A modem emulation layer is more compatible with existing software. The driver can accept commands such as AT, AT+CWMODE, and a vendor-specific connect command, then switch into transparent data mode after a socket is established. From the X68000’s perspective, the remote service behaves like a serial modem. This approach suits terminal programs and small communications tools, although escaping from transparent mode requires careful handling of guard times or an out-of-band reset method.

A full TCP/IP driver is a larger project. It needs packet buffers, socket state, retransmission logic, addressing, and an API that Human68k software can call. An alternative is to pair a simple serial transport with an existing X68000 TCP/IP stack, using SLIP or PPP. In that arrangement, the Wi-Fi module acts as a wireless modem and the driver handles framing, checksums, and serial interrupts rather than implementing Ethernet and IP itself.

For an enthusiast project, SLIP is often the most manageable target. It uses a straightforward byte stream, supports IP packets, and avoids the complexity of pretending that the serial port is an Ethernet controller. PPP offers negotiation and authentication but demands more code. Start with a reliable character device and a test utility, then add packet framing after the physical link is stable.

Understand the X68000 serial environment

Human68k software normally reaches hardware through IOCS calls, BIOS services, device drivers, or direct register access. A resident program that polls the serial port can be useful during experimentation, but it is not the same as a proper driver. Polling wastes CPU time and can lose incoming bytes while the system is busy drawing, reading a floppy, or servicing another interrupt.

An interrupt-driven implementation should maintain separate transmit and receive ring buffers. The receive interrupt reads the UART status and data registers as quickly as possible, stores each byte, and records overrun or framing errors. The foreground side removes bytes from the ring, interprets command responses, and reports them to Human68k callers. The transmit path can similarly queue output and enable the transmitter-empty interrupt only while data remains.

Do not assume that a modern module’s default serial settings match the X68000. Begin at a conservative rate such as 9,600 or 19,200 baud, 8 data bits, no parity, and one stop bit. After testing the interrupt code, increase the rate if the UART and wiring remain reliable. A short cable, common ground, and proper level compatibility matter more than a headline baud rate.

Many Wi-Fi boards use 3.3-volt logic, while an X68000 serial interface may use RS-232 voltage levels. Connecting the module directly can damage it or produce unreliable data. Use a genuine level converter designed for RS-232, not merely a 3.3-volt UART adapter. Check the module’s power requirements as well: an ESP-class board can draw brief current peaks that exceed the output of a small regulator. A powered converter from Jaycar or an Australian electronics supplier is often safer than a bare module connected to an improvised supply.

Build a dependable command and data state machine

A driver should treat the Wi-Fi board as an asynchronous device. The module may take several seconds to boot, print unsolicited status messages, or reset after joining an access point. A simple sequence of “send command, wait for text” calls will eventually become confused. Define explicit states such as OFFLINE, RESETTING, READY, JOINING, CONNECTED, DATA, and ERROR.

Each command needs a timeout, an expected response, and a recovery action. For example, after reset the driver can discard boot text until it sees a known ready marker. It can then disable echo, configure station mode, join the saved wireless network, and open a TCP connection. If the response is incomplete, the timeout should return an error to the caller rather than leaving the driver blocked forever.

The command parser should accept both OK and documented error responses, but it should not rely on one exact line ending. Modules differ in whether they use carriage return, line feed, or both. Keep response parsing separate from application data parsing. In transparent mode, a string resembling ERROR may be legitimate remote data and must not be mistaken for a module response.

A framing layer is valuable even when the module already offers transparent transmission. One practical format is an escape byte followed by a type, length, payload, and checksum. Escape reserved bytes in the payload, reject impossible lengths, and resynchronise after a damaged frame. A checksum will not repair a bad connection, but it lets the driver discard corrupted data instead of passing it to a file transfer or TCP stack.

Power loss and access-point changes need predictable behaviour. The driver should expose a reset operation, clear buffers after a reset, and return a distinct “link unavailable” status. Automatic reconnect is useful, but it should use a delay rather than hammering the module with commands. Australian home networks frequently combine an ISP router with mesh access points, so testing with both a simple WPA2 network and a more complex household setup can reveal timing problems early.

Map the driver to Human68k software

Human68k device-driver conventions should shape the public interface from the beginning. A driver loaded through CONFIG.SYS needs an installation path, a strategy for initialisation, and clearly defined read, write, status, and control operations. Exact entry conventions depend on the driver type and development environment, so inspect existing X68000 .SYS drivers and assembler examples rather than copying assumptions from ordinary MS-DOS.

A sensible control interface can expose operations for setting the baud rate, resetting the module, joining a network, opening a socket, closing a socket, and reading link status. Keep these controls separate from ordinary byte reads and writes. That allows a terminal program to use the character stream while a networking utility can request a connection without embedding module-specific AT commands.

Layer	Responsibility	Useful test
UART interrupt code	Move bytes between registers and ring buffers	Sustained receive at the selected baud rate
Serial device layer	Provide read, write, status, and control calls	A Human68k diagnostic utility
Wi-Fi state machine	Boot, configure, connect, recover, and report errors	Repeated module resets and reconnects
Framing or modem layer	Separate commands from payload data	Binary data containing escape characters
SLIP or PPP layer	Carry IP packets over the serial stream	Ping and a small TCP transfer
Application interface	Give programs stable networking operations	Terminal, file transfer, and time service

Keep buffer sizes modest and static. A few kilobytes allocated at installation time are easier to reason about than dynamic memory on a machine with limited RAM and many resident utilities. Define what happens when a buffer fills: pause transmission, drop the oldest data, or return an overflow error. Silent loss is the worst choice for file transfer.

A companion diagnostic program is worth writing alongside the driver. It should display UART errors, ring-buffer occupancy, module responses, signal information where available, and the last state transition. A command-line tool that performs reset, join, connect, send, receive, and disconnect tests will save considerable time compared with debugging through a graphical application.

Test compatibility, safety, and real hardware

Start testing with a loopback plug or a second serial device before introducing Wi-Fi. Verify transmit and receive interrupts, buffer wraparound, timeout handling, and recovery from deliberately removed cables. Then connect the level converter and module with the Wi-Fi radio disabled. This separates electrical and UART problems from authentication or network problems.

Binary transfers are a particularly valuable test. Text terminals can conceal dropped bytes because a missing character may be obvious but harmless. Send a known file containing every byte value, calculate a checksum on both systems, and repeat the test at different speeds. Include long pauses, bursts of data, and a module reset during transfer. The driver should fail cleanly and report the reason.

For Australian installations, mains safety deserves attention. The X68000’s supply is designed for local Japanese conditions, and replacement or repaired power units must be treated carefully around Australia’s 230–240-volt, 50 Hz mains. A Wi-Fi board should run from an isolated, regulated low-voltage supply; never derive power from an uncertain point inside the computer without checking the service documentation. A fused external adapter is easier to replace and reduces the risk of damaging a rare machine.

Wireless security also affects compatibility. Some older modules support WPA2 reliably but struggle with WPA3-only networks or unusual channel configurations. Use a separate 2.4 GHz SSID during development, with a clear password and stable DHCP reservation. A module that works beside the router may fail in a room across a Sydney terrace house or a brick Melbourne apartment, so test the intended physical placement rather than relying on bench results.

Hardware sourcing can be surprisingly regional. Australian buyers may find level shifters, USB-to-serial tools, and ESP development boards through Jaycar, RS Components Australia, eBay Australia, or Gumtree, although stock and delivery times vary. Keep the design tolerant of substitute modules, and document pinouts so a future maintainer can replace a discontinued board without reverse-engineering the wiring.

Extend the project without losing its period character

Once the serial path is stable, SLIP provides a practical route to networking. The driver wraps each IP datagram with SLIP framing, escapes special bytes, and passes the result to the Wi-Fi module’s connected socket. A small TCP/IP stack can then provide ping, FTP, Telnet, HTTP, or NTP utilities. PPP is worth considering later if authentication, dynamic configuration, or broader compatibility is required.

The module’s firmware should be treated as part of the project. Record its version, AT command set, default baud rate, and configuration procedure. Store settings in a way that can be restored after a factory reset. If the board supports custom firmware, a deliberately small serial-to-TCP firmware can remove unpredictable command parsing and make the Human68k side cleaner.

Documentation is part of preservation. Include schematics, connector pinouts, timing diagrams, source code, assembler build instructions, and a known-good module configuration. A short note about Australian power adapters, local wireless settings, and replacement parts can help another owner reproduce the setup years later. Related preservation work, including Coolscan archives, shows why practical hardware notes matter: obscure equipment remains usable when its operating details are recorded rather than left in memory.

The project can also coexist with purpose-built X68000 networking hardware. The Nereid-X expansion offers a different path for users who need Ethernet-oriented software or higher throughput. A serial Wi-Fi driver remains valuable because it is accessible, electrically isolated from internal expansion work, and suitable for machines whose original network options are unavailable or too expensive.

A working Human68k Wi-Fi driver should feel uneventful in daily use. It boots, reports clear errors, reconnects when appropriate, and moves data without corrupting it. Build the UART layer first, make the module state machine observable, test every failure path, and only then add SLIP, PPP, or application-level networking. Publish the source, wiring notes, and test results on X68K.NET so another Australian hobbyist can connect a surviving X68000 to a modern network without sacrificing the machine’s original identity.