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 implement those words:

TX>  c --    Send char c through the device
RX<? c? f -- Poll device for character

The rest of the implementation is device-specific, but those two
words are enough for applications like the Remote Shell and the
XMODEM implementation to work.

Flow control

All drivers in Collapse OS have a similar approach: unbuffered
communication using RTS/CTS handshaking as flow control.

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.