How to Build a Reliable FreeDOS Serial Link for Retro Hardware

Determine whether the devices you’re connecting require a null-modem or a straight-through cable before touching any software configuration — wiring built for the wrong topology will not be fixed by any setting on either end, no matter how carefully everything else is configured.

Step 1: confirm the wiring topology first

A null-modem cable crosses transmit and receive lines specifically so two DTE (data terminal equipment) devices — two computers, for instance — can talk to each other directly; a straight-through cable is built for connecting a DTE device to a DCE (data communications equipment) device like a modem, where that crossing already happens inside the device itself. Wiring the wrong topology produces symptoms that look exactly like a software or speed misconfiguration, which is why this needs confirming before you spend time adjusting anything else.

Step 2: match every parameter at both ends

Baud rate, data bits, parity, and stop bits must match exactly at both ends of the link, and both sides need to agree on whether flow control is hardware (RTS/CTS) or software (XON/XOFF) — a mismatch in any single one of these produces garbled or dropped characters that look superficially similar regardless of which specific parameter is actually wrong.

Step 3: start conservative with a plain terminal program

Begin at a deliberately conservative baud rate using a simple terminal program on both ends, and verify that typed characters arrive correctly in both directions before attempting anything resembling a real file transfer. Confirming basic two-way communication first isolates whether a later file-transfer failure is a protocol-level problem or a more fundamental link problem you’d otherwise be troubleshooting blind.

Step 4: use an error-detecting protocol for actual file transfer

Raw terminal capture has no error correction at all — for real file transfers, use a protocol supported by both endpoints. XMODEM, the original 1979 protocol, moves data in 128-byte blocks with a simple checksum; XMODEM-CRC and YMODEM upgrade that to a considerably more reliable CRC-16 check and add batch multi-file transfer; ZMODEM, developed in 1986, adds streaming throughput and automatic transfer resumption on top of the same underlying error-detection lineage. Compare file hashes after transfer regardless of which protocol you use — a completed transfer with no reported errors is reassuring but not the same guarantee as an actual hash match.

Step 5: understand where high baud rates actually break down

The 16550 UART, introduced in 1987, added a 16-byte FIFO buffer specifically to solve a real problem with its 8250/16450 predecessors: above roughly 9600 baud, a single-byte receive buffer couldn’t reliably keep up with continuous incoming data on a period-typical CPU, and characters were silently dropped. Confirm which UART generation your actual hardware (or emulated serial port) provides before pushing to a high baud rate — an older UART or a sufficiently slow CPU can reintroduce exactly this dropped-character problem well below the link’s nominal maximum speed.

Step 6: increase speed incrementally, and keep a known-good fallback

Raise baud rate one step at a time rather than jumping straight to the link’s theoretical maximum, confirming reliable transfer at each step before going further. Keep the last confirmed-working configuration documented separately, so a failed attempt at a higher speed has an immediate, known-good profile to fall back to rather than requiring you to re-derive working settings from scratch.

Step 7: never wire RS-232 directly into TTL-level equipment

For embedded or vintage equipment specifically, confirm and document the actual voltage levels involved before wiring anything. RS-232 signaling operates at considerably higher voltages than TTL-level serial logic, and connecting one directly to the other without a proper level-shifting circuit in between risks damaging the TTL-level device — this is a hardware safety concern, not merely a configuration detail.

The DB9-to-DB25 pin-numbering trap

If either end of your link uses the older 25-pin DB25 connector instead of the now-more-common 9-pin DE-9 (commonly called DB9), don’t assume identical pin numbers carry the identical signal — they don’t. On a DB9 connector, pin 2 is receive data and pin 3 is transmit; on a DB25, that assignment is reversed, with pin 2 as transmit and pin 3 as receive. A cable or adapter built assuming pin-number equivalence between the two connector types wires transmit to transmit and receive to receive instead of properly crossing them, which produces exactly the kind of silent, confusing failure this whole troubleshooting process is meant to avoid. When adapting between connector sizes, work from each connector’s actual signal names, never from matching pin numbers alone. Related: Diagnosing IRQ and Driver Conflicts on Real Hardware Running FreeDOS · FreeDOS 1.4 Publishes a Floppy-Only Edition for Original PC-Class Hardware

Sources: