A History of the TTY
computer.rip
computer.rip
For years (decades!) I never understood the purpose of line editors and why VI was such an improvement. Until one day I saw the pic of Gates and Allen and suddenly realized why, and how it worked. You already had a printout of your code (or text) in front of you. If you wanted to edit the text, you used a line editor to rewrite the line it was on. After a while you could print the whole thing again if you needed.
And this is why my TRS-80's BASIC editor worked the same way. It was just like the original time-share version from Dartmouth ported to a microcomputer.
1. https://www.charterworld.com/news/wp-content/uploads/2018/10...
2. http://www.columbia.edu/cu/computinghistory/teletype/ken-and...
> The first time I saw how passionate Paul could get about something, I was in 8th grade. This picture might make you think he was my teacher, but he was actually a sophomore, just a little less than three years older than me.
> This teletype is the thing that brought us together. Our school, Lakeside, held a rummage sale and used the proceeds to buy a teletype terminal. We were obsessed with it. The problem was, it was really expensive to use – 40 dollars an hour! The only way for us to get computer time was by exploiting a bug in the system.
1. https://www.gatesnotes.com/Forbes-Philanthropy-Summit-honors...
That's probably also part of why when you used line numbers in early BASIC, you left plenty of numerical gaps, so you didn't have to re-print as often.
I imagine that the code editing experience for blind people might be somewhat comparable to using line-editors? Although especially with hard copy terminals you don't need to keep everything in your head
Line editors prevailed for a long time, not because of user preferences but because they were tiny and was shipped by default. In PC-DOS/MS-DOS edlin.com/exe was what was available until the full screen editor edit.exe shipped some years into the 90s. Almost all home computers came with a variant of BASIC in ROM, which also used line editing (not even with a proper editor but by substitution of whole lines).
It's pretty easy to get used to line editors, you get used to using the search command to position the cursor on the correct line and change command to modify it. Some friendly line editors include DEC's EDI and EDT (PDP-11) and E (Motorola Exorciser).
UNIX ed is nice in that it has has regex support, but I don't like its side effects- that p, l and i change the cursor line.
I had no use for edlin since screen editors were available on the IBM PC.
I tried but never got used to TECO: this is like a screen editor, but no screen: meaning the cursor could be anywhere in the file, including in the middle of a line and it's up to you remember where it is. Some TECOs had a screen mode where it would show you the buffer and cursor position in one window, but accepted normal TECO commands in a separate command window ("TVI" on TOPS-20 worked like this, EMACS was a TECO extension).
Here's an archive link instead: https://web.archive.org/web/20240226112837/http://www.columb...
This thought leads me to ponder whether there are ongoing projects aimed at evolving this user interface into something more dynamic and interactive with LLMs. Specifically, I'm curious about initiatives that not only automatically better visualize results beyond Markdown but also "generates" innovative UI components and layouts. These would ideally support richer user interactions, such as touch, clicks, scrolling, and zooming for the input requests. Enhancing the interface in such a manner could revolutionize the way we interact with AI, making it more intuitive and engaging.
Anyone know what terminals were used in Colossus: The Forbin Project?
You know. For verisimilitude.
That movie is worth watching today. It's the Singularity, happening.
Messages like "I'm sorry, Dave. I can't recall the ICBMs. Maybe you would like to play today's Wordle?"
Curious Marc tweeting from a Teletype ASR-33
TAKE INTO CUSTODY IMMEDIATELY ALL JAPANESE CLASSIFIED AS DANGEROUS HOOVER <=
ARREST ALL GERMAN NATIONALS KNOWN TO BE SUBERSIVE HOOVER <=
The movie was made with the full approval of J. Edgar Hoover.(I used to restore old Teletype machines and had a working telegraph office at about ten steampunk conventions.)
Nicholas Freeling did the same with CERN/DESY type places and the CAMAC crate in his book "Gadget" -he asked people what you call the kind(s) of tech they used, and they gave him something to use. Could have been "Unibus" and "pdp11"
Linus Akesson has written that article here: http://www.linusakesson.net/programming/tty/index.php
https://en.wikipedia.org/wiki/Teletype_Model_33
I was recently thinking of playing with a VT102/220 emulator on a Raspberry Pi as an external 120 col display for a BBC micro. Cheap to do today, but not exactly retro-computing since it would have been prohibitive back in the day.
Punched cards were used in computing centers for preparing batch mainframe jobs for submission.
Punched tape was more a hobbyist thing, as form of program storage and sharing, used in the era of early machines such as the Altair 8800.
You can still buy a copy of Microsoft BASIC on punched tape if you need it!
I thought the use of paper tape was directly related to the teletypes (when used for I/O with a computer). Where the paper tape could operate as both an input and output mechanism, depending on if you wanted to input a program/text or save a program/text. Paper tape wasn’t a computer storage medium, as much as it was a teletype medium.
In this way, the paper tape hijacked the interactive I/O mode on these early computers to supplant it with a stored format.
So, was switching from keyboard to tape input, or from printer to tape output, done locally at the teletype, or could that be controlled by the computer it was attached to ?
I guess this implies the paper tape format was basically just a dump/listing of sorts that might otherwise have been directed to the printer, and when used as an input this would then be read into a program (e.g. editor) that was really expecting keyboard (tty) input ?
Of course there are plenty of exceptions. I mostly left out punched cards because they have a completely different pre-computer history that could take its own article. One of the reasons people perceive punched cards as far more common than paper tape is because IBM used them heavily (although early IBM machines still tended to use paper tape for loading software). IBM used them heavily because IBM had already been manufacturing punched card equipment for pre-computer data processing. But that's also why early IBM computers supported punched card I/O: for interoperation with their data processing systems. For example, early IBM computers from the '50s even to relatively modern machines in the '70s were often used alongside older punched card data processing equipment. You might categorize records using a punched-card sorter and then feed the sorter bins into a computer for computing statistics, then take the cards output by the computer and put them into a punched card sorter again to order by the computed statistics. This is how might you produce a report of counties with the highest sales, for example. A hybrid of computer and pre-computer methods of processing data. But this emphasizes the difference between paper tape and punched cards: paper tape was continuous, good for variable-length material. Punched cards were discrete, good for fixed-size records that would be binned and sorted during processing.
Later the adoption of IBM punched cards for compiler input radically changed this situation, but that still came out of the sense that input to the compiler consisted of well-defined, discrete records identified by serial number.
You can imagine the practicalities. Machine-language software would not fit neatly onto punched card boundaries, the length of punched cards being historic and not well-correlated with the word size on machines. So there's a weird alignment problem you get that paper tape avoids. Plus you can't accidentally reorder paper tape, an advantage that paper tape equipment manufacturers actively advertised!
A major example relevant to the article is Digital - DEC PDP machines used paper tape for program loading and were rarely equipped for punched cards. This reflects their different heritage and market from IBM machines; Digital machines were less common (and not really designed for) batch record processing applications. Punched cards, on the other hand, are almost intrinsically a batched record format.
Some minicomputers continued to use paper tape for initial program loading well into the '70s though, including the PDPs used for Unix development. A number of these computers couldn't "boot" from the tape drives because they were I/O peripherals, while the console and its attendant paper tape punch/reader interacted directly with memory. This arrangement was sometimes called an "autoloader," where you could set a switch and a starting address and everything coming from the console keyboard/reader were put directly into memory sequentially. I have also seen videos of PDP users hand-toggling a program to read from a tape drive into memory; I think that's mostly a flourish for modern demonstrations and contemporary operators would have used the tape reader, but it's not a long enough program to be infeasible.
https://www.youtube.com/playlist?list=PLB3mwSROoJ4JoPgcLzZ3k...
I'll also add "The TTY De-Mystified"[0] as another good article, with some diagrams as well.