Copied from the Z80 Membership Card Operation Manual
written by Lee Hart, updated Apr 11 2017 by Josh Bensadon

Appendix A is by Josh Bensadon.
Copied by Herb Johnson and updated, June 23 2018

Appendix A. USB Adaptors.

These are relatively new (compared to the Z80) and for the most part, they all use
one of four common chips. These chips are:

• FT232R by FTDI
• PL2303 by Prolific
• CH340 by ????
• CP2102 by Silabs

They all require drivers, but some install the drivers automatically. Some drivers
don’t work well with some operating systems, my experience showed CP2102 fails with
Windows XP. These adaptors can be cheaply obtained on Ebay for a couple of bucks. If
you are in a country where Chinese food is just called food, then shipping should be
quick. If you plug it in before loading the drivers and the drivers don’t automatically
install, you will need to unplug it, install the drivers and look for the USB device in your
device manager then either update the driver or just delete it and let the system find the
driver when you plug it back in. You can, from the device manager, click the properties
of the USB port and select any com port you wish.

I don’t know a lot about the USB interface and drivers but I have found out
through experimenting that the data from the terminal emulator program is sent to the
USB device in some form of packet protocol. Your knowledge, experience or drivers
may be different, so please take the following information provided with a grain of salt.

In normal typing, the keys are sent one by one to the USB and come out as TTL
serial data. But when sending a text file, strange things happen as you introduce
character and line delays. When selecting 1mSec or more character delay, the characters
all come out with about 14mSec delay. I’m guessing this is the time it takes to process 1
packet, the 1mSec delay is long enough to have the driver start the real “send” process.
When sending a hex file line of about 70 characters, line delays of less than 70mSec do
not provide any line delays. When the delay is about 100mSec, then you get a 30mSec
delay. At 9600 baud, 70 characters take about 70mSec to send. So, it’s my guess that the
terminal program sends all 70 characters to the USB within a few microseconds, and the
delay matches the time the USB chip sends out those 70 characters.

Bottom line, when sending hex or other text files, set character pacing to 0mSec
and line pacing to 150mSec. You can choose less and experiment if you need more
speed, otherwise this value worked well with all tests performed.

[Comment by Josh, added at his request, June 17 2017]

I've arrived at these conclusions by observation of only 1 USB UART chip, namely the CH340.  Operation, timing and delays of other chips (or even future revisions of the CH340 chip) will most likely vary as there are no established standards.