Building a handshaking serial-to-USB adapter for X68000

The Sharp X68000’s built-in serial facilities still connect the machine to modems, terminals, controllers and other period hardware. A cheap USB lead solves only part of that job: if it carries receive and transmit but ignores RTS, CTS, DTR or DSR, software that waits for a handshake can stall or overrun. A useful adapter must reproduce the electrical interface and the control-line timing. Learn more about Windowsで複数のオーディオインターフェースを同時使用するときのサンプルレート統一法.

The safest approach is an external, reversible unit rather than a motherboard modification. It should sit between a confirmed X68000 port and a modern USB host, expose the control lines the target software actually uses, and leave the original computer untouched. This makes the board useful with several peripherals and keeps the experiment within reach of hobbyists who lack original cables.

A practical build starts at the connector, moves through the RS-232 transceiver and USB bridge, then ends in host configuration. Hardware flow control must be distinguished from XON/XOFF, and electrical assumptions must be checked against the particular X68000 model. For Australian readers, parts sourcing, imported-chip GST, summer heat and electrical safety rules are part of the design, not afterthoughts.

Establish the port’s actual behaviour

Begin by identifying the exact machine, port and peripheral. The original X68000, ACE and related variants should not be assumed to share every connector detail. Consult the service documentation and schematic, then photograph the connector and trace each relevant pin to the interface IC. Board-specific notes in https://x68k.net/diary can help identify a revision, but they must be checked against the machine in hand.

Next, establish whether the X68000 port behaves as data terminal equipment or data communications equipment in the cable you need. Most serial links pair TXD with RXD, but null-modem and straight-through conventions vary by documentation. Hardware handshaking normally pairs each RTS output with the far end’s CTS input and each CTS input with the far end’s RTS output. DTR and DSR may also form a readiness pair, depending on the peripheral.

Record the software settings too: baud rate, data bits, parity, stop bits and the selected flow-control mode. XON/XOFF sends in-band pause characters and is not the same as RTS/CTS. If the application offers no hardware-flow option, an adapter cannot create the missing handshake, although a terminal that exposes individual modem-control lines may still be useful for experiments.

Choose a suitable USB-to-serial bridge

Choose a USB-to-serial bridge with the control pins genuinely accessible, not buried inside a moulded cable. CH340, PL2303 and FT232 devices are common choices, but module revisions matter. The useful features are a receive input, transmit output, CTS input and an RTS output that either follows USB buffer space or can be driven by software. Confirm the chip’s TTL voltage and Windows, macOS and Linux driver situation before laying out the board.

Australian hobbyists can buy from eBay Australia, AliExpress and local outlets such as Jaycar, Core Electronics or element14, although stock and genuine chips vary. Sydney and Melbourne collectors often find donor cables and sockets through Gumtree, Facebook Marketplace and specialist dealers. Direct low-value imports may attract GST at checkout, so include tax and postage when comparing a cheap module with one held locally.

Buy the bridge and transceiver before committing to connectors or an enclosure. PL2303 modules with older controller revisions have caused Windows driver problems, and look-alike USB devices may install under misleading names. A CH340G is inexpensive and easy to prototype around; an FT232RL costs more but usually gives a smoother cross-platform path. Driver evidence and a socket with accessible pins are more valuable than the lowest advertised price.

Convert levels and wire the handshake

USB UART logic is not RS-232. Connect the bridge to a proper line transceiver such as a MAX3232 for either a 3.3 V or 5 V design; a MAX232 is usable when its 5 V supply matches the rest of the circuit. Follow the exact data-sheet pinout because similar packages differ. Place a 100 nF ceramic capacitor at the transceiver supply pins and the specified charge-pump capacitors close to the IC, with suitable bulk capacitance on the USB rail.

At the cable side, the essential routes are X68000 TXD entering the adapter’s receiver and reaching bridge RXD; bridge TXD passes through a driver to X68000 RXD. For a direct link between two data-terminal devices, bridge RTS goes through a driver to X68000 CTS, while X68000 RTS enters a receiver and reaches bridge CTS. Add crossed DTR and DSR only if the target software uses them; a MAX3232 has enough channels for both pairs.

Connect signal ground between the machines, but keep cable-shield bonding under control to avoid an unnecessary ground loop. RS-232 uses bipolar signalling: with a conventional transceiver, the mark state is normally a negative voltage at TXD. A multimeter or oscilloscope should confirm that the bridge side is TTL and the connector side is RS-232 before it is attached. Match the D-sub gender and locking screws; a gender mismatch can lead to crossed pins inside an adapter lead.

Configure flow control in software

Configure the bridge as a hardware-flow device. On many implementations RTS rises when the USB receive buffer has room, allowing the X68000 to transmit; the bridge’s transmitter is held off unless CTS is asserted. That is the timing relationship the X68000 software expects when RTS and CTS are crossed correctly. If a module does not automate RTS, use a driver-supported request or a small interface circuit to control it.

Hardware flow control must be selected in the host application as well as in the device driver. Windows programs can use the COM port’s RTS and CTS state, and command-line or diagnostic tools can display and change the lines. On Unix-like systems, the terminal termios settings can enable hardware flow control. Confirm that the chosen program actually opens the port with that option instead of quietly falling back to XON/XOFF.

Treat DTR and DSR as a separate control path. Some equipment uses DTR to request that a modem enter or leave a ready state, while DSR reports equipment availability; wiring them incorrectly can make a transfer begin too early. Record the expected idle states and the point at which each line changes. That log is more valuable than assuming every serial device follows the same RTS/CTS sequence.

Protect the hardware from electrical mishaps

Power the bridge and transceiver from the USB host, and do not take power from an unknown X68000 serial pin. Check every chip variant’s input tolerances so an unpowered bridge is not back-fed through a protected I/O pin. Connect the host and X68000 grounds in the intended way, or use a genuinely galvanically isolated serial interface if separate power supplies create a problematic path. Isolation must carry the handshake signals as well as data.

Use a small enclosure, strain relief and ESD protection, with the board mounted away from warm power supplies. Brisbane’s summer heat can raise the temperature inside a sealed case, while Sydney’s humid coastal environment encourages corrosion on poorly protected joints. Good ventilation, clean connectors and a light conformal coating on the underside of the board are inexpensive safeguards. Keep the transceiver close to the socket and the USB electronics separate from analogue wiring.

A mains-powered design raises the legal and safety stakes. Australian mains is 230 V, so keep it out of the adapter and use USB bus power or a certified external USB supply. Any mains unit sold in Australia should carry RCM compliance for the relevant product category. Commercial sellers must also meet applicable electrical safety and Australian Consumer Law obligations. A hobbyist who builds only from extra-low-voltage USB parts avoids much of that risk, but should still document voltages and polarity before testing.

Test data and control-line behaviour

Test in stages. First, use a loopback fixture to prove that transmitted bytes return intact and that the USB driver creates the expected COM device. Try several common baud rates with 8 data bits, no parity and one stop bit. A simple terminal is useful, but do not interpret successful text scrolling as proof that the handshake works; the control lines need their own test.

Next, watch RTS and CTS with an oscilloscope, a suitable RS-232 probe or a high-impedance indicator while the X68000 and host exchange data. The required lines should change only when the driver and application request it. Connect to the real peripheral and repeat with both supported and unsupported flow settings to expose timeout or overrun symptoms. If a second known serial system is available, a null-modem lead provides a useful cross-check.

Keep serial timing separate from audio timing on the same Windows bench. The Japanese sample rate unification guide explains the related clock-matching problem for multiple audio interfaces; it does not replace RTS/CTS, but can help interpret jitter reports that originate elsewhere.

The practical differences between common bridge choices come down to exposed control pins and driver support. All of them still need a separate RS-232 transceiver such as a MAX3232.

Bridge	Control signals exposed at TTL side	Host support	Practical trade-off
CH340G	RTS, CTS, DTR and DSR	Common Windows and Linux support; macOS requires a suitable current driver	Low cost, but automatic RTS behaviour must be checked on the exact module
PL2303HX	RTS, CTS, DTR, DSR, DCD and RI	Broadly supported, although older controller revisions can need newer drivers	Convenient pin access, but driver provenance and counterfeit chips matter
FT232RL	RTS, CTS and other modem-control signals	Mature Windows, macOS and Linux support	Higher cost, but usually the smoothest cross-platform choice

Document the build for continued X68000 use

Keep the adapter external so the X68000 remains reversible. Save the schematic, board photographs, connector orientation, chip versions and measured idle voltages in a dated project folder. Include the working host settings, test cables and any changes made to the USB driver. A paper sketch without revisions is less useful than a versioned drawing that another hobbyist can reproduce.

Long-term value comes from publishing the evidence with the machine documentation. A dated project entry can show which assumptions were measured rather than guessed, helping others avoid damaging a rare serial interface. A scope capture of the handshake also lets the next builder distinguish a driver problem from faulty wiring.

Choose one confirmed X68000 peripheral, build the adapter on an external board, verify the handshake with a scope, and publish the schematic and test results. That repeatable path keeps the platform useful while preserving the original hardware for the next experiment.