Long before computers existed, before transistors - let alone ICs - were a gleam in anyone's eye, machines transferred serial data between themselves. The serial protocols we now implement with thousands of gates are hardly new; indeed, it's amazing to remember that our highly integrated communications devices are sometimes just modern versions of purely mechanical machines.
The invention of the typewriter changed the face of business as clerks no longer needed the precise handwriting skills of before. Inventors quickly realized that the typewriter also simplified the creation of printed words; the measly few dozen characters on the keyboard let operators construct any word, and indeed any book. Samuel Clemens, AKA Mark Twain, had one of the first typewriters, which is still on display at his house in Hartford Connecticut. (Which is a really interesting stop if you're in the neighborhood).
Smart folks tried a variety of schemes to build automatic typewriters which could send data over a phone line to another such device. Eventually the Teletype company, later acquired by AT&T, came to dominate the industry. In Teletype's parlance these machines are properly called "teletypewriters," but common usage used the company's name for the machine. Much like we've turned the proper noun Xerox into a verb meaning "to copy."
Teletypes used mechanical linkages exclusively to encode and decode characters into bit strings. There were no active elements in these units.
Even before World War II teletypes clattered noisily in the back of newsrooms and other facilities. Often these units had no keyboard, being nothing more than the old-time equivalent of a printer, spilling miles of yellow paper on the floor with the latest UPI wire reports.
"Weather machines" were almost ubiquitous, as the fledging airline industry looked for ways to anticipate fogged-in airports. These special purpose teletypes had their own unique character set that concisely represented different atmospheric conditions. Tens of thousands of weather machines were installed, later creating a glut of these beasts on the surplus market. I acquired one in the early 70s, a model 15 Weather Teletype, for use on a 12 bit home-brew computer. It drove the neighbors crazy when noisily dumping listings at 3AM. But that's another story.
Model 15 TTY
These early I/O devices managed, without the use of a single transistor or vacuum tube, to convert parallel data to serial, transmit it over a wire, and reconstruct that data stream onto paper. They were monuments to mechanical engineering.
Those were simpler times, long before UNICODE or even ASCII. The machines spoke a five bit code call BAUDOT. Twenty six letters, 10 digits and miscellaneous punctuation marks needed more than the 32 characters possible in 5 bits, so two special codes selected what was in effect an alternate character set. The shift key as we know it today did not exist; instead, "Shift Up" and "Shift Down" keys transmitted their own unique characters, and caused the unit to move the platen to select the characters on the upper row of the hammers.
Needless to say, all letters were capitals, a bit of history that doesn't quite seem to go away as even today on the Internet too many folks seem case-challenged, sending email consisting of all upper case or all lowercase letters. Maybe, like the Japanese soldiers who held out for a decade after the end of the War, these people are in technological hideouts, still using the tools of so long ago.
A common accessory was the paper tape reader and punch, the only sort of long term data storage then possible. Operators could type their messages off-line, the punch recording each character as 5 data holes across a thin paper tape. Connecting the machine to the "net" they would then run the tape through the reader. Small metal fingers probed the holes, checking all 5 in parallel at once.
To convert this parallel data stream to serial, the 5 fingers actuated switches connected to a device that strongly resembled the distributor in a car. Each switch went to a metal strip around the rim of the distributor; a spinning rotor dragged over each strip in turn, generating a stream of ones and zeroes, in serial, representing the character. It was breathtaking to watch.
Incoming data was assembled in reverse, using the distributor to feed the serial stream to the metal strips as the rotor spun.
The serial stream was therefore time-dependent. All machines had to use a rotor spinning at exactly the same speed, so the each of the bits, one after another, would be dropped onto the right metal strip. If the receiving rotor was too slow or too fast the data would be hopelessly scrambled. This was a simple matter of using a synchronous motor, tied in speed to the quite regular 60 Hz rate from every wall socket in the USA. Teletypes destined for Europe and other overseas locations needed a replacement motor to insure that the basic bit speed remained constant despite a 50 Hz line frequency.
Distributor schematic: Note the five sense switches that "felt" for the holes in the tape and routed the 5 bit wide parallel signal to the rotary distributor's 5 contacts arranged around a central post. A wiper rotated around on these contacts and converted the parallel to serial (the center pin is the serial output).
Clearly, though, the machines needed to transmit a tad more than just the five data bits. Something had to start the rotor spinning, in effect signaling the receiving machine that "hey, a character is starting to come." The sending machine therefore preceded each character with a "start" bit, a signal that fired up the motor at the other end.
An awful lot of levers and linkages moved to print a single letter; the machine took a little bit of time to stop, and to put everything back to an idle state before the next character came. An idle time, therefore, followed every character. This time was never really part of the transmitted data, as it was just an interval when nothing was on the line. It became known as the stop bit, or bits when more than one was required due to slowly moving levers.
RS-232 didn't exist then. Instead, these machines communicated via "current loop," a two wire interface where an open (like opening a switch) designated a logic one - the one signaling a start bit, for example - and a closed line meant a zero. When about 20 ma of current flowed through the circuit the system was idle. RS-232, by contrast, is a standard based on voltage, not current. Ones and zeroes are indicated by a few volts of negative or positive level.
RS-232 also designates a number of additional wires used for handshaking and status indications. Current loop never needed handshakes - if the teletype wasn't ready it just missed the data. Tough.
At the dawn of the microprocessor age the ASR-33 Teletype was still the standard way to communicate with computers. Video units were simply too expensive for most small systems. By the 70s ASCII was firmly entrenched and had replaced BAUDOT as the lingo of the teletype. Still all upper case, at least the Shift-Up/Down characters had been relegated to the dusty bin of abandoned technologies.
Model 33 TTY
Operating at a blinding 10 characters per second, this mechanical beast was no doubt the cause of many ulcers and crimes of frustration. The teletype needed 8 seconds to print one line of output. Think about it - 8 seconds per line.
The 10 character/second rate became a de facto standard. 110 baud came from the one start, 8 data, and 2 stop bits transmitted 10 times a second by these machines - 110 bit periods each second.
Desperate for better speeds someone found that the ASR-33 generally behaved well with only 1.5 bit periods for the stop bit. As UARTs got smarter quite a few supported 1, 1.5, and 2 stop bit generation.
Today we live in an age of no moving parts. It's hard to imagine the complexity of one of these machines. A bewildering array of levers moved faster than the eye could see. Yet the machines were amazingly reliable. When problems did occur a few taps in the right place with a hammer usually got the machine going again. I wonder if there's a landfill piled deep with this detritus of progress, the old teletypes, 545 scopes and 300 baud modems.
The ASR-33 included a paper tape punch and reader. Even into the early 70s tape was a standard storage media. All microprocessor programs, both binary and source, were stored on paper tape. Even in the minicomputer age DEC and Data General distributed most of their code on fan-fold tape. You sent in your money for a Fortran compiler and received a two inch stack of tape. This was long before code bloat changed the computer world.
The micro world followed many of the models of minis at first. The first microcomputer systems looked a lot like a mini, with the same front panel switches and LEDs, and of course the teletype interface.
It's interesting to see how technologies converge at critical moments in history. The microprocessor would have flopped without DRAMs, invented just a few years before. The UART similarly came along just at the right time. Intel's 1972 Intellec 8008 development system used a General Instruments UART to talk to the teletype.
Had the UART never been invented then probably we'd use "bit banging" software to do the serial to parallel (and reverse) conversions. Though not difficult, this requires a deep understanding of the timing of each instruction used to insure the code reads the serial input stream at exactly the right point in a bit field. Despite the availability of cheap UARTs, even today some firmware does indeed use bit banging.
As a college kid I was tapped to work on an 8008 project. This embedded instrument was coded in assembly language. Our development environment consisted of an Intellec microcomputer from Intel (an 8008 machine with - fully loaded - a breathtaking 16k of RAM), an ASR-33 Teletype, and software tools.
Intel did quite a good job supplying the nascent micro community with software tools. We'd start work with their rudimentary editor, supplied on paper tape, entering and modifying the assembly source code. With no disk storage we'd finish editing and punch out a tape of the program's source.
Then we'd load the assembler - also on tape, also loaded over the ASR-33's painfully slow 10 cps reader. Today tools work so transparently that we forget assemblers and compilers read the source file at least two or three times, to resolve forward references and handle macro expansions. Intel's old 8008 assembler was a three pass product, so we loaded the assembly source file - uh, tape - three times. On the third pass it punched out a binary image of the assembled module. An aftermarket of very clever but ultimately restricted one-pass assemblers all offered much faster assembly speeds. These products, too, are now in the landfill of abandoned technology.
After assembling all of the modules, with a binary tape for each module, we'd load the two-pass linker, itself yet another inch high stack of tape, and then run all of the binary tapes through twice. The result was a single absolute image, on tape, we'd load into the debugger.
Needless to day, the ASR-33's speed made this an awfully tedious and slow process. A 4k program took 3 days to assemble and link. As young sorts with too much ego and not enough software design experience, our bug rates were high enough to make any thought of reassembling after finding each bug absurd.
Like most developers of the time, we'd patch the code in the debugger. This meant entering in new hex codes to fix incorrect instructions. To add more code we'd patch in a jump to an unused area of RAM, hand assemble mnemonics, and jump back.
As we patched and patched, the code diverged from the master source tapes. We'd punch binary images each night to make a record of the changes, but the ASR-33 was so slow that reassembling from clean source files was a luxury rarely indulged.
With time fast paper tape readers became available to the micro world. That 10 cps ASR-33 speed shot up to 300 characters per second on a high speed optical reader, greatly reducing development time. Spending a small amount of money on capital equipment yielded vast improvements in efficiency, a lesson still not learned today. Tape gave way to cassettes, and finally floppies became the technology de jour. High level languages have made patching object code a thing of the past, except in extreme circumstances. Embedded tools are still far from perfect, but have shrunk the edit/compile/download cycle to something much closer to the ideal (zero time) than ever before.
Yet the legacy of the Teletype still exists. Every RS-232 connection uses a data stream no different, except in levels, than that pioneered by the teletype. UARTs, electronic equivalents of the old pseudo-distributor, are a standard feature on embedded processors. You could connect an ASR-33 to your PC or embedded system even now, using nothing more than a couple of transistors to shift the RS-232 voltage levels to current loop. Many UARTs, including the 16550 used in PCs, still support 1.5 stop bits, a bit of old teletype history we're still carrying along.
The more things change, the more they stay the same.