So, recently I've been researching old tech because I want to write some fiction about some typewriter that can access the command line(yep) that shows up in many youtube videos like This one. I want full accuracy for some reason. However, I can't seem to find a tutorial on how to setup one, and I would like to know. Suppose that I have a Teletype ASR 33. How would I setup it with some operating system's terminal, given that I have the materials in this youtube video?(Hayes Smart modem, something that's able to connect to the internet through telephone e.g.. Livermore Model B, a rotary telephone, etc.)
The presumption in this situation is that there is some computer out there that already has one or several modems connected to phone lines, set up to automatically answer incoming calls and establish terminal sessions on them. I'm not going to go into detail on how this is done.
Once that's in place, connecting using an Model 33 ASR is similar to connecting with any other terminal. You do need to ensure that your Model 33 has the EIA interface (we call it RS-232 nowadays) rather than the 20mA current loop interface that was the norm before EIA became so common. If it has the EIA interface then it will probably work with almost any RS-232 equipped modem (or the terminal can be attached directly to a computer if it's not too far away for the cable to reach). I say "probably" because a Teletype Model 33 ASR ran at a fixed speed of 110 bps (bits per second) and sometimes you will find equipment with a minimum speed of 150 bps. But as long as the device you're connecting the Teletype to supports 110 baud, you should be fine.
Sidebar: At low bit rates the terms "bps" and "baud" are interchangeable. At higher bit rates they technically mean different things but people will often misuse "baud" when they meant "bps". "bps" is bits per second, which is the aggregate number of bits transmitted per second. "baud" is the number of signals transmitted per second. At low bit rates, each symbol represents 1 bit, so the number of symbols per second is the same as the number of bits per second. At higher bit rates, a symbol might represent 2, or 3, or even more bits, so you might have for example a 2400 baud modem transmitting 4 bits per symbol yielding 9600 bps. Connections between a terminal and modem are almost universally done using 1 bit per symbol, but high speed modems will almost always use multiple bits per symbol when communicating with another modem.
Anyway, back to your Teletype. Connect your Teletype and your modem using an EIA cable (aka an RS-232 cable), then connect your modem to the phone line using whatever plug is appropriate for the decade (the commonly seen RJ jacks we have today weren't the norm when Teletypes were in common use). If your modem has switches to establish the EIA baud rate with the terminal those will need to be set. Terminals often also had switches to set the baud rate, but a Teletype Model 33 only runs at one speed -- 110 baud.
Some modems have the ability to dial the phone, but if yours doesn't you should also hook up a telephone to use for dialing. A Hayes Smartmodem can automatically dial the phone so once everything is connected you can type dialing commands to the modem on the Teletype keyboard (e.g. ATDP5551212). If you have touch-tone service (this was an extra-cost option in those days) you can use "ATDT" instead of "ATDP". Once the modem establishes a connection anything you type will be forwarded down the line rather than being interpreted as a command to the modem. To return to 'modem command mode' you type three plus signs in a row (+++). You would need to do this if you want to instruct the modem to hang up the phone (ATH). The Hayes "AT" command set (and the use of +++ to get back to command mode) were a standard adopted by almost every other modem manufacturer so you will see them a lot.
As other answers will point out, you simply need to ensure that you have a teletypewriter that can talk ASCII and a way to make it communicate over a modern serial link such as RS-232 (possibly via an adapter as used in the video), and the rest is exactly the same as you'd do if you were using a terminal program on your Mac. (And probably a USB serial interface cable/dongle, given that modern Macs no longer have built-in ASCII serial interfaces.)
But you also mention that you want "full accuracy," which I think you may need to think about and expand upon. If you're just after "it looks like what a movie-goer would imagine old things to be like," as with the blinkenlights and [old tape drive cabinets] that appear in the movies wherever someone has a "mainframe," you'll be fine. But the technologies you're talking about putting together are rather anachronistic, so "accurate" to history it will not be.
The Teletype Model 33 was far from the the first printing terminal used as a computer console; it wasn't introduced until 1963. By that time the Fridan Flexowriter and similar devices had been used as computer consoles for as long as computers had had printing consoles. What made the ASR-33 popular over the next few years was a combination of low cost and that it used the brand new "ASCII" encoding rather than the BAUDOT code that had been standard up to that time. (Non-IBM computers happened to be switching from various proprietary codes to ASCII around the same time.)
Nor was it a "modern" printing terminal when it was introduced. By that time the uppercase-only "chugga-chugga" printing thing had one foot in the grave. The IBM 1052 was introduced in the same year and with its Selectric typewriter mechanism it offered both upper and lower case and was faster and quieter. By the end of the decade, even before VDTs became affordable, there was hardly reason to manufacture something like the ASR-33 any more; Selectric, daisy-wheel and dot-matrix mechanisms had taken over the market. This was, however, advantageous to microcomputer hobbyists in the 1970s who had limited budgets, since ASR-33s were now very cheap on the used market.
It was only as the teletypewriter terminals were having their final
hurrah that the "command line" (i.e. timesharing) started to appear.
Shortly after the ASR-33 was introduced the first commercially
successful timesharing system, the Dartmouth Time-Sharing
System was developed, and over the next decade it and similar
systems started to become popular.
But there were never any
"terminal rooms" full of ASR-33s, as far as I'm aware; there just
wasn't enough overlap in time there. (And who would be able to stand
the noise, anyway?)
There were cases of terminal rooms being filled with ASR-33s, as another-dave mentions, but I don't think this was terribly common; the incredible noise produced by this certainly would have not made for a comfortable interactive development environment. I know I would probably have preferred to do most of my programming off-line to minimize the time I would have to spend on a terminal in such a situation. And more off-line work than on- was common until the microcomputer era, since the demand for terminals was almost invariably higher than availability. It was not unusual to have a limited supply of "soft dollars" to pay for computer resources, including interactive time as well as CPU and disk. Programming off-line and limiting on-line time to debugging was of course quite different from how we do things today.
Then you bring in the WWW and HTTP. The main difference between that and the many previously existing hypertext systems was that the WWW was explicitly designed not to be used from a command-line interface, but with a graphical one. Even though it was made available to the public only shortly after the text-based Gopher protocol started becoming popular on the Internet, because Gopher was better for use with a command line interface it remained more popular than WWW/HTTP for several years. And FTP, which was also designed for command-line use, remained the most popular protocol for file transfer for even longer.
So in short, this particular experiment or demonstration you're doing is an utterly inauthentic combination of technologies. There's nothing wrong with that if authenticity is not what you're trying to achieve, but if it is what you're trying to achieve, you probably need to think further about just what you're trying to be authentic to, and then do some research to find out what the contemporary technologies, protocols and the like were.