Lawrence D'Oliveiro
2024-06-29 03:43:44 UTC
Anybody remember “breakout boxes”? These were used for analyzing RS-232C
connections and figuring out how to get two different machines to
communicate via this supposedly “standard” connection protocol.
The standard connector had 25 pins, and I think most of them were used in
the full protocol. The original purpose was to define a connection between
a piece of “terminal equipment” (computer terminal, teletype, computer
interface) and a “data set” (modem), the latter of which communicated with
another data set via the phone network, which in turn had its own “data
terminal” connected at the other end.
But direct computer/terminal interfaces commonly used only a small number
of signals, and so correspondingly smaller connectors became common. E.g.
instead of the full DB-25, many PCs had DE-9 connectors with just 9 pins,
though of course Apple had to be different in using a DIN-8 connector.
Besides issues of bit rate, data/stop bits and parity, one common source
of incompatibilities was in how the two ends wanted to do flow control.
RS-232C did not define the concept as such. Some machines/devices used the
RTS (“request to send”) and CTS (“clear to send”) signal pins for this
purpose; one end asserted RTS when it had something to send, and the other
asserted CTS when it was ready to receive it. I think this was commonly
called “hardware” flow control. But I remember some devices wanted to use
DTR (“data terminal ready”) and DSR (“data set ready”) for this purpose
instead.
DEC gear, as usual, had the simplest possible hardware interface: just
three pins were used, one for transmitting data, the other for receiving
it, and the third for ground. Flow control was done by sending XON (CTRL/
Q) and XOFF (CTRL/S) characters in the data stream.
Of course, you then had to decide which was the “transmit” pin and which
was “receive”: RS-232C said that pin 2 (in the full 25-pin connector) was
for sending data from the data terminal to the data set, while pin 3 was
for going in the opposite direction. So if you wanted to connect two
devices, each of which thought of itself as a “data terminal”, then the
connecting cable crossed over the wires so pin 2 on one side went to pin 3
on the other, and vice versa. This was called a “null modem” cable.
Then you had devices that tried to be helpful in avoiding the need for
such a crossover, by transmitting on pin 3 and receiving on pin 2 instead.
How the devices actually behaved might or might not be documented
somewhere. Hence the need for a breakout box to hook into the connection,
and try to figure out what was happening from the blinking lights that it
showed. The box also came with little jumper wires that you could use to
connect the pins on the two ends in various ways, to assemble an ad-hoc
connection. Once you got a working arrangement, you then contacted your
hardware-expert colleague to make up a more permanent cable.
Oh, and did I mention that the connectors came in “male” (pins) and
“female” (holes for the pins) varieties? So you needed to have the right
matching connectors for each end of your cable.
connections and figuring out how to get two different machines to
communicate via this supposedly “standard” connection protocol.
The standard connector had 25 pins, and I think most of them were used in
the full protocol. The original purpose was to define a connection between
a piece of “terminal equipment” (computer terminal, teletype, computer
interface) and a “data set” (modem), the latter of which communicated with
another data set via the phone network, which in turn had its own “data
terminal” connected at the other end.
But direct computer/terminal interfaces commonly used only a small number
of signals, and so correspondingly smaller connectors became common. E.g.
instead of the full DB-25, many PCs had DE-9 connectors with just 9 pins,
though of course Apple had to be different in using a DIN-8 connector.
Besides issues of bit rate, data/stop bits and parity, one common source
of incompatibilities was in how the two ends wanted to do flow control.
RS-232C did not define the concept as such. Some machines/devices used the
RTS (“request to send”) and CTS (“clear to send”) signal pins for this
purpose; one end asserted RTS when it had something to send, and the other
asserted CTS when it was ready to receive it. I think this was commonly
called “hardware” flow control. But I remember some devices wanted to use
DTR (“data terminal ready”) and DSR (“data set ready”) for this purpose
instead.
DEC gear, as usual, had the simplest possible hardware interface: just
three pins were used, one for transmitting data, the other for receiving
it, and the third for ground. Flow control was done by sending XON (CTRL/
Q) and XOFF (CTRL/S) characters in the data stream.
Of course, you then had to decide which was the “transmit” pin and which
was “receive”: RS-232C said that pin 2 (in the full 25-pin connector) was
for sending data from the data terminal to the data set, while pin 3 was
for going in the opposite direction. So if you wanted to connect two
devices, each of which thought of itself as a “data terminal”, then the
connecting cable crossed over the wires so pin 2 on one side went to pin 3
on the other, and vice versa. This was called a “null modem” cable.
Then you had devices that tried to be helpful in avoiding the need for
such a crossover, by transmitting on pin 3 and receiving on pin 2 instead.
How the devices actually behaved might or might not be documented
somewhere. Hence the need for a breakout box to hook into the connection,
and try to figure out what was happening from the blinking lights that it
showed. The box also came with little jumper wires that you could use to
connect the pins on the two ends in various ways, to assemble an ad-hoc
connection. Once you got a working arrangement, you then contacted your
hardware-expert colleague to make up a more permanent cable.
Oh, and did I mention that the connectors came in “male” (pins) and
“female” (holes for the pins) varieties? So you needed to have the right
matching connectors for each end of your cable.
