Re: [M100] M200 vs M100/2 RS232 Differences

[Charlie Hoey]

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  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.
>

Re: [M100] M200 vs M100/2 RS232 Differences

[Peter Noeth]

On the M100 and T102, the only automatic flow control method for the RS-232
port is XON/XOFF (software flow control).

Back in my HP pen plotter days (1985) I found that 2400 baud was fast
enough between a RS Model 4p and any HP serial pen plotter. Just have to
get your pen plotter to use XON/XOFF flow control. This should also be
available on the T200.

The complications with RS-232 cabling is because the standard was to
connect a terminal, computer or printer (Data Terminal Equipment, DTE) with
a modem (Data Communication Equipment, DCE), where the cable was connected
1 to 1 on both ends. The modem reversed the data pairs internally (RX/TX,
DTR/DSR, RTS/CTS, etc). Only a modem was defined as DCE, everything else
was DTE. So connecting DTE to DTE requires some wire juggling that never
seems the same every time. Sometimes the hardware handshaking lines
DTR/DSR, RTS/CTS, and CD can be looped back on each end or cross tied to
the other end to find the minimum connection to make it work with the least
number of wires in the cable.

Ahhh  the good old days before USB.

Regards,
Peter

>
>

Re: [M100] M200 vs M100/2 RS232 Differences

[John R. Hogerhuis]

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.

Re: [M100] M200 vs M100/2 RS232 Differences

[Brian K. White]

There is definitely no (normal) access to rts/cts from BASIC unless you 
count BASIC with included/encoded machine language.


The hardware exists in the machine. The uart has the pins and they are 
wired up to the db25, but there is no code anywhere in the main rom that 
uses them. No BASIC commands, no telcom, print, etc.


The options I know of are:

* machine language do your own uart setup
HTERM and TBACK are pretty much the only examples of code that actually 
uses rts/cts, and they are machine language.

http://bitchin100.com/wiki/index.php?title=HTERM

* I think you can read the status of cts by reading INP(187), and 
possibly set the status of rts but OUT(???) something.
But I don't know about accessing the uart register to tell IT to do 
rts/cts itself. I don't think being able to read the pin and set the 
pins helps you get to "print with rts/cts".

http://bitchin100.com/wiki/index.php?title=Diagnose_DTR/DSR_and_RTS/CTS_issues

* At power-on the Model 100 rs232 port sets all data & control pins to -5v.
On RUN "COM:98N1E", pins 4 (RTS) and 20 (DTR) go to +5v.
So, you have actually one form of control over the pin by opening and 
closing the COM port. I don't think this is useful for your printing 
problem, I just include it for completeness.


* xon/xoff is reliable enough if you keep the speed down to the limits 
dictated by the time it takes for an in-band xoff round trip, the size 
of the other sides receive buffer, and how much data is already in 
flight in that amount of time. For the 100, when receiving, with the 
screen active/updating, this is only 600 baud. Turn the screen off and 
it's maybe up to 9600. For sending only, like printing? I guess that 
number would be determined by the size of the printer's receive buffer 
and how quickly the 100 can respond to an xoff. There will be some 
absolutely reliable speed. It's not that xon/xoff just isn't reliable. 
It's just that since it's in-band, you have a maximum reliable speed 
limit dictated by the round trip time, processing time, and size of 
receive buffers. And that maximum bulletproof speed can be much lower 
than you think.


--
bkw

On 6/10/23 21:20, Charlie Hoey wrote:
It may come to that for cables, but now I'm extra confused. I'm also 
doing some experimenting with an RK-P400C pen plotter that's got an 
RS-232C port. There's this bitchin100 article 
 
that says you don't get any hardware flow control in BASIC with RS-232, 
but is that true for 'saving' out to a com port as well? For example, if 
i hook up a serial printer and hit F3 and 'save' to com:58n1dnn, is that 
going to respect flow control?


IThe manual for the plotter has the following wiring diagram:
image.png
I've created a cable following this but it seems to still be ignoring 
flow control, which on a slow plotter like this one makes it almost 
unusable. So I'm curious if anybody knows for sure if it's possible to 
transmit data over RS-232 on an M100 that respects CTS signals in BASIC. 
Or, if there is an alternative wiring I should try for the M100 
specifically so it doesn't keep overflowing print buffers.


Thanks!

On Fri, Jun 9, 2023 at 10:55 PM Gregory McGill > wrote:


Why not wire dsr from the printer to CTS

On Fri, Jun 9, 2023, 5:23 PM Charlie Hoey mailto:charlie.h...@gmail.com>> wrote:

Apologies for the longish post, didn't have time to write a
short one!

*TL;DR* I've been happily serial printing on my 100/102, but my
200 doesn't work, so I'm in search of a non-hardware solution to
tying DTS/RTS together on a 200 to let it send RS-232 data.

I've been experimenting with RS232 printing on an Apple
Imagewriter ii, and I noticed that my 100's and 102 will print
to it just fine, but my two 200's both just time out trying to
print (by print I mean, save a text file to "com:88n1enn". Same
deal when just playing around in the terminal, it gets a little
buggy and I can't even quit without powering on and off, and
identical behavior on both otherwise healthy 200's.  What gives?

I dug around the m100 list archives, and there's this thread
from 2015
http://lists.bitchin100.com/htdig.cgi/m100-bitchin100.com/2015-January/069836.html 
 that's 
very similar (also this one 
 and this 
one , 
an old problem). So I hooked my 102 and 200 up to a scope and made a little test harness to look 
around, and long story short, the 200 indeed refuses to send any RS232 data unless RTS/CTS are 
tied together. This doesn't seem to be the case for the 100 and 102, which will happily send data 

Re: [M100] M200 vs M100/2 RS232 Differences

[Gregory McGill]

Why not wire dsr from the printer to CTS

On Fri, Jun 9, 2023, 5:23 PM Charlie Hoey  wrote:

> Apologies for the longish post, didn't have time to write a short one!
>
> *TL;DR* I've been happily serial printing on my 100/102, but my 200
> doesn't work, so I'm in search of a non-hardware solution to tying DTS/RTS
> together on a 200 to let it send RS-232 data.
> 
> I've been experimenting with RS232 printing on an Apple Imagewriter ii,
> and I noticed that my 100's and 102 will print to it just fine, but my two
> 200's both just time out trying to print (by print I mean, save a text file
> to "com:88n1enn". Same deal when just playing around in the terminal, it
> gets a little buggy and I can't even quit without powering on and off, and
> identical behavior on both otherwise healthy 200's.  What gives?
>
> I dug around the m100 list archives, and there's this thread from 2015
> http://lists.bitchin100.com/htdig.cgi/m100-bitchin100.com/2015-January/069836.html
> that's very similar (also this one
> 
>  and
> this one
> ,
> an old problem). So I hooked my 102 and 200 up to a scope and made a
> little test harness to look around, and long story short, the 200 indeed
> refuses to send any RS232 data unless RTS/CTS are tied together. This
> doesn't seem to be the case for the 100 and 102, which will happily send
> data out blind.
>
> Digging through the Technical Reference Manual
> ,
> the 200 does indeed have a different chip (82C51A) for handling serial IO,
> and perhaps it is pickier about when it allows outbound traffic. The TRM
> has what amounts to a decent data sheet on that chip, and this part caught
> my eye (bottom of pdf page 98):
>
> [image: image.png]
> It seems like perhaps it's possible to fix this with software? Or, am I
> way overthinking this whole thing, and there's another way to do it that's
> even easier? I know I can just get a null modem cable, but it's kind of a
> bummer to have to get all new cables to use a 200 with printers the 100/102
> happily connected to.
>
> Thanks for reading / any advice.
> -Charlie
>