You're doing a great service for the EE community. I'm a retired computer engineer and used to get paid good money to debug serial I/O. They just don't teach 1980s technology in today's engineering programs, but there are still plenty of devices in various industries that speak only RS-232/RS-422. I would advise anyone interested in this stuff to look for used books on Serial Communications using PCs or Microprocessors. There were a couple of good ones published in the 1980s and early 1990s. If you have EE training or experience working at the breadboard level, the data sheets for these older chips also provide excellent guidance for working. with these chips with descriptions, example schematics, and driver primitives written in pseudo code. Have fun!

Waiting for more Z80 Playgrounds. No pressure ;)

Thanks, I was searching for material to do the exact same thing. this video helped me.

It's worth having a read of the Wikipedia article on RTS/CTS which you can find here: en.wikipedia.org/wiki/RS-232#RTS,_CTS,_and_RTR RTS/CTS was originally Request To Send / Clear To Send and was used in old half duplex modems where the terminal was normally listening to data coming from the modem and had to ask if it wanted to send data to the modem and then had to wait for the modem to say it could send. (Think of how a walkie talkie works, you normally listen and have to push a button if you want to talk). In modern circuits (which are full duplex) a new signal has been defined called RTR (Ready to Receive) which is assigned the same pin as the old RTS signal. It indicates that the receiver is ready to receive and is connected to the Clear to Send signal of the sender and the circuit then works as you'd expect - unfortunately many devices still call the RTR signal RTS even though it has a different purpose!

Hi John, good find! You're making good progress. Stay safe, regards Albert

Nice catch :-)

very cool

THANKS!! I had the same problem, you are my savior

There is third, quick and dirty solution for paste issue when flow control is not available - delay between sent characters. Some terminal programs have such option. That allow to paste without extra wirings and/or settings, but sacrifices transfer time.

The UART should be raising an interrupt when it's buffer has some data in it. That way you'd read it in time. Using RTS means the UART is saying hold on my CPU is having a tea break.

Did I see the magic words 'Jupiter Ace'?

I have the Z80 Playground v1.2 and I can't seem to get flow control working. I set the `FLOW` option to `01` and have enabled RTS/CTS flow control on my PC, but "the paste test" still fails. I suspect it's an issue on my end, but I don't have any idea. I am on Linux; I have been using minicom, which has an option for hardware flow control. I also tried using screen and was able to confirm with that (as well with stty) that RTS/CTS flow control is enabled. Any ideas?

Can we connect uart cable to my Qualcomm snapdragon( soc sdm636) motherboard to debug kernel log , how to find the rx tx gnd on the motherboard or is there any alternative way to connect through USB port with an FTDI adaptor ??

The speed limit is really in the connection speed. Then the two systems involved are like cars. One is so slow it can't even reach the speed limit except for bursts when going downhill. The other car is so fast it ca easily hit the speed limit. You can try lowering the speed limit and see if the slow car can keep up. But obviously flow control is the better solution.

English without flow control feels like Dutch, just noticed ;)

3:12 You have some liquid nitrogen setup for your 7 GHz PC? lol

Did you record in a cathedral?