I'd do prep and all the heavy lifting with a PC that has a real serial terminal, get it working correctly, and then tackle the USB2Serial issues. Not all adapters work correctly and they are a headache to rely on. b
On Wed, Jul 15, 2026 at 12:23 PM Brent Hilpert via cctalk < [email protected]> wrote: > On 2026Jul 15,, at 8:26 AM, Jon Elson via cctalk <[email protected]> > 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 > >
