Writing a Human68k driver for a SNES controller via serial port

An SNES controller can be more than a museum piece. On an X68000 it can provide a familiar feel for new games, a compact source of test input, or a satisfying bridge between two generations of Japanese hardware. The challenge is that the X68000’s RS-232C serial ports and the SNES pad speak very different electrical and timing languages.

A workable design places a small controller adapter between them. Human68k talks to the adapter with ordinary serial bytes, while the adapter performs the SNES controller’s synchronous transfer. This adds a board, but it gives the driver stable packets and avoids asking a general-purpose UART to imitate a protocol it was never designed to carry. The original console can remain untouched if the adapter accepts a standard controller lead or a short passive breakout, and the finished driver can expose the pad to any Human68k program that knows how to query it.

Approach	Host-side work	Electrical arrangement	Likely result
Direct UART connection	Exchange ordinary bytes	Level conversion still required, but timing remains wrong	Unsuitable for the native controller protocol
Bit-banged MFP lines	Generate clock, data and turnaround timing	TTL buffers and a suitable data-line interface	Possible, but sensitive to timing and interrupt jitter
Microcontroller adapter	Exchange framed request and response packets	MAX3232 plus a protected 5 V controller interface	Most repeatable and portable option

Understanding the protocol mismatch

A standard SNES controller is a synchronous 5 V peripheral. The host supplies a clock, writes a command on a bidirectional data line, then clocks the controller’s reply back. A normal button query is one command byte, commonly 0x00, followed by a two-byte response. The familiar clock rate is about 250 kbit/s, and the sequence includes enough edge timing that idle time between characters cannot replace a clock. A reset is commonly initiated with a command such as 0xff before normal polling.

The X68000’s external serial ports use RS-232C electrical levels and normally expose asynchronous byte streams through Human68k’s I/O layer. RS-232 defines voltage swings and signalling rates; it does not supply the SNES clock-and-data transaction. Connecting the sockets or placing a resistor between them would not create a working controller, and a 5 V SNES data line must never be applied directly to an RS-232 driver.

There are several realistic choices. Bit-banging the SNES lines from an HD63450 MFP timer or general-purpose output is possible, but interrupt jitter can corrupt a bit. Some USARTs provide synchronous modes, although software must still manage the single data line’s turnaround. A microcontroller adapter is the easiest route to repeatability, and it lets the Human68k side remain an ordinary device driver.

Designing a protected serial interface

Use the X68000 port only through its RS-232C transceiver. A MAX3232-family transceiver is convenient because it converts the adapter’s TTL UART signals to and from the bipolar RS-232 levels expected at the socket. Cross the transmit and receive lines according to the data sheets for both devices, and use DTR or RTS only if the adapter defines a meaningful handshake. The SNES side remains at 5 V and should connect to the adapter, never directly to an HD68k GPIO pin or an RS-232 driver output.

Give the SNES data line a proper bidirectional arrangement, normally with a suitable 74xx transceiver, direction control and pull resistors that match the controller’s open-collector behaviour. Check the pinout of the specific pad rather than trusting a photograph: original Nintendo pads, third-party pads and reproductions do not always number their leads alike. Identify power, ground, clock and data with a meter, then add local decoupling and reverse-polarity or ESD protection around the connector.

A USB-powered adapter offers a useful power boundary. Regulate 5 V locally for the pad, let the MAX3232 handle data, and fit a 100 nF ceramic capacitor plus a small bulk capacitor near the controller socket. If the pad is powered from an original console instead, isolate its 5 V rail and avoid creating a second ground path. Many Japanese X68000 supplies are rated for 100 V, while Australian mains is 230 V at 50 Hz and domestic outlets use Type I plugs. Use an appropriately rated step-down isolation transformer and inspect the supply before energising it. Heat in Brisbane and Melbourne and humidity in Sydney also favour protected connectors and dry storage.

Building the Human68k driver

Treat the adapter as a framed serial device rather than a direct SNES controller. Here, a driver means a Human68k device library or service, not a Linux kernel module. The host side needs four wrappers around the IOCS or B-PORT facilities available in the chosen toolchain: configure the UART, write bytes, read with a timeout, and report line status. Keep these wrappers separate from game code so applications receive a stable 16-bit button mask rather than protocol details.

A request carries a command and sequence number. The reply repeats that sequence number, adds the button bytes and ends with a checksum. This lets the driver reject stale data from an earlier query. The following pseudocode assumes the serial wrappers have been implemented for the selected X68000 BIOS and compiler environment:

#define PAD_REQUEST 0x01

int x68k_pad_get(pad_state *state)
{
    unsigned char tx[3] = { 0xa5, PAD_REQUEST, pad_sequence++ };
    unsigned char rx[6];

    if (x68k_serial_write(tx, sizeof tx) != sizeof tx)
        return -1;

    if (!x68k_serial_read(rx, sizeof rx, PAD_TIMEOUT_MS))
        return -1;

    if (rx[0] != 0xa5 || rx[1] != 0x81 || rx[2] != tx[2])
        return -1;

    if (crc8(rx + 2, 3) != rx[5])
        return -1;

    state->buttons = rx[3] | ((unsigned int)rx[4] << 8);
    return 0;
}

The driver should open the serial resource once, request button state at a modest rate such as 50 to 100 times per second, and translate the result into an ioctl-style operation for applications. Keep hardware calls out of interrupt handlers. A game can ask for the latest state while the driver owns the UART, timeout policy and error counters. Applications should receive a positive byte count or a defined error code, with zero reserved for “no change” and separate status values for timeout, framing failure and disconnected hardware.

If the implementation also uses an MFP timer or UART receive interrupt, consult the interrupt priority notes before assigning handlers. Human68k programs must preserve registers, avoid unsafe operations in interrupt context and account for priority and masking on the X68000. Receiving a complete packet in the driver and publishing it in a small shared buffer is usually safer than waking an application for every byte.

Testing the controller and the driver

Bring the adapter up in stages. First test the SNES side without the X68000: check the 5 V rail, issue a reset and button query with the microcontroller, and inspect clock, command and reply on a logic analyser. Verify that the first reply bit is not shifted by a missing or extra clock. A UART loopback test should precede the controller test: return known request bytes, then inject a known reply, so a bad baud rate or checksum implementation is not blamed on the pad. Finally, connect the RS-232 side and confirm framing, polarity and timeout behaviour with a known request sequence.

Test the finished driver with every button, diagonals, opposing directions and several buttons held together. Repeat those tests while the controller cable is flexed, because a marginal data line can resemble a software bug. Disconnect the pad to test timeout handling, then introduce controlled line noise or corrupted bytes to confirm that checksums and sequence numbers reject bad packets rather than returning phantom presses.

Australian collectors often turn such a build into a weekend “soldering arvo”, and groups around Sydney, Melbourne, Adelaide and Brisbane have the skills to review a design. Parts are easiest to source through specialist dealers, eBay Australia and other local sellers; Australia Post padded packaging and careful double-boxing make vintage displays and controller cables safer in transit. Cross-references from the TFOSORCIM community can help with regional meet-ups, repair notes and people who still know the original Japanese controller conventions.

Preserving the project and passing it on

Record every decision that another custodian cannot recover from the hardware: the measured pinout, logic levels, UART settings, packet layout, timeout values and test results. Photograph the board before fitting it to an X68000, and keep a copy of the adapter firmware beside the Human68k source. A version-controlled repository can hold the code, while a dated narrative in the project diary can explain why the design changed.

The preservation goal is practical. A reproducible adapter lets more than one person service a pad, compare notes and replace a failed board without reverse-engineering the original. It also turns an isolated curiosity into a reusable X68000 peripheral, with the distinction between original hardware, modern components and tested substitutions made clear.

Build the interface, verify it against the logic analyser, document the schematic and driver, and publish the results for the next X68000 enthusiast. Share the adapter with the hobby community so the SNES controller remains a working input device rather than a display object.