On Fri, Mar 6, 2026 at 11:51 AM Stephen Adolph <[email protected]> wrote:
For my part, I make tools that do things like this using Freebasic on > Windows to get a program I can run on my desktop to generate the final > product. > Seems like there is a Linux way and a Windows way. I wonder if the right > tool to use is the M100 itself, for commonality. > That might be the best way forward in the long run. After all, the johnny-come-latelies — Linux and Windows — happen to work right now, but they are moving targets. The Model T will be the same forty years from now. Brian’s co2ba.sh is svelte and would probably make a better starting point for porting to M100 BASIC than my co2do. On Fri, Mar 6, 2026 at 1:34 PM Brian White <[email protected]> wrote: Transfer time was limited by the default per-byte artificially added delay > in dl -b, which has gotten larger every time I encounter some combination > of a file and a receiving machine that fails. > That’s interesting! I very much would like to know where the failures are coming from. My guess is that some BASIC programs take longer for the Model T tokenizer to process — for example, leaving out the double quote in DATA strings — but that shouldn’t be a problem. If flow control is working as it should be, then the Model T will request the host to pause (with ^S) and no delays are needed. I regularly toss BASIC files to my T200 at 19,200 with no issues, even though its BASIC tokenizer operates at slightly over 9,600. What happens if, instead of sending the bootstrap file using dl -b, you just copy it directly to the serial port? It should arrive fine, as long as the file ends with a ^Z. I think something like this would work in Windows: C:\> MODE COM1 BAUD=19200 XON=ON C:\> COPY FILE.DO COM1 In UNIX, this works for me: $ stty -F /dev/ttyUSB0 19200 ixon$ cp file.do /dev/ttyUSB0 When you have a combination of a file and a receiving machine that fails, do you also try switching out the USB serial adapter? Or, are you purposefully testing with a lousy adapter so you can be sure that dl will work for everyone? Poor quality USB serial adapters use UART chips with large buffers (FIFOs) but lacking on-chip XON/XOFF flow control. By the time the ^S (XOFF) signal is received by the host computer, it is too late as the UART’s FIFO is already filled with bytes that will overrun the Model T. That could cause exactly the problem you’re seeing. I do not think that REX could be the cause as it only slows down the Model T by 10% when you have an option ROM selected. (70% without an option ROM, but then your transfers probably wouldn’t be working at all.) —b9
