1
0
mirror of https://github.com/hsoft/collapseos.git synced 2024-11-15 10:18:06 +11:00
collapseos/doc/hw/acia.txt
Virgil Dupras 0f83451193 trs80: Improve RS-232 driver
I could drive my RC2014 from my TRS-80 4P (using the Remote Shell
coming in the next commit)! A challenge I faced was that the RC2014
spits characters too fast and the CTS line of its ACIA modules
(both the 6850 and SIO/2 ones) are hard-wired to ground, making
flow control difficult. I solved this, for now, by lowering comm
speed.

This driver improvement makes CL<? faster and makes baud rate
configurable in CL$.
2021-01-03 13:56:53 -05:00

44 lines
1.7 KiB
Plaintext

# Asynchronous Communications Interface Adapters
Machines talking to each other is generally useful and they
often use ACIA devices to do so. Collapse OS has drivers for
a few chips of this type and they all have a similar approach:
unbuffered communication using RTS/CTS handshaking as flow con-
trol.
The reason for being unbuffered is simplicity and RAM. The logic
to implement input buffering is non-trivial and, alone, doesn't
buy us much in terms of reliability: you still have to signal
the other side when your buffer is nearly full.
Because we don't really need speed, we adopt a one-byte-at-once
approach: The RTS flag is always high (signalling that it's not
ready for communication) *except* when calling the ACIA driver's
"read" word, which is blocking.
That "read" word will pull RTS low, wait for a byte, then pull
it high again.
This slows down communication, but it's simple and reliable.
Note that this doesn't help making communications with modern
systems (which are much faster than a typical Collapse OS
machine and have their buffer output faster than the RTS flag
can be raised) very much. We have to take extra care, when
communicating from modern system, not to send too much data too
fast. But for COS-to-COS communication, this simple system
works.
# Broken hardware
Some designs are broken with this scheme. For example, the
RS2014 SIO module hard-wires CTS to GND because the FTDI
connector doesn't have such a pin (modern computers can always
handle the load).
In these cases, a solution would be to use Break signals as a
workaround, but I prefer avoiding complexity for now. So when
you deal with broken design, you'll have to sidestep it either
by implementing your own Break handling or by lowering com-
munication speed.