RS232 flow control

------------------

Social media:

Special thanks to these supporters for making this video possible:

[phirenz]

About the dropped echo characters:
The datasheet has a note saying "The Command and Control Registers should be set up first before transmission begins when writing
the TDR/TSR."

I suspect what this actually means is that it's invalid to write to the command register while data is transmitting. You are sending the echo char and then immediately writing to the control register.

Swapping the order (modifying CTS, then reading from the buffer and echoing) might be enough to fix the bug... But you probably need to poll the status register and wait for TDR to be empty before any writes to control or command.

[andrewalcock]

Ben, I noticed the get character routine will write to CTS for _every_ character read from the buffer except when the buffer is mostly full. My hunch is that the UART might not totally like being continually told that it's CTS when it already is CTS. Edit: So you could keep the state in memory and only write it when it changes

My first computer was the ZX81 and I envied my friends who had 6502 computers. Your series has brought back so many memories! Thank you so much for your work 13:33

[mikefochtman]

Great demonstration of flow control. It's interesting (at least to some of us nerds) that the original naming of signals was waaayyy back when RS232 was between 'Data Terminal Equipment' and 'Data Communication Equipment'. That is to say, between a data terminal and a data modem. So names like 'clear to send' was the modem telling the terminal it could send data, and 'request to send' was the terminal 'asking' the modem if it could send data. It also helps understand which signals were controlled from the DTE and which from the DCE.

[johnadriaan]

This brings back memories. I used RS-232 (and its derivatives) to talk over HF/VHF/UHF radios for years. You'd have a speaker set to the frequency, and watch the RS-232 handshake lines while listening to the tones. Note that the communication path was half-duplex - you could either transmit OR receive, not both at the same time. If you "push to talk"ed, then you weren't going to hear what the other side said! The handshake lines defined the various phases of the communication:
DSR: (Data Set Ready - Input) Modem is turned on. Without this, there's no point in even starting to communicate.
DTR: (Data Terminal Ready - Output) Computer is turned on. This might literally send power to various parts of the modem and/or transmitter in preparation.
RTS: (Request to Send - Output) Tell the modem to first "key" the radio (press to talk), then send the carrier - a preamble and start tones - to signal the far side that it was about to get a transmission.
DCD: (Data Carrier Detect - Input) The modem has detected a carrier, so prepare to receive a message - oh, and DON'T start a transmission of your own (raise RTS)!
CTS: (Clear to Send - Input) The modem sends this in response to RTS, to state that the preamble has been sent and the transmission can begin.
For those that remember dial-up modems, you know the "melody" that is played up front, before the raw static-noise data transfer starts? Well, that melody is the preamble. The modem would respond to RTS by playing the melody down the wire, and when finished would respond with CTS to signal that data transmission could start. Meanwhile, the other end would be doing the same thing - and also raising DCD to signal that the other end has initiated transmission. Given that the modems could speak full-duplex, that meant that the two modems could talk at the same time - but the RTS/DCD/CTS sequence would still be followed. As modems got better, they'd just raise CTS immediately, and internally buffer the data until communications had been established.
Finally, the last signal (other than TX and RX for transmit and receive data, and GND for Ground) is RI. This is Ring Indicate, a phone-line signal (not radio!) which pulses to say that the phone is ringing. You'd raise DTR to answer. Cool fact: you know that the original phones had a hammer that struck a bell repeatedly to make the "ring" sound? RI would pulse for each hammer-strike, not just raise to say "phone's ringing!"

[devnol]

What a lovely break from 400 gigabytes of NPM packages and desktop apps that use 200 megs of ram. Truly an elegant computer from a more civilized age.

[zelllers]

Thank you for explaining this. I've configured a lot of network switches which have RS232 interfaces, and I've always wondered why pasting in a large config file all at once caused issues with it being able to read it. It's common wisdom to just paste small sections at a time lol, but I never knew why this happened

[tylermasters]

Wake up! New Ben Eater video just dropped!

[jihadfee]

Ben, This is what is happening with the RTS when you put 00 TIC it disables the Transmit look at the Rockwell data sheet, This is not a BUG but how the RTS and CTS were designed. To get this to work it is better to use the DTR pin as it acts like a IO pin and the DSR as an Interrupt pin, but you still use RTS/CTS from the computer. FYI I will tell WDC to correct there Data Sheet

[cbmeeks]

This bug was discovered by a 6502 forum member and very well documented and discussed. 🙂

[canadianavenger]

Love this series, brings back so many memories. Had some thoughts/observations. You're odd behaviour with the hardware flow control may be because you left the CTS input on the UART floating, and it's picking up it's state from the adjacent RTS pin. Since your transmit code is not flow-control aware it just trashes what's already in the transmit register waiting to be sent. Try pulling this pin low to see if that fixes the problem. (or better yet, route the CTS as well) Another potential issue I noticed is with your "fix" for the flow control problem, you are doing a blind write instead of a read-modify-write to PORTA. So if PORTA had pins being used for other purposes as outputs, you would be trashing those states by setting them to 0 when you update your RTS/RFR pin.

[skilz]

He's back! September has been a month full of surprises. A few days ago, a game in my Steam library that I've been playing for about the past 4 years officially came out with their 1.0 release. The game is no longer in Early Access, and that is completely Satisfactory!!! And now, a new Ben Eater video! On top of that my birthday is less than a week away. So, it's been a relatively very good month!

[iamdarkyoshi]

I really like your teaching approach of "This is why this technique WON'T work, here's how'd we make it work instead"

I personally learn so much more this way, as opposed to just seeing it work the first time

[Dreamshadow]

You make this look effortless and I understood it. Thank you for being an awesome communicator!

[HarrySinanian]

Ben, Im older than the PCs with BASIC in ROM BIOS... Here I was with my Nortons Guide to the IBM PC, trying to work out what your making sound easy...

And in my 30 years of Systems integration, there's one thing I value most. When someone can articulate the most complicated ideas so simply, it makes sense to everyone. We can all read the text, those that can relay it on in simple terms, are the ones that understand and master it. Bravo, Ive been watching for years now, always as good as the last ep.

[SuburbanDon]

Nice to see something done that I did 40 years ago. Ben rocks.

[modelrogers.]

My heart. I really said "omg, omg another ben eater video." Thanks, ben.

[f.eugenedunnamiii]

It's been decades, but the whole "wtf does RTS even mean?" thing contributed significantly to me choosing to be a software guy instead of a hardware guy. And then your UART problem brought back my serial communication PTSD.

[Rvator]

So glad to see a video drop Ben!! Always a treat!

[azpcox]

Still no ZIF docket for that poor eprom. That is a spectacularly heavy duty package! :

Love the explanations and concepts we all take for granted these days.

[John-tezd]

Great video Ben, enjoy watching retro programming videos