The RS-232 protocol [video]
Looks like this would be RS-232F.<p>It was way back in RS-232B when the Mark and Space were reversed.<p>And the standard called for robust performance with all circuits not affected by any miswiring up to +&#x2F;- 25 VDC on any pin at any time.  Must not requie powering down before connecting&#x2F;disconnecting.<p>DCE really meant Data Communication Equipment, i.e. primarily Bell-approved acoustic telephone modems (to be operated back then no faster than 300 baud when using their monopolized land lines).<p>So a DTE was Data Terminal Equipment which means a regular &quot;dumb&quot; terminal which is just a keyboard and CRT display with an RS-232 input&#x2F;output having the D-sub (male) pinout according to the DTE pinout scheme.  A PC is a lot more powerful but with a terminal app or the correct tty i&#x2F;o your keyboard, display, and motherboard 9-pin D-sub (if available) will do it better than ever.<p>In the video, he&#x27;s connecting only the transmit pair from his terminal, not shown would be the handshake lines which are, as seen, actually &quot;optional&quot;.  Not really but with lots of hardware if the recieving DCE end were not able to signal Data Carrier Detect (DCD), Data Set Ready (DSR), and Clear to Send (CTS) on the proper handshake lines back to the DTE terminal, there was going to be no data coming out of the terminal from pin 2 for you.<p>I would expect in the software of his RS-232 adapter, that he has continuously enabled the handshake lines needed by the PC to recognize that his external device is ready to recieve.  So he therefore needs no extra conductors between the devices to accomplish that handshake purpose.<p>The DTE terminal would ideally signal power on and buffer ready on the DTR and RTS pins or the modem would speak not.<p>On the DTE the outputs are Data on pin 2 and logic on DTR and RTS.  The inputs are Data on pin 3 and logic on DSR, DCD, and CTS.<p>On the DCE the outputs are Data on pin 3 and logic on DSR, DCD, and CTS.  The inputs are Data on pin 2 and logic on DTR and RTS.<p>The default concept was supposed to be a cable with straight connections between pins 1, 2, 3, 4, 5, 6, 7, 8, and 20 of a male and female D-sub 25 connector at each end.  On the hardware, the DCE modem had the female D-sub and the DTE terminal had the male D-sub, so it was just a straight cable.  Multiple cables could be used as extension cords.  Good for hundreds of feet with careful wiring considerations.  In the abscence of handshakes only two conductors needed for one-way communication.<p>On the first PCs there were two D-sub 25 pin connectors on the back, the female was a (ribbon cable) bus parallel port for the printer, and the male was an RS-232 serial COM port for use to connect to a telephone modem.<p>When the mouse came along they were RS-232, most people did not have a modem yet (why would you want to connect to someone else&#x27;s computer anway?), so there was an available port.  Connector was downsized to 9-pin with partial pin renumbering.<p>Actually you could always connect two PC&#x27;s together and bypass the handshake settings in software if your buffers were adequate, you only needed 3 conductors; a ground with 2 &amp; 3 crossed over.  There is also the optional XON&#x2F;XOFF software handshake otherwise which is signaled within the data stream instead of needing excess conductors in the cable.  Or you put a local jumper between some handshake pins at one or both ends of the cable to force the handshake logic if you didn&#x27;t truly need the extra logic conductors between your target devices.<p>On any one connector, there should be a couple handshake pins (other than communication pins 2 and 3) where, in the abscense of intentional hardware signal changes, these pins remain at a constant positive or negative voltage.  So either voltage is available at either end of the cable for <i>local jumpering</i> in order to fake a handshake if necessary to coerce data flow in one or both directions.  Small (sometimes unique) rats nest of wiring inside of one or both ends of &quot;proprietary&quot; RS-232 cables under the hood is normal, to get by with fewer conductors since most serial devices are not modems any more and have lesser logic needs.<p>For one-way communication he&#x27;s wise to use only two conductors between devices and skip the confusing &quot;null-modem&quot; fake-handshake approach I have seen so much of.  Fortunately modern (1990!) RS-232 software allows you to enable various handshake lines at the terminal.<p>Here&#x27;s some example wiring workarounds showing that almost anything goes:<p><a href="https:&#x2F;&#x2F;www.perle.com&#x2F;support_services&#x2F;cabling&#x2F;documents&#x2F;db25_dce_cabling_examples.pdf" rel="nofollow">https:&#x2F;&#x2F;www.perle.com&#x2F;support_services&#x2F;cabling&#x2F;documents&#x2F;db2...</a><p>At slow baud rates like 300 or less if available, your data can be visualized in real-time without an ocilloscope.  With bypass of the hardware handshakes enabled in your communication software, ideally connect a bipolar LED (having an appropriate current-dropping resistor in series) between only male pins 2 &amp; 5 of the PC&#x27;s D-sub 9-pin connector.  Although an ordinary (unipolar) LED can be good too, then alternatively reversed in polarity, showing only the marks or the spaces either way.  This could just be popped into the breadboard in the video.  As you press a key when terminal i&#x2F;o is to that COM port it&#x27;s almost like Morse code on the LED.  These are the same two pins he is using to connect from his COM port to his breadboard.