15 Jul
2026
15 Jul
'26
8:16 a.m.
On 2026Jul 15,, at 8:26 AM, Jon Elson via cctalk <cctalk(a)classiccmp.org> wrote:
I am trying to get my old VMS system going for demo at VCFMW.
I got a USB-serial adapter, and it mostly works OK. I am using minicom, and trying to
get the Emulex firmware resident diagnostics loaded on the uVAX. This requires entering a
BUNCH of ODT commands. I tried to put these in a file, and then do an ASCII send file
command in minicom, but it gets garbled. I assumed that minicom was sending too fast, so
put in a bunch of delays on each character and on linefeed. I did this in the T
(terminal) menu. I can clearly see these delays work when typing on the keyboard, but
they DON'T seem to work when sending the file, as the file send doesn't take any
longer to complete. Is there another place to set delays that is effective for ASCII
send?
Also, minicom doesn't seem to save these terminal (T) settings when restarted.
Should I be using a different program?
This sounds like the inherent problem with USB-serial adapters.
The terminal program (minicom in your case) may well be adding the per-character delay,
but somewhere in the host-to-USB stream the characters are accumulated in a buffer/packet,
when the USB adapter finally gets them it sends them out to its serial port all at the
regular bps rate, sans the inter-character delay.
Or at least, I have had such a flow control problem in trying to emulate a paper-tape
reader (for downloading BASIC programs to an HP2116). Adding delays, adding TC_FLUSHES to
the terminal program, etc., were of no effect. In that situation, I was eventually able
to resolve it by adding some code to (my) terminal program to wait for the LF returned by
the receiving software (BASIC interpreter on the 2116) after sending the EOL CR, that is,
using the LF as an ACK.
If it might work for your situation, or if you want a hackable terminal program:
http://madrona.ca/e/scomm/index.html