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
<http://bitchin100.com/wiki/index.php?title=Model_100_Serial_Interface>
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 <arcadeshop...@gmail.com
<mailto:arcadeshop...@gmail.com>> wrote:
Why not wire dsr from the printer to CTS
On Fri, Jun 9, 2023, 5:23 PM Charlie Hoey <charlie.h...@gmail.com
<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
<http://lists.bitchin100.com/htdig.cgi/m100-bitchin100.com/2015-January/069836.html> that's
very similar (also this one
<http://lists.bitchin100.com/htdig.cgi/m100-bitchin100.com/2018-May/077378.html> and this
one <http://lists.bitchin100.com/htdig.cgi/m100-bitchin100.com/2013-January/065432.html>,
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
<https://ia801908.us.archive.org/14/items/Model_200_Technical_Reference_Manual_1986_Tandy/Model_200_Technical_Reference_Manual_1986_Tandy.pdf>,
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.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
--
bkw
