On Sat, Jan 6, 2018 at 2:03 AM Ron Lauzon <[email protected]> wrote: > I'm using the standard Telcom program. > > The big file test won't show me anything new. I see the problem
Just trying to help you characterize the whole problem before you work on the solution You’ve got two channels, transmit and receive. Are both channels lossy or just one? Talking about the response to the ATI command in TELCOM you’re talking about the receive channel. It’s limited by a 64 byte queue. Plus the overhead of displaying characters on the screen. When doing display on the M100 you actually can’t go faster than about 600 baud without dropping chars. If you fill the receive queue you’re going to drop chars. If your system is so busy that it cannot process all serial interrupts, you will drop chars. How big is the response to ATI supposed to be? If you take display out of the equation you could test the receive channel at 19200 in TEXT with a load from the file COM:98n1d (assuming there’s a way to trigger the other side to begin transmitting). Now you can be at a higher baud rate in interactive TELCOM if you enable software flow control. 98N1E. Effectively because the display is involved you’ll still be limited to 600baud but the line rate will be 19200bps. That’s all software flow control. The model 100 has no built in software support for hardware flow control. For that you need to write some machine code or play with HTERM. — John.
