CTS/RTS is the current standard hardware flow control, so I'd be surprised
if any modern dongle didn't handle it as it's necessary for high speed
connections. I suggest *not* jumpering those together. I believe there is
some software for the Model 100 that can use them for hardware handshaking.
(HTERM?)
DSR/DTR is, if I recall correctly, a higher-level part of the handshake
("is there a device connected at all" rather than "is the device ready to
receive"). In my memory DSR/DTR was mainly used for flow control by some
terminals and printers in the 1980s. While I could imagine a new device
failing to assert DSR, that'd be shockingly poor design. More likely, as
John¹ stated, you've got a cable that leaves those wires out. Check for
continuity on the DSR and DTR pins and get a new cable if that's the
problem.
If your cable is fine, then Jim's loopback may be the only solution.
Looping DTR back to DSR makes it so that when the Tandy 200 checks DSR to
see if a modem is plugged in, it will hear its own signal from DTR
announcing its presence.
By the way, when people say "jumpering the wires together", don't literally
do that. You can end up with two devices fighting to set the same wire to
different voltages. It won't blow anything up, but it'll heat up and waste
electricity. What you actually want are the pins on one end jumpered
together, but not going across the cable to the other device, the first
picture in this ASCII art drawing:
A loopback cable Normal null modem Normal RS232C cable
DSR <--\ /--> DSR DSR <--\ /--- DSR DSR (DTE) <----- DSR (DCE)
) ( X
DTR ---/ \--- DTR DTR ---/ \--> DTR DTR (DTE) -----> DTR (DCE)
While unlikely, the problem could also be Carrier Detect, Pin 1. Some
devices want to see CD asserted before they are willing to talk. You can
fake it by wiring CD to DSR (on the same side of the cable), so that any
signal getting sent to the DSR port also goes to CD.
—b9
_____
¹ John, you were doing 3-wire RS-232!? I was amazed when I saw that on
Radio-Shack's CoCo, but I thought that was just Radio-Shack being stingy.
On Wed, Dec 21, 2022 at 12:09 PM John R. Hogerhuis <[email protected]> wrote:
>
>
> On Wed, Dec 21, 2022 at 11:51 AM Jim Anderson <[email protected]> wrote:
>
>> I’ve run into this before with the 200 – I don’t remember if it was CTS
>> or DSR or both that it wants to see asserted, but it definitely does behave
>> differently from the 100 and 102. If you don’t have one or both of those
>> lines high, the 200 appears to freeze up if you attempt serial
>> communication using TELCOM (ctrl-Break recovers). The 100 and 102 (at
>> least in TELCOM) don’t seem to care.
>>
>>
>>
>> There’s no real harm in jumpering both of these signals high if your wifi
>> modem isn’t actively asserting either of them. In a DB9 you would jumper 7
>> (RTS) to 8 (CTS) and 4 (DTR) to 6 (DSR). In a DB25 those would correspond
>> with 4 to 5 and 20 to 6.
>>
>>
>>
>>
>>
>
> Agree... one of my few Model T pet peeves... this is the "cable check"...
> uh... feature. Don't know what they were thinking. A given cable either
> works or it doesn't... in what universe is it a feature to do a sanity
> check on lines that aren't actually involved in communication on the Model
> T? And then if there is an issue, don't give a clear error message, just
> lock up.
>
> Just weird, I don't know what the engineers were thinking. TS-DOS, TEENY
> do it as well unless you're running a version with the feature disabled.
>
> Maybe Radio Shack and the 3rd party vendors wanted people to buy better or
> proprietary cables (from them)? Since the main result of the feature is
> that 3-wire cables don't work without looping back.
>
> -- John.
>
