31 Jan
2025
31 Jan
'25
1:30 p.m.
On Fri, 31 Jan 2025, Steve Lewis via cctalk wrote:
So while some protocol gets developed for that system,
I experimented with
other actual vintage system trying to "talk to" a modern PC (where
"modern
PC" is a 3GHz i7 laptop). For the actual task of transferring files, there
are many other better options, but I still wanted to "push the envelope" of
what classic RS232 could do on these systems.
And it was interesting that even modern-PC to modern-PC, it only handled
460Kbps. But it causes two "opposite" questions:
1) How is it even doing over 115.2Kbps? (is that still "RS232"?)
2) Why is it so slow even on modern systems?
FWIW I was able to get reliable serial communication under Linux of up to
3.5Mbps with off-the-shelf proper PCIe UART hardware clocked at 62.5MHz
despite that line drivers used with said hardware (soldered onboard) were
spec'd for up to 1MHz only[1]. This was with plain PIO interrupt-driven
operation, but then the UARTs used had decent FIFO sizes of 128 characters
and the FIFO trigger level for the interrupt was reasonably set.
Finally at 4.0Mbps data corruption reproducibly triggered, but it was
garbled rather than lost characters, so I conclude the reason was either
line drivers finally giving up or the transmission frequency hitting the
bandwidth limit of the serial communication cable used.
That was actually with POWER9 hardware rather than a boring x86 PC, but I
don't think the architecture of the system mattered much if at all.
So I tested a bunch of (relatively modern, post-UART)
vintage systems:
4.77MHz PC w/ 1.8MHz/8250, 12MHz 286 (with Unknown), 386/486, and a Pentium
all null-modem connected to a modern-make PC - just to verify how fast they
should be pushed (download) a data stream. None of them (not even the
Pentium) could be clocked past 115.2K on this serial line. (I know the
host system isn't dictating the speed, but whatever integrated UART is
available-- then the software that controls that UART to clock divide to
"commonly defined baud rates").
With slower host hardware and PIO operation this just boils down to
interrupt handling latency vs UART FIFO sizes. If a receive interrupt
cannot be served in time for the FIFO to keep from overflowing, you'll get
dropped characters. If there's no FIFO and all you have is the receive
shift register, then it's getting hopeless very quickly, just as it used
to be the case with the 8250/16450 UARTs.
With DMA (e.g. Zilog Z8530 SCC or some 8250 improvements) you should be
able to run at higher baud rates just fine even with slower host hardware
as the DMA transfer can continue between the UART and host memory while
the CPU gets to serving an interrupt request; that's how synchronous
serial protocols normally operate too.
References:
[1]
<https://lore.kernel.org/r/alpine.DEB.2.21.2106071700090.1601@angie.orcam.me.uk/>
Maciej