31 Jan
2025
31 Jan
'25
1:50 p.m.
On Jan 31, 2025, at 4:30 PM, Maciej W. Rozycki via
cctalk <cctalk(a)classiccmp.org> wrote:
On Fri, 31 Jan 2025, Steve Lewis via cctalk wrote:
Was that with an actual RS232 port, i.e., a device using RS232 signal levels, or a
"TTL" logic level serial port? I'm guessing the latter.
In my high speed experiments, I found that the limit for RS232 data rates comes from the
relatively slow rise/fall times implemented in RS232 drivers. If you have a port that
uses logic levels the transitions are likely to be much faster so loss of signal integrity
occurs only at much higher speeds. With the RS232 drivers I have used (MAX3222), 250 kbps
is roughly the upper limit.
paul
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.