I do serial transfers at 115k all the time with DDLINK - are you sure your problem is cableing?

Run a terminal program - on the other system in DOS use MODE to set the speed, then: CTTY COM1
You should see the DOS prompt appear in the terminal program on the other system.

Capture output to a file, then > TYPE {largish text file}

Then make sure the file you captured has text from the file you TYPed without errors/missing characters etc.

I don't really know FASTLYNX but I assume it has error detection/retransmission ... so I'm guessing when it "aborts" it has already tried a bunch of times...

The only times I've seen this type of thing is with an old 8088 @4.7 - that couldn't get a packet transferred at 115k - does it work at lower speeds?

You could try DDLINK - available (free) on my site.

stanwebber wrote on 2026-06-06, 12:23:

i thought maybe the cat5a twisted pairs were causing interference since i just pinned it straight thru 1-8 so i re-pinned both adapters using a strategy to separate the related communication wires as far apart as possible.

there is no as far away as possible in ethernet cable, everything is twisted with each other. The best strategy is putting signal pairs on twisted pairs so RX /TX on 1 and 2 or 3 and 6 or 4 and 5 or 7 and 8 pins of rj45 connector.

stanwebber wrote on 2026-06-06, 12:23:

at this point i gave up and purchased a retail 1 meter null modem cable from rocstor.com--same result as the cat5a patch cables! ok, i don't know anything about rocstor's reputation so let's try a startech.com branded 1 meter cable. again, no difference!

so not the cables.

stanwebber wrote on 2026-06-06, 12:23:

what is going on?

Different computers. You can have
- failing from old age rs232 voltage translators, on ancient hardware something like MC1488 MC1489 pair, on never one max232/max 3232 or GD75232 something more proprietary. Those chips convert TTL 3-5V to +-15V
- some cheap ass manufacturers didnt bother generating +-15V in the first place and opted for +-9V or even not doing negative voltage at all.
- one of your computers is OLD, so old its not using 16550 chip. It might have 16450 or even 8250.

RS-232 doesn't spec twisted pair - but I've run RS-232 through all kinds of twisted pair wires - Cat5 - even old 4-wire phone cable.

Any chance the serial port isn't +/-12v ? That's what's normally used on a PC since those supplies are available - but RS-232 specs anywhere from +/-3v to 25v. I find the 12v pretty robust and reliable - even over very long cables.

Some "cheap" serial ports only do +/0v which mostly works with most RS-232 receivers - but it out of spec. and can be very unreliavle.

sorry for the delay in responding...i'm pretty sure the ports on both sides are 16550a. to be specific the systems are an nec versa p laptop (pentium p54c) and an iwill kk266 (athlon xp). nothing has changed in this setup except the null modem cables and time. accelerated 7-wire mode does work reliably at 57kbps and i can even transfer several mb at 115kbps without usually running into problems--anything larger in size invariably fails. (115kbps non-accelerated also works reliably.) the systems are old, but not ancient. surprisingly, the laptop is the more stable of the 2. i suppose i could break out my multimeter to check things. what pins should i be probing and is there a risk of my frying anything?

The fastlynx manual suggests that the null modem cable needs TX-RX and RX-TX which makes sense obviously, plus RTS-CTS and CTS-RTS for hardware flow control, but also specifies DTR-DSR and DSR-DTR. You can't assume a random null modem cable will have DSR-DTR wired that way. I've seen DTR wired to CD instead for example, and DSR possibly unconnected altogether or connected the local end's own DTR so that it's just reflected back. Since they're quite particular about "7-wire" who knows what they're using DSR/DTR, for example, if they drop DTR in the middle of the connection as some second-level flow control.

What OS, hardware and other software are you runniong?

DOS and W9x work well, XP can have bad serial emulation in DOS mode, esp. if it ever goes "windowed" (open COMMAND in full-screen only). Stuff running in "background" can cause problems with high-speed interrupt response.

I've never had problems with anything 386+ ... I do have a PoqetPC (Battery powered 8088) which can't do >19200 reliably.

Try under DOS (or 95/98 restarted in DOS mode). Have you tried my DDLINK? - it uses interrupt driven serial I/O code I've used at high speeds for many years without problems - it only needs 3-wire (Rxd,Txd,Gnd) null modem.

It also include SDT (SerialDebugTerminal) which will let you test in detail your COM ports.

Are the serial ports on-board or on an ISA card?
If it's ISA it might help to change the affected IRQ/DMA from PCI/ISA PnP to Legacy ISA in CMOS Setup.
It helped me when I was using an multi-i/o card in a 586 system.
Before the change, I couldn't reliably open the serial port in DOS.
After it, I was able to use 9600 Baud no problem (old UART FiFo on the ISA card).

i'm running fastlynx between win98se and dos 7.0 (or sometimes win95rtm) on the aforementioned hardware. all serial ports are onboard com1 ports. it's possible the store bought cables are wired in some unexpected ways, but i wired the db9 to rj45 adapters myself and i did it twice in different twisted pair configurations and i know i got it right both times. in any case, i could break out a continuity tester to know for sure how the retail cables are wired (at least the ones i still have).

no, i haven't tried ddlink, but i suspect it will work just fine since it's not trying to do any flow control on the extra wires. however, my impression is that 7-wire accelerated mode is more than just hardware flow control to free up more bits on the tx/rx lines. isn't there another data stream on one of the extra pairs or do i have that wrong? why would you need 4 wires just to do flow control for 1 pair of tx/rx lines? wouldn't 5-wire accelerated be enough?

^Historical reasons, I think.
There's RXD, TXD and GND for actual data. RTS/CTS and DTR/DSR for handshaking (flow control).
On PC, RTS/CTS was often used in the 90s, DTR/DSR were used in early to mid-80s.
But strictly speaking, both pairs used to have different purposes.
One was meant for terminal (DTE) point of view, the other for the modem point of view (DCE).
Together, they (DTE+DCE) can ask each other if they are ready to communicate.

Edit: The status lines (handshaking pins) could also be used as extra transmission pins.
So you basically have 3x RXD/TXD. It's like a small parallel port, basically.
By including the RI pin (ring indicator), a serial port can even receive a nibble.
(Edit: I forgot, there's DCD, too. Another input pin.)

Similarily, on the old parallel port (Centronics or SPP), the status lines had been used to receive 4 bits (a nibble).
Some applications also used the parallel port as a fast serial port, by just using one data line for transmitt and one status line for receive.

Edit: I've once stumbled upon a website about null-modems.
The thread has a link to a version archived by the internet archive.
A Null-Modem is a Null Modem, right?

Edit: Too many edits. Sorry about that.

Edit: Note that the "proper" full-size null-modem schematic shown on that website differs from the usual null-modem schematics found on the internet.
It might be that certain software assumes a certain wiring, thus.

For example, DTR/DSR aren't just cross wired to each opposide, but RI is also connected on one side.
Or RTS/CTS: They're not simply cross wired to each opposide, but are wired on same side. RTS+CTS then connect to DCD on opposide.

Edit: Attached pictures for illustration.

RS-232 was developed wwaaayy back in the day when interaction with computers was almost all via serial "terminals" - these were often slow mechanical devices, and had no processor or storage and had to be "ready" to receive a character.

Communication over distance was through a "modem" - these had no processor or storage, were unidirectional and had to be ready to transfer each character in a particilar direction.

Hence the common RS-232 control signals DataTerminalReady(DTR), DataSetReady(DSR), RequestToSend(RTS) and ClearToSend(CTS). DTR/DSR usually indicater that terminal or modem was online, and CTS/RTS controlled byte-by-byte transmission (Modems would go Host->Terminal by default, RTS by terminal would request Terminal->Host and CTS would indicate the modem was ready to do so.

Computer<->computer didn't make sense and was almost never used! Hence the "null modem" cable with wired DTR->DSR and RTS->CTS so that the requests would appear as ready to the other end.

Like any standard these got "adapted" (sometimes in unusual ways) as the tech advanced, and were often used for "flow control" when sending data to slow devices.

---

Modern serial shouldn't need these, but reminents remain (eg: native DOS needs RTS/CTS, DTR/DSR - hence to "bootstrap" DDLINK over serial, you need a 7-wire cable (Rxd/Txd, Dtr/Dsr, Rts/Cts, Gnd). In normal use DDLINK needs only 3 (Rxd/Txd, Gnd).

As long as the PC can process interrupts at speed/10 (10 bits/char, 115200 = 11520 bytes/sec) there is no "flow control" needed.

The higher level protocol covers transfer speed control - packet of data is sent, processed, and Ack is returned.

Knowing that many will have to make null-modem or parallel-transfer cables, I include SDT.COM(SerialDebugTerminal) and PPDEBUG.COM(ParallelPortDEBUG) with DDLINK.

SDT will let you control the state of Txd, Dtr and Rts, and lets you see chars received and the state of Dsr, Cts, Ri and Cd) - you can use this over two systems to confirm that your cables are wired exactly correctly.

RingIndicator(RI) was used only during initial connection of traditional (dumb) modems and is almost never used today.

CarrierDetect(CD) was used to tell when a modem was actually connected to the far-end, and also to tell if it disconnected.

Both these signals are generated by the modem (DCE) and in PC<->PC serial connections should not be required - a PC actually "looks" like an RS-232 terninal DTE). This is why DOS itself doesn't need these signals.

But... like I said earler - sometimes reminents remain. I've not seen any "modern" comms package that needs RI - some need CD and in some null-modem configurations CD and DSR and both wired to "other end" DTR - but this is rarely needed for anything intended as PC<->PC (which is usually where you need a null-modem).

what is the deal with pin 8 and/or 9 being bridged to other thu wires? i've seen those diagrams and it makes no sense for interference reduction or otherwise. i've wondered before if that golden 10m cable was wired this way.

fastlynx 7-wire accelerated mode really is significantly faster. i mean removing 1 (2?) handshaking bit for every 8 bits is already a substantial speed increase, but fastlynx must be using some special sauce to achieve performance above that. hell, i've read newer serial ports (certainly 16550a) are timing accurate enough to do hardware handshaking without the actual wires being connected and instead looped back on themselves.

i guess i will continue to use 7-wire accelerated mode for files up to a few mb in size and break out the cf adapter for anything larger. perhaps i will do a head-to-head transfer speed test with ddlink and while i wasn't motivated to dig out a continuity tester, i will use that sdt tool on the cables when i get the chance.

stanwebber wrote on Yesterday, 12:51:

... i will do a head-to-head transfer speed test with ddlink ...

DDLINK uses standard async serial = 10-bits (1 start, 8 data, 1 stop)
This does not need overly precice timine as it resyncs on every character. Perhaps 16550 can do some form of synchronis transfer (8 bits) which normally needs a clock as well.

I did some speed tests: Re: DDLINK: Easily move files between/To/From DOS systems

and DDLINK came pretty close to the thoretical max (speed/10 bytes sec)
there is a small bit of overhead but with 1024byte packets it is very small.
Obviously LPT and LAN are much faster.

I've never seen/used/tested fastlynx.

stanwebber wrote on Yesterday, 12:51:

what is the deal with pin 8 and/or 9 being bridged to other thu wires? i've seen those diagrams and it makes no sense for interference reduction or otherwise. i've wondered before if that golden 10m cable was wired this way.

Wouldn't have anything to do with interference, rather that arrangement defeats RTS-CTS flow control and instead use RTS-CD flow control by connecting 7 and 8 at each side (when the DTE asserts its own RTS, it's reflected back on its own CTS), and the 6 to 9 connection means RI (not just DSR) is held asserted as long as the opposite end's DTR as asserted too.

Neither of those makes much sense to me, it wouldn't work with standard comms software where RTS-CTS is legitimate flow control, and RI only goes high during active ringing to bring the PC out of sleep mode (where supported).

Are you absolutely certain that the serial port hardware interrupts are configured correctly and working?

Depending on how the software accesses it, a serial port may appear to work properly at lower speeds even when it's interrupt is not functioning, and fail miserably at higher speeds.

Years ago I wrote a TSR to let you see the lask 8k or so of selected interrupt occurances ... if needed I can try to dig it out when I'm back in my lab.

This has also given me an idea - perhaps at some point I will enhance SDT with an option to keep track of and display how many interrupts were processed during a session.