35

I have read that the early terminals were Teletypes, for example:

Teletype

So you send your input to the (large) computer, and then you receive the result which gets printed on paper I suppose.

But could you actually see what you were typing? Does a Teletype have a small screen or something that allows you to see what you are typing?

psmears
  • 173
  • 4
user7681202
  • 1,837
  • 12
  • 17
  • 1
    That's exactly like the teletype my school had before they threw it out in favour of an RM 380Z. My memory might be wrong, but I think the TTY in my school had an acoustic coupler where the blanking plate on the right of the one in the photograph is. – JeremyP Apr 19 '17 at 12:09
  • 3
    @JeremyP - your memory is correct! That's what went on the right side. 110 baud! Woohoo! I remember when Harvey Mudd upgraded to ASR-43s! God were those fast! 300 baud! – davidbak Apr 19 '17 at 18:03
  • 1
    From memory, Microsoft BASIC for CP/M is particularly hard to use because it doesn't assume a virtual teletype like most software from just a year or so later. Pressing backspace adds a backslash and then a fresh copy of the letter removed. Then the next letter removed, etc, followed by an additional backslash once the list of characters you've deleted has ended. So e.g. a correction might appear as PROM\MO\INT A. – Tommy Apr 19 '17 at 18:28
  • 2
    @cbmeeks Those "holes in the front" are not holes at all, they are the letters T E L E T Y P E. –  Apr 20 '17 at 02:08
  • That's actually a fairly late model -- the ASR-33. But to my knowledge most models worked similarly. While it was possible to disconnect the keyboard from the printer, they were normally connected together, either directly or by being "echoed" through the attached computer or whatever. – Hot Licks Apr 20 '17 at 19:29
  • It's worth mentioning that for Unix specifically, it always worked in remote echo mode when the terminal was capable of not doing local echo - i.e. the kernel was responsible for echoing typed-in characters back up the serial line, which allowed it to not echo (e.g. when you are typing in a password), or transform the echoed character (echoing control-c as ^C). Can anyone think of any other OSes that an ASR-33 was normally used as the terminal for that would require local echo? – Random832 Apr 21 '17 at 13:48

6 Answers6

59

You could see what you were typing because it appeared on the paper in front of you. A teletype is just an electric typewriter at heart.

There was no screen, the picture is just as the system was.

The teletype was the console input to the computer. Once logged in, you had the standard command prompt. You entered your command which was sent to the mainframe character by character as you typed it. Then the response was presented on the paper. This was replaced by the console, or shell, display on a video monitor when such things came along later.

As shown in your picture, there was a punched tape reader / writer on the left hand side, so you could also "type" onto punched tape, or read the contents of tape into the computer or onto the roll of paper.

I spent my formative years programming on these. They were very slow to use because the keys had to be depressed a long way before contact was made and the keystroke detected. This made it impossible to touch-type at any sort of respectable speed. They were also incredibly noisy. The sound of the clattering carriages in a room full of a couple of dozen of these could be deafening.

Chenmunka
  • 8,141
  • 3
  • 39
  • 65
  • 16
    "They were very slow to use" - this is the main reason behind the oldest UNIX programs being so cryptically named - ls, rm, cp, etc. Only having to type two characters rather than four on one of these things is a significant saving! – Muzer Apr 19 '17 at 09:06
  • 2
    @Muzer: Indeed so, and also why on games like Adventure, you entered single character commands. – Chenmunka Apr 19 '17 at 09:23
  • "You entered your command which was sent to the mainframe character by character as you typed it" What if you pressed a wrong key, does a Teletype have a backspace key? – user7681202 Apr 19 '17 at 09:57
  • 1
    @user7681202: Yes, it had a BS and a DEL key. – Chenmunka Apr 19 '17 at 10:01
  • 2
    However, it's probably important to remember that since the output was printed, backspace simply moved the location of the printhead and didn't (and couldn't) actually erase the character. – Edward Apr 19 '17 at 11:43
  • 19
    That's also why you have back space and delete instead of just a single key that erases the last character typed. Back space moved the type head back one and also the paper tape. Delete sends a delete character to the computer (if connected) and punches a line of holes in the paper tape which would obliterate any existing character there. This is why ASCII DEL is 0x7f – JeremyP Apr 19 '17 at 12:03
  • 1
    The model looks like a golf-ball, so the head "jumps up" to print each character, leaving what you've typed fairly clear. Some later teletypes used a daisy-wheel or a dot-matrix head, which often would obscure the last couple of characters typed. Many would move the head to the right by an inch or so a few seconds after the last character typed so you could see what had just been typed (and then moved it back when a key was pressed). – TripeHound Apr 19 '17 at 12:14
  • 2
    @JeremyP: If a character was inadvertently punched on the tape of the ASR33, it was necessary to first push a button located on the punch itself to back the tape by one position, and then type a rub-out character which would punch all the holes. Rub-out was just an ordinary character which would cause some receivers to do nothing and others to show a "deleted character" marking, but basically the idea would be that if one typed "hellp", backed up the type, hit rubout and then typed "o", the tape would end up with "hell▒o", which should hopefully be recognizable as "hello". – supercat Apr 19 '17 at 15:41
  • 1
    Note also that the paper-tape unit was optional, it wasn't present on all models. You can actually see on this photo that it looks bolted-on. – Michael Kay Apr 19 '17 at 15:46
  • "You entered your command which was sent to the mainframe character by character as you typed it" - possibly. I think in many cases there was some kind of front-end processor that collected a line of input and sent it to the mainframe only when you hit RETURN. – Michael Kay Apr 19 '17 at 15:48
  • @MichaelKay: On many machines such as the HP-2000 there would have been a terminal interface board that would only relay lines of data to the main CPU when they were complete (the user hit enter). That board would have been in the same cabinet as the rest of the computer, so if "the computer" includes everything in that cabinet the data would be processed by "the computer", albeit not by the main CPU. What's important is that the teletype would immediately send the data somewhere; it would not buffer the data on its own. – supercat Apr 19 '17 at 17:05
  • 4
    @TripeHound This is an ASR-33 or something very similar - produced by the Teletype Corporation. The type head was a cylinder. The golf ball/typeball was an IBM invention and available from IBM only. – davidbak Apr 19 '17 at 17:55
  • @MichaelKay - no front end processor! and no line buffer either! We're talking about the 1960s! Nope characters were sent over the wire as soon as they were typed. Now the computer the terminal was connected to ... that thing might have had some cabinet or another in front of it to process communications. E.g., DECSystem-10s had an integral PDP-8 for that, IBM 360s had large (large!) boxes external to the computer to handle comms (e.g., the 2700 series - a box the size of a pair of washing machines that could handle 4 - count 'em: four! - low speed lines). – davidbak Apr 19 '17 at 18:02
  • @davidbak - yes I know characters were sent from the Teletype as soon as they were typed, but I think that on the system I used (the Cambridge Titan) they only went as far as a PDP comms processor where they were buffered: the Titan machine didn't have to handle an interrupt for every keystroke on every terminal. I might be recalling that incorrectly, however. – Michael Kay Apr 19 '17 at 22:46
  • @Chenmunka I miss Adventure :( I would love to get a copy of it working in Linux, preferably the original PDP-10 version by Willie Crowther. –  Apr 20 '17 at 03:15
  • @Spellweaver See this page and in particular the 'Adventure' Downloads page. – TripeHound Apr 20 '17 at 05:53
  • @GypsySpellweaver: I have a Windows 10 and an Android version of the original Adventure. There must be one for Linux. – Chenmunka Apr 20 '17 at 07:14
  • 1
    Note that it is NOT true that the characters were immediately printed. The keyboard operated independently from the printer, and you could, in theory, be typing one thing and printing another. When the printer was not connected you just got a sort of brief buzz from the machine when you depressed a key. (Usually this meant that there was a wiring error or that the attached computer was not echoing your keystrokes for some reason.) On machines where there was a software-provided "echo" the printing came a disturbing length of time after the key press. – Hot Licks Apr 20 '17 at 19:35
23

Many Typetype-style devices (I'm not positive about the popular Teletype® brand ASR-33 itself) could be switched to use "full-duplex", "local", or "half-duplex" mode. In full-duplex mode, characters which were typed would be transmitted to a remote machine but would not be processed locally. In local mode, they would be processed locally but not transmitted. In "half-duplex" mode (so named because it was suitable for use on "half-duplex" lines that could either transmit or receive, but could not do both simultaneously), characters that were typed would be both transmitted and processed locally.

In cases where such usage would be practical, the optimal behavior is often to have characters that are typed be transmitted without being processed locally, but then have the remote system echo back characters as they are processed. This can provide the user with clean feedback as to when and how characters are being processed, but requires that characters be processed as soon as possible with minimal buffering delays. Single-user computers seem to favor such an approach since a computer that is doing nothing but awaiting input will be able to respond to it quickly. Today, Unix systems seem to use a hybrid approach where the terminal itself is not expected to echo characters locally, but the characters get echoed by the system automatically before the application layer requests them.

supercat
  • 35,993
  • 3
  • 63
  • 159
  • 7
    The knob on the front is for selecting "Line" (to the left), "Local" (to the right), and "Off" (straight up). Local was used for punching the tape, which you could then feed back to the reader in Line mode so that your "connection time" was reduced. Many remote locations paid for CPU time and Line time (kind of like minutes on the cell phone now), and if your access was over a toll line, spending time typing in a program, line by line, got very expensive. Duplex settings were part of the communications unit. In Line mode nothing was printed until it was received, or "echoed". –  Apr 20 '17 at 02:58
  • @GypsySpellweaver: When I used an ASR-33 hooked up to an Altair 680 it didn't seem like there was a 200ms lag between keystrokes and echo. Would the Altair have to have been hardware-echoing characters as they were typed (rather than receiving and retransmitting) or did the ASR-33 have a way of doing that automatically, or perhaps whatever interfaced the ASR-33 to the Altair did the echo? – supercat Apr 20 '17 at 14:31
  • Several options depending on the setup. If the communications unit was installed and set to half duplex it could do the echo. If the ARS/KRS was connected to an external modem/device, same thing. It could also be directly connected to twx which would be a fast echo. If the it has a full duplex connection and the receiving end had a comma interface unit, typical setup, then the echo is fast since it'S not delayed by the processor. –  Apr 20 '17 at 16:15
  • @GypsySpellweaver: I'm not familiar with "comma" interface; does that echo the state of the receive wire during transmission? I wouldn't expect a CPU to take very long to echo a character once it's received, but most kinds of circuitry wouldn't start processing a character until it was fully received--86ms after transmission had commenced. – supercat Apr 20 '17 at 16:20
  • @supercat - There was always (at least) a full 1-character delay between the key press and the typing action, and when there was remote echo it could get noticeably longer. In "local" mode where the echo occurred within the TTY, the connection was purely electrical, and, from the time the key was pressed, it took a tenth of a second to "read out" the key's bit pattern and "impress" that pattern into the "shift register" of the printer unit (all of this mechanical). Only then could printing begin. It was quite the mechanical marvel. – Hot Licks Apr 20 '17 at 19:45
  • @HotLicks: True there would always be one character delay. I would think that at 110 baud I would have noticed a 2-character delay, but I don't remember noticing one. Out of curiosity, could an ASR-33 operate in full duplex with someone typing outgoing data independent of the incoming data, or did it use a shared rotor for transmit and receive bit timings? I know it could shut off a remote reader by typing control-S, but that might be possible even with a shared rotor if an attempt to type control-S while a character was incoming would get deferred until the end of the incoming character. – supercat Apr 20 '17 at 19:51
  • @supercat - There was a shared shaft, turning at 10 revs/sec, but the transmit and receive assemblies were completely separate (in most machines), and so one could transmit and receive independently and simultaneously (though doing so meant that you could not see what you were typing). (The punch was driven off the printer, IIRC.) I'm recalling a few setups that oddly required that the "loopback" be accomplished within the TTY itself (and hence no full-duplex mode), but in even these case I think that it was all accomplished electrically. – Hot Licks Apr 20 '17 at 20:01
  • 1
    @HotLicks: What I find interesting is that minicomputers developed a very different I/O philosophy from microcomputers. On a lot of microcomputers, even ones with typeahead buffers, characters that would end up getting consumed by a "read line with echo" system call would not echo until the call is performed, while minicomputers like to echo characters when typed unless echo gets turned off before they're typed. Advocates of the latter design seem incredulous at the idea that it would be possible to disable echo of characters that have already been typed. – supercat Apr 20 '17 at 20:19
  • @supercat - Keep in mind that a serial terminal cannot "echo" an entire line instantaneously. If the computer buffers up 40 characters and only echos them when return is pressed, the printer (on a TTY) will be busy for 4 seconds. This is different on a "glass TTY" operating at 1000 bps or so, where the echo would be 10 times faster. – Hot Licks Apr 20 '17 at 20:29
  • @HotLicks: No, but whatever is receiving a line of input should be able to echo any buffered characters when a request is received to input a line, without having to wait for return to be pushed. – supercat Apr 20 '17 at 20:39
  • @HotLicks: If it takes a BASIC interpreter 3 seconds to process a line of input, and within the four seconds following one line of input the user types a total of ten characters and the computer has a serial input buffer, I would expect it to start echoing those characters three seconds after the previous "enter" keystroke, and after a second be caught up to what the user was typing. If the computer were to run out of memory or otherwise squawk at the input, I would expect it to type "OUT OF MEMORY"[cr/lf] followed by any characters that had been typed for the next line. – supercat Apr 20 '17 at 20:44
  • @supercat - How "read line with echo" is handled is up to the computer (and the OS specs). There is no technical reason why there can't be character-by-character echo, unless the computer-side hardware can't handle it. I can recall, on a TTY, cases where I'd type a line and return and then keep typing for several characters, as the computer responded. So long as you didn't make a fatal typo it worked fine. – Hot Licks Apr 20 '17 at 21:18
  • @supercat - But there were no doubt systems with "dumb" terminal controllers that could only be placed in either character-by-character mode (requiring a lot of computer overhead) or line-by-line mode. If the controller was not itself capable of being placed in "echo" mode, then, in line-by-line mode, the echo would have to wait until return was pressed and the input statement was processed. – Hot Licks Apr 20 '17 at 21:22
  • @supercat "Comma" was an auto-corrected typo from "comms." meaning an individual unit, outside the central processor, that could handle the communications for several lines (often as many as four) and schedule the input to the processor as needed and buffer the output before sending it back to the terminal. Sorry for the long delay, I shouldn't have tried to do the mobile app with flaky wifi. –  Apr 21 '17 at 07:15
  • @GypsySpellweaver: It was necessary on many systems to use terminal controllers that would avoid disturbing the main processor until enough input was received to do something useful. It should still have been possible and practical, however, to have the main computer issue an affirmative "I'm ready for a line of buffered/echoed input; let me know when you've got one" before each line, rather than simply having the controller expect that it should keep buffering lines with echo until further notice. – supercat Apr 21 '17 at 15:41
13

I own a DEC pdp8/e and two ASR-33 Teletypes.

The ASR-33 can operate in "Line" or "Local" mode. In Local mode, characters are printed as they are typed. This mode is used for reading and punching paper tapes.

In Line mode, typed characters are sent down the line to whatever host you're communicating with. Typing makes a "Bzzt" noise for each character as the mechanical parallel->serial converter spins but nothing is printed. It is the responsibility of the Host to echo back the characters being typed.

Crash Gordon
  • 231
  • 1
  • 2
7

Absolutely stone age stuff. We had these in 1970 when I worked at Hawker Siddeley Woodford. We had amazingly fast leased telephone lines that would handle 128 bps (not kilobits or megabits) connecting to the mainframe at Hatfield. The main point of the paper tape reader was that you could have your bulk input punched up in advance offline in the "punch room" and then read it in far faster than you could type it yourself on the teletype (normally without printing it at the same time). We shared the terminal among the programmers in the office and I got half an hour three times a week, so every second counted.

P.S. Thanks Lana for the punching, 50 years ago but not forgotten !

Tom Collinge
  • 219
  • 1
  • 3
6

You could see what you were typing, as others have said, because the print head (which was cylindrical) rose up and rotated until the right character was in place, then slammed forward to smack the (simultaneously raised) tape and make a mark on the paper, and then dropped back down. The raise-spin-slam-unspin-and-lower sequence was rather noisy -- and not just the "slam" part.

On a distantly-related note, the data-transmission mechanism for directly-connected model 33s was the "20 mA current loop" -- a loop of wire that went from A to B and back. Machine A would send pulses into this loop by raising the voltage on one end until a current of 20mA flowed, hold it there for a short time, and then release. That was a "1" bit, I believe. A similar stretch of time with no current was a "0" bit.

The cool thing about the 20mA design was that it really didn't matter how long the wire was, or how resistive (up to a point!): if 20mA is flowing HERE, then 20mA must be flowing THERE, and be enough to activate a solenoid or whatever at the remote location. For long wires and higher speeds, things look less and less like switched-DC, and more and more like high-frequency analog signals, and things like inductance and capacitance make the whole plan less workable. But it sure was a cute first draft!

John
  • 161
  • 1
  • 1
2

Yes, you could... The usual way of sending messages was to punch a paper tape first, and then run it through the tape reader, but you could also type directly, and even communicate as a 'chat', in real time and with the two texts clearly differentiated by the usual two-color tape, red and black...

xxavier
  • 21
  • 1
  • 4
    Despite having user online teletypes extensively (ASR 33, KSR 33), on several different computer systems, I never saw a teletype with two-colour tape. Flexowriter yes, Teletype no. What model was this? – dave Sep 19 '20 at 11:48