A quick look at older usages

As an introduction to this segment, it may be useful to review how data connections have developed historically. At first, a simple terminal was connected by its own dedicated connection to a port of a central computer: those who worked with "minicomputers" will probably remember what I have in mind. The IBM3270 terminals are a surviving, though not very typical, example also. Later, terminals were connected, usually via an asynchronous serial line, to a terminal concentrator, which in turn was connected to a network, giving you the ability to connect to a choice of remote central computers: this is what happens with a PAD (on an X25 network such as JANET), or a DECserver (on an Ethernet). Finally, we come to the situation where you have a computer on your desk (a micro such as a PC or Mac). It is, of course, possible to run "terminal emulation" software on such a micro, and connect it in the same way as a simple terminal, but this misses the versatility that is possible if you connect your micro to a network.

IBM3270.
There's not a lot I want to say about this method. Those who had IBM3270-type terminals will recall that they connect to the room socket via a little blue gadget called a Balun, or balanced-to-unbalanced converter. At the hub end, another balun connects each terminal to its own coaxial port on the terminal controller or multiplexer.

Asynchronous serial lines (V24/RS232)
Strictly speaking, this standard was designed for connecting a terminal equipment to a modem, over a relatively short cable. It is no secret that it works in practice over quite long lines, say 100m, without modems, up to 9.6kb/s or even 19.2k.

We use such a link to connect a terminal (or a micro's COM port) to a CAMTEC X25 PAD, located at the patch centre ("PAD" stands for Packet Assembler-Disassembler, as usual). Dedicated connections from a terminal to a specific computer are used in a few cases (e.g computer operators). Normally, apart from signal-return, only the data transmit and receive lines are used, and the terminal-ready control line DTR (optional), accounting for four of the eight available wires. In situations which call for additional control lines to be used, one would either allocate some of the unused wires to them, or install short-haul modems at each end to provide full 'hardware handshaking'. As a terminal connection method, no automatic error recovery is provided: this isn't a major problem for us in practice.

The Nuclear Structure group have their own DECservers, which they operate in an analogous way.