I have read that the early terminals were Teletypes, for example:
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?
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.
0x7f
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.
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.
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 !
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!
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...
PROM\MO\INT A.TELETYPE.