Now I understand what you are going after. Thanks. I'll give that a shot and see what happens.
On Sat, Jan 6, 2018 at 5:54 AM, John R. Hogerhuis <[email protected]> wrote: > > 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. -- Ron Lauzon - rlauzon at acm dot org Homepage: http://webpages.charter.net/rlauzon/ Weblog: http://ronsapartment.blogspot.com/ TRS-80 Pocket Computer 2 - TRS-80 Pocket Computer 4 - TRS-80 Model 100/102 Some people like to work on old cars. But old computers are cheaper and don't require a big garage.
