On 11/13/2019 3:41 PM, Nigel Johnson via cctalk wrote:
No. While each end might be able to communicate with the local modem
in command mode using different parameters, when they are in connected
mode the modems will not convert anything, just pass the exact format
along. So if one end is expecting 7E2 and the other is sending 8N1
there will be a 50% chance that parity errors will be received.
cheers
Nigel
On 13/11/2019 16:16, Grant Taylor via cctalk wrote:
On 11/13/19 1:31 PM, Fred Cisin via cctalk wrote:
But, stuff like commands to the modem didn't need much of that, and
needed to be able to communicate in spite of wrong parameters. It
made sense for a modem to recognize a command, even with wrong
parity, etc.
Okay....
Now I'm thinking that there are really two phases / modes of
communications: 1) computer to modem commands, and 2) computer to
computer via modem connection data.
I think my previous statement applies to #2. I can see the value in
#1 being more liberal in what it recognizes and accepts.
But, I'd still be surprised if the following would work for #2.
[A]---(7E2)---{modem}==={modem}---(8N1)---[B]
Would A and B be able to transfer data between each other with
different (local) settings?
Jumping back in here:
Initially, tcpser's goal was to emulate enough of the "Hayes" command
set so as to bridge old BBS applications so they could be once again
used without modifying them and trying to make them aware of the
Internet. Over time, that mandate meant adding in support for S
registers and & commands and such, since apps used those.
However, the actual line functionality of the modem was never attempted
to be emulated, as doing so would defeat the purpose of the app.
Initially, I assumed everyone would set their BBS to 8N1, so as to
maximize the utility of the connection (8 bit clean, etc.).
But, now, I have a Teletype Model 43 here, and it only does 7 bit ASCII.
Fozztexx's mod helps, but it only cleans up parity while in command
mode, which means I can atdt jammingsignal.com, but then when I connect,
I can't log onto that Telnet BBS (that's the catchall name for such
things) because parity gets in the way.
To be as useful as possible, I think the utility should detect parity in
command mode, but then switch the entire data stream to that
configuration, both command mode and data mode.
The alternative (since a PC can't sniff the serial stream like the Hayes
did), is to allow parameters to set the specific parity and number of
stop bits. And, I think I'll do both. Without parity and stop bits,
sniff parity. With it, lock in the parity and don't sniff. That way,
if folks want the purist behavior, they do tcpser -s1200,N,8,1 and
sniffing can just do -s 1200
Jim
--
Jim Brain
[email protected]
www.jbrain.com
