Thanks all! Being able to poll the status of CTS in BASIC was the missing link. I've been doing a similar mini BASIC "printer driver" that would just do garbage loops to delay enough to usually print. I'm going to read the ports as described above and see if I can get things humming on the M100. Will report back.
Re the 200 flow control, I can at least say pretty definitively that respects external CTS signals even in BASIC or telcom. I've tried it on a couple different RS-232C printers and both promptly overflow from a 100 or 102, but keep pace on the 200. Which is great news, I wish it were so easy on the 100. My use case is printing out basic code from EDIT by just saving to the COM port. Super cool that I have a cable that'll at least let me do it on the 200. Here's my cable (male db25 on both sides, left is computer, right is printer). 1 ----- 1 2 ----- 3 5 --|_ 20 6 --| 7 ----- 7 https://www.thingiverse.com/thing:4610032 - also fwiw, had great luck with this easy and quick-to-print db25 shroud (which from the photos was designed by someone with a model t). Standard m3 hardware, everything fit first time. On Sun, Jun 11, 2023 at 1:09 AM John R. Hogerhuis <jho...@pobox.com> wrote: > To print to a printer that relies on hardware flow control on a m100 you > need to write a program to print the file. Can be in BASIC or ML. > > In a loop you read the file to print and send the data a byte at a time, > before sending each character use I/O command to check you're not flowed > off. You just loop waiting until you're allowed to send again. > > That can work if you have the full formatted file to print in an external > or memory file. Or if you can modify the program that does the printing. > > I had no idea the T200 enforced hardware flow control in the uart, that's > interesting news. > > > -- John. >
