Re: Question about modems
On 11/15/2019 8:09 PM, Fred Cisin via cctalk wrote: What do the various Hayes modemS do when you type "aT" ? I can speak to all modems, as I gave away most of mine. But the one I have right now has the following behavior: AT -> OK at -> OK aT -> CR, no LF, essentially echoing back the CR that was sent At -> same AAAT -> OK aaat -> OK Aaat -> At behavior aAT -> aT behavior AaT -> OK (AT found) at -> OK (at found) abcdefgAT -> OK (AT found) abcdefgat -> OK (at found) AbcdefaT -> aT behavior aBCDEFAt -> At behavior The rule seems to be: once you find an a, save it. If you find more as, just ignore, but if you see a non a non T, reset. Once a t is found, check case with saved char. If same case, detect parity and continue with command. What do they do when you used mixed case? And, are they all the same? (as mentioned before, "Hayes Compatible" was never completely defined.) I have no idea. Guess I'll have to create a small text file and have people pipe it into modems and see what comes out. It's been a cool exersize, and sorry I annoyed so many people with the trivial details of modems :-) Jim -- Jim Brain br...@jbrain.com www.jbrain.com
Re: Question about modems
What do the various Hayes modemS do when you type "aT" ? What do they do when you used mixed case? And, are they all the same? (as mentioned before, "Hayes Compatible" was never completely defined.)
Re: Question about modems
On 11/15/2019 5:18 PM, Chris Osborn via cctalk wrote: On Nov 15, 2019, at 1:54 PM, alan--- via cctalk wrote: MCU should set receive line coding to 8,N,1. When in command mode, you don't care about parity Actually it's in command mode that you *do* care about parity, which is why I added the parity detection in the first place. Without the parity detection there's no way for the modem to send back the command responses with the correct parity. That made it cumbersome to use tcpser when using terminals or communications software that insist on using even/odd/mark parity and would drop any characters that had the wrong parity. And, as I noted to Chris, I think it actually makes sense to convert all the time, so that a 7E1 device that is trying to connect to the Internet can do so with a minimum of hassle. If parity is stripped on both sides (C64 to tcpser to Internet to tcpser to 64, for example) and replaced when needed for the local classic machine, I think that's the best scenario. Jim
Re: Question about modems
On 11/14/2019 9:17 AM, a...@alanlee.org wrote: I think you may be over thinking this. I suppose a system could send a bit-stream where the data bits + any parity bits != 8 or the parity bit isn't in the trailing MSB position. However, for simplification lets consider only that case. A modem will always set the local line coding to 8,N,1. TCPSER aims to emulate a modem. I actually implemented the above (assume the line is 8,N,1) when I first wrote the code in 2004 or so, as my goal was to allow home computer BBS systems to run unmodifed using a serial interface to a PC, as I previously noted. Those machines could, as you note, set the comm channel to 8,N,1, so all was well. However, I made no provisions if the DTE could not run with 8,N,1. At VCF-Midwest this year, I tried to put my KSR43 online, only to find it will only do 7 bit ASCII. Enter FozzTexx's mods. I suppose you could have 7,N,x however the MSB of the 8-bit word period would be a stop bit and would transfer through the modulated transmission the same way - correctly. Actually, it won't. When the 7,E,1 hits the 8,N,1 (effectively) of the Internet, I could not even get past the initial "ASCII or PETSCII screen" :-( My advise is always set the MCU line coding to 8,N,1 (or preferably 1.5), strip the MSB in command RX, and manually re-add MSB parity stuffing for command responses only based on some algorithm that makes the most sense. I think you may be underthinking this. The target is not an MCU, but a piece of classic gear that people do not want to modify (or can't) to handle the internet. TCPSER stands in for a Hayes modem and allows the device to connect to the Internet (or another classic machine across the world using the Internet as a stand in for telco lines. Jim
Re: Question about modems
On Nov 15, 2019, at 1:54 PM, alan--- via cctalk wrote: > MCU should set receive line coding to 8,N,1. When in command mode, you don't > care about parity Actually it's in command mode that you *do* care about parity, which is why I added the parity detection in the first place. Without the parity detection there's no way for the modem to send back the command responses with the correct parity. That made it cumbersome to use tcpser when using terminals or communications software that insist on using even/odd/mark parity and would drop any characters that had the wrong parity. -- Follow me on twitter: @FozzTexx Check out my blog: http://insentricity.com
Re: Question about modems
On 11/15/2019 1:38 PM, Jim Brain wrote: On 11/15/2019 3:12 AM, Brent Hilpert via cctalk wrote: (If it is of any consequence at this point) If those vertical groups of 4 are intended to correspond to the first group of AT/at/At/aT, then you have the case bit (0x20) inverted, uppercase are bit 0x20 OFF (lower value), lower case are 0x20 ON (higher value). Well, the above values are what an 8N1 connections sees when the other end is set to the various 7 bit parms. I verified that the numbers above are correct, case and all. My apologies. The case is indeed backwards... The caps lock appears to have become stuck on in the test machine KB. Argh! I know I was pressing a shifted A Jim
Re: Question about modems
Again.. I really think you are overthinking this. MCU should set receive line coding to 8,N,1. When in command mode, you don't care about parity as it is presumed the connection from the host machine to the modem is short and largely has integrity. Every byte you receive in 8,N,1 command mode, zero the MSB before interpreting the character. Also keep four binning counts of each byte received in command mode on whether E,O,M,S space passes a respective validity check. Whichever bin over time has the highest count of successes vs errors is the parity scheme you use when encoding/stuffing the MSB of the 8,N,1 response bytes back to the host computer. -Alan On 2019-11-15 01:23, Jim Brain via cctalk wrote: If you look at the values received by an 8N1 connection from a sender using the different settings, you get: AT at At aT 7E1 E174 41D4 E1D4 4174 7O1 61F4 C154 6154 C1F4 7M1 E1F4 C1D4 E1D4 C1F4 7S1 6174 4154 6154 4174 8N1 6174 4154 6154 4174 Obviously, still trying to find the magic boolean logic equation to tease out the parity, but you could brute force it with these values and only aT would cause you issues requiring looking at CR (7E1 would send 8d, while 7S1/8N1 would send 0d. Jim
Re: Question about modems
On 11/15/2019 3:12 AM, Brent Hilpert via cctalk wrote: On 2019-Nov-14, at 10:23 PM, Jim Brain via cctalk wrote: If you look at the values received by an 8N1 connection from a sender using the different settings, you get: AT at At aT 7E1 E174 41D4 E1D4 4174 7O1 61F4 C154 6154 C1F4 7M1 E1F4 C1D4 E1D4 C1F4 7S1 6174 4154 6154 4174 8N1 6174 4154 6154 4174 Obviously, still trying to find the magic boolean logic equation to tease out the parity, but you could brute force it with these values and only aT would cause you issues requiring looking at CR (7E1 would send 8d, while 7S1/8N1 would send 0d. (If it is of any consequence at this point) If those vertical groups of 4 are intended to correspond to the first group of AT/at/At/aT, then you have the case bit (0x20) inverted, uppercase are bit 0x20 OFF (lower value), lower case are 0x20 ON (higher value). Well, the above values are what an 8N1 connections sees when the other end is set to the various 7 bit parms. I verified that the numbers above are correct, case and all. Let me peruse the code you sent. I did some eoring, but maybe your math works as well. First, it looks like I need to replicate the behavior os the at prompt (it looks to be calculated as soon as the T is received). Jim -- Jim Brain br...@jbrain.com www.jbrain.com
Re: Question about modems
On Thu, 14 Nov 2019, Jim Brain via cctalk wrote: While you're working in that code, would it be possible to derive the baud rate of the host like the Smartmodem did? The modem would set the baud rate on the first command sent to the modem. It would be kind of a neat feature to have. :) BTW, did my telnet echo and ip address patches survive into FozzTex's version? g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.diy-cockpits.org/coll - Go Collimated or Go Home. Some people collect things for a hobby. Geeks collect hobbies. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://scarlet.deltasoft.com - Get it _today_!
Re: Question about modems
On 2019-Nov-14, at 10:23 PM, Jim Brain via cctalk wrote:
> If you look at the values received by an 8N1 connection from a sender using
> the different settings, you get:
>
> AT
> at
> At
> aT
> 7E1
> E174
> 41D4
> E1D4
> 4174
> 7O1
> 61F4
> C154
> 6154
> C1F4
> 7M1
> E1F4
> C1D4
> E1D4
> C1F4
> 7S1
> 6174
> 4154
> 6154
> 4174
> 8N1
> 6174
> 4154
> 6154
> 4174
>
> Obviously, still trying to find the magic boolean logic equation to tease out
> the parity, but you could brute force it with these values and only aT would
> cause you issues requiring looking at CR (7E1 would send 8d, while 7S1/8N1
> would send 0d.
(If it is of any consequence at this point)
If those vertical groups of 4 are intended to correspond to the first group of
AT/at/At/aT, then you have the case bit (0x20) inverted, uppercase are bit 0x20
OFF (lower value), lower case are 0x20 ON (higher value).
If it's of any interest, here's some (untested) code, using your finding that
the case must be consistent:
===
/* Return: -1 the two characters are not ASCII A/a and T/t
* -2 the case is not consistent between the two characters
* 0 SPACE parity
* 1 ODD parity
* 2 EVEN parity
* 3 MARK parity
*/
int
AssessATParity( chA, chT )
int chA, chT;
{ int pp;
if( (chA&0x5F)!='A' || (chT&0x5F)!='T' )// check characters are
A/a and T/t
return( -1 );
if( ((chA^chT)&0x20) != 0 ) // check case is
consistent
return( -2 );
pp = ((chA&0x80)>>6) | ((chT&0x80)>>7); // extract and combine
the two parity bits into two-bit value (0..3)
if( pp==0 || pp==3 )// check for Space or
Mark parity
return( pp );
return( (chA&0x20) ? pp : (3-pp) ); // Odd or Even parity,
but pp value (1 or 2) must be swapped depending on case
}
Re: Question about modems
On 11/15/2019 12:37 AM, Jim Brain wrote: Looks like there might be a few more corner cases as well. Maybe modems did not accept mixed case. AT and at seem to work fine... Anyone have a modem handy to check? Spoiler alert... They do not. Only 'at' and 'AT' are recognized. So, bit 5 of both chars must be the same for the command to be handled. Jim -- Jim Brain br...@jbrain.com www.jbrain.com
Re: Question about modems
Looks like there might be a few more corner cases as well. Maybe modems did not accept mixed case. AT and at seem to work fine... Anyone have a modem handy to check?
Re: Question about modems
If you look at the values received by an 8N1 connection from a sender using the different settings, you get: AT at At aT 7E1 E174 41D4 E1D4 4174 7O1 61F4 C154 6154 C1F4 7M1 E1F4 C1D4 E1D4 C1F4 7S1 6174 4154 6154 4174 8N1 6174 4154 6154 4174 Obviously, still trying to find the magic boolean logic equation to tease out the parity, but you could brute force it with these values and only aT would cause you issues requiring looking at CR (7E1 would send 8d, while 7S1/8N1 would send 0d. Jim
Re: Question about modems
On 2019-Nov-14, at 9:59 PM, Brent Hilpert via cctalk wrote: > On 2019-Nov-14, at 9:30 PM, Jim Brain via cctalk wrote: >> On 11/14/2019 11:05 PM, Brent Hilpert via cctalk wrote: >>> >>> (Without having gone through the code presented in full detail, but >>> thinking from root premises.) >>> >>> ASCII A = 0x41 --> 2 bits on >>> ASCII T = 0x54 --> 3 bits on >> >> I agree, though I believe aT,At,AT,and at are all allowed, which complicates >> things a bit aT is the bad one, where the calc for 7E1 and 7S1/8N1 yield the >> same values... > > ... right, was forgetting about case. > But if you're trying to account for mixed case, I don't think the CR resolves > it anyways: > > ASCII A = 0x41 --> 2 bits on > ASCII T = 0x54 --> 3 bits on > ASCII a = 0x61 --> 3 bits on > ASCII t = 0x74 --> 4 bits on > ASCII CR = 0x0D --> 3 bits on > > In sequence "Ta", all characters have an odd number of bits on and would > produce the same parity value, and collectively would be indistinguishable > from a corresponding constant M or S parity. Whoops, that should have been: in sequence "aT".
Re: Question about modems
On 2019-Nov-14, at 9:30 PM, Jim Brain via cctalk wrote: > On 11/14/2019 11:05 PM, Brent Hilpert via cctalk wrote: >> >> (Without having gone through the code presented in full detail, but thinking >> from root premises.) >> >> ASCII A = 0x41 --> 2 bits on >> ASCII T = 0x54 --> 3 bits on > > I agree, though I believe aT,At,AT,and at are all allowed, which complicates > things a bit aT is the bad one, where the calc for 7E1 and 7S1/8N1 yield the > same values... ... right, was forgetting about case. But if you're trying to account for mixed case, I don't think the CR resolves it anyways: ASCII A = 0x41 --> 2 bits on ASCII T = 0x54 --> 3 bits on ASCII a = 0x61 --> 3 bits on ASCII t = 0x74 --> 4 bits on ASCII CR = 0x0D --> 3 bits on In sequence "Ta", all characters have an odd number of bits on and would produce the same parity value, and collectively would be indistinguishable from a corresponding constant M or S parity.
Re: Question about modems
On Thu, Nov 14, 2019, 10:30 PM Jim Brain via cctalk wrote: > On 11/14/2019 11:05 PM, Brent Hilpert via cctalk wrote: > > > > (Without having gone through the code presented in full detail, but > thinking from root premises.) > > > > ASCII A = 0x41 --> 2 bits on > > ASCII T = 0x54 --> 3 bits on > > I agree, though I believe aT,At,AT,and at are all allowed, which > complicates things a bit aT is the bad one, where the calc for 7E1 and > 7S1/8N1 yield the same values... > 1200 baud hayes modems required the initial AT be all upper case. I can't recall if the 2400 baud modem relaxed this, or if it was later version. Also, AT introduced commands. +++ could be followed immediately by ATH to hang up... But the parity trick discussed here matches my memory as well... Warner >
Re: Question about modems
On 11/14/2019 11:05 PM, Brent Hilpert via cctalk wrote: (Without having gone through the code presented in full detail, but thinking from root premises.) ASCII A = 0x41 --> 2 bits on ASCII T = 0x54 --> 3 bits on I agree, though I believe aT,At,AT,and at are all allowed, which complicates things a bit aT is the bad one, where the calc for 7E1 and 7S1/8N1 yield the same values... Jim
Re: Question about modems
On 2019-Nov-14, at 6:48 PM, Jim Brain via cctalk wrote:
> Well, I am off and running on getting my version of the code up to speed:
>
> https://github.com/go4retro/tcpser
>
> Man, some of this code is rough. I have learned a lot about writing C code
> in the last decade+.
>
> Anyway, while I work on adding the appropriate functionality into the
> codebase, I find myself ruminating on why there were so many parity options
> in serial communications.
>
> I understand the need for parity per se, given link quality and such. But,
> why the need for Odd, Even, Mark, Space. Is there some reason why different
> parity options work better in certain situations?
>
> Also, for those wanting to help with some code:
>
> int detect_parity(modem_config *cfg)
> {
> int parity, eobits;
> int charA, charT, charCR;
>
>
> charA = cfg->pchars[0];
> charT = cfg->pchars[1];
> charCR = cfg->pchars[2];
>
> parity = (charA & 0x80) >> 7;
> parity |= (charT & 0x80) >> 6;
> parity |= (charCR & 0x80) >> 5;
>
> eobits = gen_parity(charA & 0x7f);
> eobits |= gen_parity(charT & 0x7f) << 1;
> eobits |= gen_parity(charCR & 0x7f) << 2;
>
> if (parity == eobits)
> return 2;
>
> if (parity && (parity ^ eobits) == (parity | eobits))
> return 1;
>
> return parity & 0x3;
> }
>
> #define gen_parity(v) (v) * 0x0101010101010101ULL) &
> 0x8040201008040201ULL) % 0x1FF) & 1)
>
> Fozztexx (Chris Osborn) authored this little slice of code, and it uses the
> AT to determine parity of the form:
>
> space == 0
> odd == 1
> even == 2
> mark == 3
>
> I'm trying to sort the code out in my head, which will happen, but takes
> time. The issue I see with it is the use of the CR as the third char to
> check.
>
> Hayes S registers always allows the redefinition of the CR character, via S3.
> As such, there's no guarantee line termination = CR, (yes, it's valid for
> the first AT command, but not after, so if the user does a 8N1 ATS3=15
> and then switches to 7E1, the emulator will not handle well. I agree the
> likelihood is almost nil someone does this, but tcpser is supposed to be very
> pedantic on such matters.
>
> Thus, anyone have a way to discern parity using only the 'A' and 'T' ? I
> guess I might be able to still use the terminator, since I know what it is
> ahead of time, but not sure if the above code works on the principle that the
> 3 ASCII values have unique traits that would not hold true for other values.
>
(Without having gone through the code presented in full detail, but thinking
from root premises.)
ASCII A = 0x41 --> 2 bits on
ASCII T = 0x54 --> 3 bits on
Thus A and T would produce different parity values, and presented with an
instance of each character it should be possible to discern all 4 potential
parity encodings (S/O/E/M derived from the 4 combinations possible from
observing the parity bit from the two character instances 00/10/01/11 (if I
have parity policy in the right order)).
So it wouldn't seem like the CR would be necessary for the task.
If one assumes ASCII encoding for the A & T it seems to me the code could be
simpler - e.g. why calculate parity for known characters; but perhaps the
writer had something more in mind than I'm aware or thinking of.
Re: Question about modems
Well, I am off and running on getting my version of the code up to speed:
https://github.com/go4retro/tcpser
Man, some of this code is rough. I have learned a lot about writing C
code in the last decade+.
Anyway, while I work on adding the appropriate functionality into the
codebase, I find myself ruminating on why there were so many parity
options in serial communications.
I understand the need for parity per se, given link quality and such.
But, why the need for Odd, Even, Mark, Space. Is there some reason why
different parity options work better in certain situations?
Also, for those wanting to help with some code:
int detect_parity(modem_config *cfg)
{
int parity, eobits;
int charA, charT, charCR;
charA = cfg->pchars[0];
charT = cfg->pchars[1];
charCR = cfg->pchars[2];
parity = (charA & 0x80) >> 7;
parity |= (charT & 0x80) >> 6;
parity |= (charCR & 0x80) >> 5;
eobits = gen_parity(charA & 0x7f);
eobits |= gen_parity(charT & 0x7f) << 1;
eobits |= gen_parity(charCR & 0x7f) << 2;
if (parity == eobits)
return 2;
if (parity && (parity ^ eobits) == (parity | eobits))
return 1;
return parity & 0x3;
}
#define gen_parity(v) (v) * 0x0101010101010101ULL) &
0x8040201008040201ULL) % 0x1FF) & 1)
Fozztexx (Chris Osborn) authored this little slice of code, and it uses
the AT to determine parity of the form:
space == 0
odd == 1
even == 2
mark == 3
I'm trying to sort the code out in my head, which will happen, but takes time.
The issue I see with it is the use of the CR as the third char to check.
Hayes S registers always allows the redefinition of the CR character, via S3. As
such, there's no guarantee line termination = CR, (yes, it's valid for the first AT
command, but not after, so if the user does a 8N1 ATS3=15 and then switches
to 7E1, the emulator will not handle well. I agree the likelihood is almost nil
someone does this, but tcpser is supposed to be very pedantic on such matters.
Thus, anyone have a way to discern parity using only the 'A' and 'T' ? I guess
I might be able to still use the terminator, since I know what it is ahead of
time, but not sure if the above code works on the principle that the 3 ASCII
values have unique traits that would not hold true for other values.
Jim
Re: Question about modems
I do too. KF5CNC. Interested in packet. Looking for a local ham also. Also into retro Amiga and CP/M. It's just a hop skip jump if you ever decide to visit New Orleans, louisiana. 😀73Sent from my Verizon, Samsung Galaxy smartphone Original message From: Grant Taylor via cctalk Date: 11/14/19 10:41 AM (GMT-06:00) To: cctalk@classiccmp.org Subject: Re: Question about modems On 11/14/19 7:41 AM, Jim MacKenzie via cctalk wrote:> I have a ham radio callsign too (VE5EV) and one of these years I intend > to really experiment with packet radio, and eventually, AX25 TCP/IP > networking over radio using packet modems.I'm also interested in packet. I keep poking friends & coworkers near me to see if they are interested. None of them have indicated any interest, yet.-- Grant. . . .unix || die
Re: Question about modems
On 11/14/19 7:41 AM, Jim MacKenzie via cctalk wrote: I have a ham radio callsign too (VE5EV) and one of these years I intend to really experiment with packet radio, and eventually, AX25 TCP/IP networking over radio using packet modems. I'm also interested in packet. I keep poking friends & coworkers near me to see if they are interested. None of them have indicated any interest, yet. -- Grant. . . . unix || die
Re: Question about modems
I think you may be over thinking this. I suppose a system could send a bit-stream where the data bits + any parity bits != 8 or the parity bit isn't in the trailing MSB position. However, for simplification lets consider only that case. A modem will always set the local line coding to 8,N,1. Any bytes received in command mode will be AND'd with 0x7f to strip any parity bits before being interpreted. A modem could optionally detect and reconstruct the local line parity scheme for the purpose of stuffing the 8th bit MSB for the command responses (eg 'OK' etc) on the local line. But it will always transfer the entire 8-bit word period to the remote end in data mode - unmodified. I suppose you could have 7,N,x however the MSB of the 8-bit word period would be a stop bit and would transfer through the modulated transmission the same way - correctly. The number of stop bits only affect the transmission side of characters on the local line - in that it adds extra padding between bytes to mitigate timing mis-alignment. My rule of thumb for RTL UARTs is transmitters should always idle for 1.5 stop periods while receivers should always begin the start bit search after .5 bit-periods after the 8th data bit period. I suppose this could cause problems when a line rate is 100% saturated - but so could oscillator mismatch over time. My advise is always set the MCU line coding to 8,N,1 (or preferably 1.5), strip the MSB in command RX, and manually re-add MSB parity stuffing for command responses only based on some algorithm that makes the most sense. -A On 2019-11-13 19:08, Jim Brain via cctalk wrote: 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
Re: Question about modems
On 2019-11-13 09:17, geneb via cctalk wrote: Jim, I'd try reaching out to Dale Heatherington... Dale generally keeps to himself and rarely talks shop outside of the context of telecommunication discussions - which he also avoids. I've asked him if he would like to speak at VCF-SE a couple times but he's always replied he doesn't do public speaking. The few times I've brought up modems, he's (maybe coyly) pointed out at this point in time, others would be a far better resource. He has started to attend the show at least. I've seen him at the last 2 VCF-SEs. But he never interacted with any of the 4-5 telecom/modem exhibitors to my knowledge. -Alan
RE: Question about modems
-Original Message- From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Fred Cisin via cctalk Sent: Wednesday, November 13, 2019 7:08 PM To: General Discussion: On-Topic and Off-Topic Posts Subject: RE: Question about modems >What do you need to do to use an acoustic modem with a cellphone? >You can get a "retro" handset for a cellphone, that will fit the rubber cups, but, will it work? I have one of those handsets, and somewhere in the basement, a Radio Shack acoustic modem, so I could actually try it. I expect it would work, but would suffer from a lot of line noise because of how modern telephony works. My network routes calls via UMTS, not VoLTE. I've never done a VoLTE call, so perhaps it would be better. Jim
RE: Question about modems
-Original Message- From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of allison via cctalk Sent: Wednesday, November 13, 2019 6:02 PM To: cctalk@classiccmp.org Subject: Re: Question about modems > Like RS232/432 signaling the art and science is getting lost to time and age. > I'd bet more than half here never used a modem or have not in more than > 15-20 years. That's probably true, but I maintain my nostalgia for modems and have a bunch, including real Hayes 300 and 1200 Smartmodems, a SupraFAXmodem v.32bis and v.FC (the former was my first fast modem; the latter is the one I really wanted in the day :) but I can't find a way to upgrade it to v.34), and a nice pile of USR v.Everything modems including an ISA internal, a few v.90 and one v.92 external, and a new-in-shrink HST 14.4. (HST works super well on modern VoIP lines compared to v.32bis and v.34, I find.) I even have a dialup console to one of the Linux boxes on my network. Can't say I need it. It's a bit of an indulgence. But it's there, and it works. I have a ham radio callsign too (VE5EV) and one of these years I intend to really experiment with packet radio, and eventually, AX25 TCP/IP networking over radio using packet modems. Jim
Re: Question about modems
On Nov 13, 2019, at 5:07 PM, Fred Cisin via cctalk wrote: > What do you need to do to use an acoustic modem with a cellphone? > You can get a "retro" handset for a cellphone, that will fit the rubber cups, > but, will it work? Yes. https://www.youtube.com/watch?v=uQqWHLZjOjA -- Follow me on twitter: @FozzTexx Check out my blog: http://insentricity.com
Re: Question about modems
On 2019-Nov-13, at 5:22 PM, Electronics Plus via cctalk wrote: > ... I can simply connect 2 modems to each > other via a POTS phone cable, attach each modem via serial cable to a > different laptop, and set one to Listen and the other to Answer via > HyperTerminal. This will work for some modems, not for others. At the electrical level there were two techniques used for transmitting the signal onto the phone line. - One technique used a transformer to couple to the phone line, thus the modem actually injected audio-frequency (AF) energy onto the phone-line. The simple back-to-back POTS cable connection may work for modems using this technique. (I have successfully done this.) - The other technique used opto-isolators to couple to the phone-line. They did not provide energy to the line, they AF-modulated the phone-line central-office-supplied DC current. For modems using this technique, you have to supply a line current. The old 9V battery in series in the loop trick might work but I don't recall whether I've tried it. (Result of experiments and internal observations with several modems years ago, where I was attempting as you suggest and wondered why it worked with some modems and not others. I think I was trying to do local data transfer with macs that had internal modems but no 232 port.)
Re: Question about modems
On 11/13/19 5:25 PM, Electronics Plus via cctalk wrote: And here my problem is that I have the old modems, but I can't test them because I no longer have a land line. ~chuckle~ Is there any way to test an internal or external modem without anything except broadband or cellular connections? It depends if "without anything" is referring to "no additional phone line / service from an external 3rd party" or "nothing at all added to the mix". I know I can't test the acoustic modems, but I was hoping to be able to test internal ISA and PCI, as well as external modems from 300 baud to 56k. Perhaps there is some inexpensive gizmo available? It should be quite possible to test slower modems. However, faster speeds, 14.4 / 19.2 / 28.8 / 33.6 / 56, will be more problematic to test. People are reliably getting modems to connect across VoIP using lossless CODECs, i.e. ULAW / ALAW. This does take some effort to (initially) set up. But it should be quite serviceable once it is set up. I think that some companies make Analog Terminal Adapters (ATA) that have two ports, one would connect to each modem, and any number dialed would call (ring) the other port. I /think/ that Grandstream used to make a Handy Tone that did this. Again, this will take some configuration. I routinely (almost daily) see @Level29_BBS talking about dialing in across VoIP. -- Grant. . . . unix || die
RE: Question about modems
A "telephone line simulator". On Wed, 13 Nov 2019, Electronics Plus wrote: A young gent (about 22 yrs old) reminded me of HyperTerminal on XP. Since I have stacks of old working XP laptops, I can simply connect 2 modems to each other via a POTS phone cable, attach each modem via serial cable to a different laptop, and set one to Listen and the other to Answer via HyperTerminal. If I want to transfer files, I could use PuTTy, which also runs on XP. Seems like that should take care of both send and receive on both modems? Now to make a simple batch file that can automate the process, since I don't want to do everything manually for 50+ modems! I only have 2 acoustic modems, so I will set them aside for now. I used to have a "telephone tester" machine from Radio Shack, but it disappeared many years ago. I do have an old TAB book of "telephone projects" and another for test equipment that I could build, but that would be a lot of trouble to only test about 50 items. Not enough to justify investing in specialized test gear. OTOH, you can have fun with it. Small children seem to enjoy having "toy phones" that actually work, etc. When I was teaching my dog to tell me when the phone rang, I had a button in my pocket, . . . Testing DTMF tones, etc. is more involved, but if you hear it attempting to "dial", that's probably close enough. "Dial tone" is a little more involved, and a thorough test should include whether it detects it properly, etc. Going "off hook" on an incoming call requires creating a ring signal (90VAC at 20 Hz), . . . But, being up-front with your customers about the extent of the testing means no ill will if not all functions and capabilities are tested.
RE: Question about modems
-Original Message- From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Fred Cisin via cctalk Sent: Wednesday, November 13, 2019 7:08 PM To: General Discussion: On-Topic and Off-Topic Posts Subject: RE: Question about modems On Wed, 13 Nov 2019, Electronics Plus via cctalk wrote: > And here my problem is that I have the old modems, but I can't test them > because I no longer have a land line. Is there any way to test an > internal or external modem without anything except broadband or cellular > connections? I know I can't test the acoustic modems, but I was hoping > to be able to test internal ISA and PCI, as well as external modems from > 300 baud to 56k. Perhaps there is some inexpensive gizmo available? A "telephone line simulator". In some cases, you might be able to just connect them, with a power supply. One set to "Originate" and one to "Answer", of course. But, you also want a "dial tone". And, if you want to test answering capabilities, then you also need a "ring simulator", which is 90VAC at 20Hz. (often a lot of tolerance) What do you need to do to use an acoustic modem with a cellphone? You can get a "retro" handset for a cellphone, that will fit the rubber cups, but, will it work? A young gent (about 22 yrs old) reminded me of HyperTerminal on XP. Since I have stacks of old working XP laptops, I can simply connect 2 modems to each other via a POTS phone cable, attach each modem via serial cable to a different laptop, and set one to Listen and the other to Answer via HyperTerminal. If I want to transfer files, I could use PuTTy, which also runs on XP. Seems like that should take care of both send and receive on both modems? Now to make a simple batch file that can automate the process, since I don't want to do everything manually for 50+ modems! I only have 2 acoustic modems, so I will set them aside for now. I used to have a "telephone tester" machine from Radio Shack, but it disappeared many years ago. I do have an old TAB book of "telephone projects" and another for test equipment that I could build, but that would be a lot of trouble to only test about 50 items. Cindy
RE: Question about modems
On Wed, 13 Nov 2019, Electronics Plus via cctalk wrote: And here my problem is that I have the old modems, but I can't test them because I no longer have a land line. Is there any way to test an internal or external modem without anything except broadband or cellular connections? I know I can't test the acoustic modems, but I was hoping to be able to test internal ISA and PCI, as well as external modems from 300 baud to 56k. Perhaps there is some inexpensive gizmo available? A "telephone line simulator". In some cases, you might be able to just connect them, with a power supply. One set to "Originate" and one to "Answer", of course. But, you also want a "dial tone". And, if you want to test answering capabilities, then you also need a "ring simulator", which is 90VAC at 20Hz. (often a lot of tolerance) What do you need to do to use an acoustic modem with a cellphone? You can get a "retro" handset for a cellphone, that will fit the rubber cups, but, will it work?
RE: Question about modems
The case presented is an true corner case. Usually modems can be set for rate, bits, and parity that matches the target system. AS modem became more sophisticated (26/33/56k) they were easily set and I just a few I have. Older 300/1200/2400 baud modems like DEC DF02/03 had switch settings likely others did too. The 9600 were generally smart. Those that used AT command set were very setable as there was usually large menu of options. There were exceptions "winmodems" that were only hardware port and the system did all the work in software. Generally flaky to the max. DEC DFxx series had their own non AT command set. What is forgotten is that many of the modem programs could swich parameters on the fly after carrier detect went true. Like RS232/432 signaling the art and science is getting lost to time and age. I'd bet more than half here never used a modem or have not in more than 15-20 years. Allison And here my problem is that I have the old modems, but I can't test them because I no longer have a land line. Is there any way to test an internal or external modem without anything except broadband or cellular connections? I know I can't test the acoustic modems, but I was hoping to be able to test internal ISA and PCI, as well as external modems from 300 baud to 56k. Perhaps there is some inexpensive gizmo available? Cindy
Re: Question about modems
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
br...@jbrain.com
www.jbrain.com
Re: Question about modems
On 11/13/19 4:16 PM, 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?
>
>
>
The case presented is an true corner case. Usually modems can be set
for rate, bits, and parity that matches the target system. AS modem
became more sophisticated (26/33/56k) they were easily set and I just a
few I have. Older 300/1200/2400 baud modems like DEC DF02/03 had
switch settings likely others did too. The 9600 were generally smart.
Those that used AT command set were very setable as there was usually
large menu of options.
There were exceptions "winmodems" that were only hardware port
and the system did all the work in software. Generally flaky
to the max. DEC DFxx series had their own non AT command set.
What is forgotten is that many of the modem programs could swich
parameters on the fly after carrier detect went true.
Like RS232/432 signaling the art and science is getting lost
to time and age. I'd bet more than half here never used a
modem or have not in more than 15-20 years.
Allison
Re: Question about modems
On 11/13/19 2: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. That's what I thought. Thank you for the confirmation. -- Grant. . . . unix || die
Re: Question about modems
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?
--
Nigel Johnson
MSc., MIEEE
VE3ID/G4AJQ/VA3MCU
Amateur Radio, the origin of the open-source concept!
You can reach me by voice on Skype: TILBURY2591
If time travel ever will be possible, it already is. Ask me again yesterday
This e-mail is not and cannot, by its nature, be confidential. En route from me
to you, it will pass across the public Internet, easily readable by any number
of system administrators along the way.
Nigel Johnson
Please consider the environment when deciding if you really need to print this message
Re: Question about modems
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?
--
Grant. . . .
unix || die
Re: Question about modems
On Wed, 13 Nov 2019, Grant Taylor via cctalk wrote: Are you sure that the parity stripping (for lack of a better description) was meant to translate things between modems? I would speculate that it was to transition from serial communications which inherently depend on those settings to TCP connections (raw / cooked / NVT / etc.) which inherently don't use those settings. Perhaps. But, we thought that modems were FOREVER. We weren't thinking ahead to communication other than POTS (Plain Old Telephone System). "WOW! the new modems are 50% faster! They are close to the theoretical maximum for copper wire!" Parity, stop bits etc. were essential for error detection, ease of parsing, and slow physical devices. A single bit error in a file transfer could be disastrous. 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.
Re: Question about modems
The following is based on my limited understanding. I could easily be wrong. Please correct me if I am. On 11/13/19 12:25 AM, Jim Brain via cctalk wrote: Some time ago, Chris Osborn (FozzTexx) forked a copy of my project to fix some bugs and he also added in some parity code, which looks to strip parity from the incoming serial connection (in the case that the serial port is set as 8N1 and the computer attached to it sends in 7E1 or similar. Are you sure that the parity stripping (for lack of a better description) was meant to translate things between modems? I would speculate that it was to transition from serial communications which inherently depend on those settings to TCP connections (raw / cooked / NVT / etc.) which inherently don't use those settings. I am working to merge in all of his changes into the mainline codebase, but I am unclear on prpper Hayes behavior. His Readme says: "I also made the modem routines automatically detect parity and ignore it in AT commands and print out modem responses in matching parity. Parity is *not* stripped when sending data over the connection, which is how a real modem behaves. This may or may not be what you want. Some servers will expect an 8 bit connection and may not work." Did Hayes modem really do that? I thought most later modems self detected parity and speed and thus would have switched both the comm on the serial port and the data sent to the other side in the same parity (if the terminal was 7E1, the modem would configure as 7E1 and send 7 bit data to the other side. My limited understanding is that modems were largely transparent to serial communications. In that once the modems established the connection, they blindly passed data back and forth, much like a null modem would do. As such, devices on either end of the serial link would need to be configured identically to be able to communicate with each other. This makes me think that traditional modems would NOT alter ~> translate communications parameters as data went through the modem. But, maybe real modems did as Chris notes. I'm guessing that modems did detect what settings were in use so that they could match them to properly recognize and understand modem (AT) commands. But I suspect that's the extent of what the detection was used for. Anyone have guidance on this? The goal of tcpser is to emulate a Hayes modem as much as possible, but I never really thought about mismatched parity on the RS232 line and how to deal with it. -- Grant. . . . unix || die
Re: Question about modems
And, more than one different model!
A bunch of yuears ago, Joe Campbell ("C Programmer's Guide To Serialo
Communication", "RS232 Solution", etc, NOT the PBS Joe Campbell) told me
that he was doing some consulting for Hayes, about setting up the standard
for "Hayes Compatible"; it seemed that not all of their modems did things
the same way! I don't know WHICH things needed to be adjusted.
On Wed, 13 Nov 2019, Nigel Johnson via cctalk wrote:
I actually have an original Hayes 300 modem. Would it be any use if I could
set it up for a a test, or would it need another genuine Hayes one to talk to
for what you need?
cheers,
Nigel
Re: Question about modems
On Nov 13, 2019, at 10:41, Nigel Johnson wrote: > > > On 13/11/2019 13:36, Chuck Guzis via cctalk wrote: >> There are other "oddball" combinations, such as 8E1 and 8O1, which sends >> a 9-bit data frame. You can see datasheets on some UARTs as well as MCU >> UARTs that support the 9 bit packet. > According to the diagram of the Smartmodem there is no UART, the 1488s and > 1489s go directly to the Z80. Somebody has to do speed and word format sensing, to pull off something like the Smartmodem. Hayes Technical Reference pointed at earlier has a table of supported data word formats in section A.1.1, page A-2. Start bits, data bits, parity, stop bits 1, 7, even/odd, 1 or more 1, 7, none, 2 1, 7, mark/space, 1 or more 1, 8, none, 1 or more That’s all! -Frank McConnell
Re: Question about modems
On 11/13/19 10:41 AM, Nigel Johnson via cctalk wrote: > > On 13/11/2019 13:36, Chuck Guzis via cctalk wrote: >> There are other "oddball" combinations, such as 8E1 and 8O1, which sends >> a 9-bit data frame. You can see datasheets on some UARTs as well as MCU >> UARTs that support the 9 bit packet. > According to the diagram of the Smartmodem there is no UART, the 1488s > and 1489s go directly to the Z80. >> Also, don't/doesn't TDD (5 level code) use 5E2 or some such. Same for >> Telex/TWX. > > Not sure 5 level code (ITU #2) ever had parity, but to confuse the issue > even further, there was a 1.5 stop bit option too, for mechanical machines! Strange that--not even a DART? Well, I was always a Racal Vadic guy back in the day of 300 bps. Also, 134.5 for selectric machines. --Chuck
Re: Question about modems
On 13/11/2019 13:36, Chuck Guzis via cctalk wrote: There are other "oddball" combinations, such as 8E1 and 8O1, which sends a 9-bit data frame. You can see datasheets on some UARTs as well as MCU UARTs that support the 9 bit packet. According to the diagram of the Smartmodem there is no UART, the 1488s and 1489s go directly to the Z80. Also, don't/doesn't TDD (5 level code) use 5E2 or some such. Same for Telex/TWX. Not sure 5 level code (ITU #2) ever had parity, but to confuse the issue even further, there was a 1.5 stop bit option too, for mechanical machines! cheers, NIgel --Chuck -- Nigel Johnson MSc., MIEEE VE3ID/G4AJQ/VA3MCU Amateur Radio, the origin of the open-source concept! You can reach me by voice on Skype: TILBURY2591 If time travel ever will be possible, it already is. Ask me again yesterday This e-mail is not and cannot, by its nature, be confidential. En route from me to you, it will pass across the public Internet, easily readable by any number of system administrators along the way. Nigel Johnson Please consider the environment when deciding if you really need to print this message
Re: Question about modems
There are other "oddball" combinations, such as 8E1 and 8O1, which sends a 9-bit data frame. You can see datasheets on some UARTs as well as MCU UARTs that support the 9 bit packet. Also, don't/doesn't TDD (5 level code) use 5E2 or some such. Same for Telex/TWX. --Chuck
Re: Question about modems
Not much in the manual. I browsed it looking for anything about data bits and stop bits. Nothing. p1-2: ' Commands given to the Smartmodem must be ASCII coded at baud rates between 110 baud and 1200 baud. Once 'on-line', any code at any speed from 0 to 300 baud may be used.' p 9-1 'Do not send any data to the Smartmodem while it is in local command mode unless the data is intended to be a command. Random data can confuse the baud rate detector and the command decoder giving unpredicatable results.' That is al lI can find i nthe manual. cheers, Nigel On 13/11/2019 12:39, Jim Brain via cctalk wrote: On 11/13/2019 5:31 AM, Nigel Johnson via cctalk wrote: I actually have an original Hayes 300 modem. Would it be any use if I could set it up for a a test, or would it need another genuine Hayes one to talk to for what you need? I looked at the SmartModem 300. It looks like it completely detected the speed and parity internal to the unit. If you have a manual or a link ot one to validate, I think that would suffice. If it did do that, then it would have reconfigured itself to match the terminal and thus all communication would be in the same format (8N1, 7E1, etc). I did a quick check for an online manual, but my Google-fu is weak today. Jim -- Nigel Johnson MSc., MIEEE VE3ID/G4AJQ/VA3MCU Amateur Radio, the origin of the open-source concept! You can reach me by voice on Skype: TILBURY2591 If time travel ever will be possible, it already is. Ask me again yesterday This e-mail is not and cannot, by its nature, be confidential. En route from me to you, it will pass across the public Internet, easily readable by any number of system administrators along the way. Nigel Johnson Please consider the environment when deciding if you really need to print this message
Re: Question about modems
On Nov 13, 2019, at 6:40, allison wrote: > > On 11/13/19 9:17 AM, geneb via cctalk wrote: >> On Wed, 13 Nov 2019, Jim Brain via cctalk wrote: >> >>> Did Hayes modem really do that? I thought most later modems self >>> detected parity and speed and thus would have switched both the comm >>> on the serial port and the data sent to the other side in the same >>> parity (if the terminal was 7E1, the modem would configure as 7E1 and >>> send 7 bit data to the other side. > > No, well maybe a few of the winmodems did. > > Generally all the modems I have (ISA,S100 and external serial) you need > to set the baud rate, parity and word length to match the modem (is it > has at or similar protocal) and also to match the other end (usualy the > same). I remember old dumb modems that just turned 1s and 0s into different frequencies on the audio channel. Think Bell 103 here, and acoustically coupled modems where your fingers do the dialing. No concept of parity in the modem, it was just another bit passed through. Anyway, maybe this is an authoritative reference: http://bitsavers.org/pdf/hayes/Hayes_44-012_Technical_Reference_For_Hayes_Modem_Users_1993.pdf Section 1.4, page 1-53 (PDF page 64 of 160): (begin copy-pasta) Modem commands begin with an AT prefix that gets the modem's attention. The speed and character format at which the DTE sends this prefix tells the modem the speed and format for responding to commands, and at which speed to attempt the connection. (end copy-pasta) Similar language in the July 1991 version of the manual (also on bitsavers in that directory). -Frank McConnell
Re: Question about modems
On Nov 13, 2019, at 11:17 AM, Jim Brain via cctalk wrote: > On 11/13/2019 7:47 AM, Alexandre Souza via cctalk wrote: >> Jim, its a long time I don't use it, but I've used other configurations >> beyond 8N1 and I remember when you put the modem in 7E1 it mirrored the >> configuration of the other side. If you had a vax with a 2400 7E1 port, you >> gotta have in the terminal 2400 7E1 > > Yeah, I agree with your statement, but I am wondering what happened if you > "mismatched" things. Did the AT commands continue to work, but the raw data > was sent out to the other side, or did it silently try to adapt? I used Smartmodem 300’s and 1200’s a lot as a kid dialing up to BBSes in the 80s (also ran a BBS myself). I recall that the modem itself — eg, the AT command interpretation — automatically handled 7E1/8N1/etc., but that’s as far as it went. If I was dialing up a non-8N1 BBS (rare, but they did exist), I had to set my terminal program accordingly. I think I also had to set the speed (although later modems would respond with the speed as an ASCII number in the CONNECT message). Of course, I might be completely misremembering. —John
Re: Question about modems
On 11/13/2019 5:31 AM, Nigel Johnson via cctalk wrote: I actually have an original Hayes 300 modem. Would it be any use if I could set it up for a a test, or would it need another genuine Hayes one to talk to for what you need? I looked at the SmartModem 300. It looks like it completely detected the speed and parity internal to the unit. If you have a manual or a link ot one to validate, I think that would suffice. If it did do that, then it would have reconfigured itself to match the terminal and thus all communication would be in the same format (8N1, 7E1, etc). I did a quick check for an online manual, but my Google-fu is weak today. Jim
Re: Question about modems
On 11/13/2019 7:47 AM, Alexandre Souza via cctalk wrote: Jim, its a long time I don't use it, but I've used other configurations beyond 8N1 and I remember when you put the modem in 7E1 it mirrored the configuration of the other side. If you had a vax with a 2400 7E1 port, you gotta have in the terminal 2400 7E1 Yeah, I agree with your statement, but I am wondering what happened if you "mismatched" things. Did the AT commands continue to work, but the raw data was sent out to the other side, or did it silently try to adapt? Jim
Re: Question about modems
On 11/13/19 9:17 AM, geneb via cctalk wrote: > On Wed, 13 Nov 2019, Jim Brain via cctalk wrote: > >> Did Hayes modem really do that? I thought most later modems self >> detected parity and speed and thus would have switched both the comm >> on the serial port and the data sent to the other side in the same >> parity (if the terminal was 7E1, the modem would configure as 7E1 and >> send 7 bit data to the other side. No, well maybe a few of the winmodems did. Generally all the modems I have (ISA,S100 and external serial) you need to set the baud rate, parity and word length to match the modem (is it has at or similar protocal) and also to match the other end (usualy the same). My experience is fairly recent as WSTD.Cm still support dial-in terminal or SLIP. there are also synchronous modems, different critter. Allison > Jim, I'd try reaching out to Dale Heatherington - he wrote the firmware > for the Smartmodem line. http://www.wa4dsy.com/robot/home/about > > At one point either he or Dennis Hayes had source code to the Hayes > 1200B firmware online, but I can't find it any longer. :( > > g. >
Re: Question about modems
On Wed, 13 Nov 2019, Jim Brain via cctalk wrote: Did Hayes modem really do that? I thought most later modems self detected parity and speed and thus would have switched both the comm on the serial port and the data sent to the other side in the same parity (if the terminal was 7E1, the modem would configure as 7E1 and send 7 bit data to the other side. Jim, I'd try reaching out to Dale Heatherington - he wrote the firmware for the Smartmodem line. http://www.wa4dsy.com/robot/home/about At one point either he or Dennis Hayes had source code to the Hayes 1200B firmware online, but I can't find it any longer. :( g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.diy-cockpits.org/coll - Go Collimated or Go Home. Some people collect things for a hobby. Geeks collect hobbies. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://scarlet.deltasoft.com - Get it _today_!
Re: Question about modems
Jim, its a long time I don't use it, but I've used other configurations beyond 8N1 and I remember when you put the modem in 7E1 it mirrored the configuration of the other side. If you had a vax with a 2400 7E1 port, you gotta have in the terminal 2400 7E1 So, you gotta match the configuration of the other side Hope that helps! Em 13/11/2019 04:25, Jim Brain via cctalk escreveu: I am the author of tcpser, a UNIX/Windows program that emulates a Hayes modem. Some time ago, Chris Osborn (FozzTexx) forked a copy of my project to fix some bugs and he also added in some parity code, which looks to strip parity from the incoming serial connection (in the case that the serial port is set as 8N1 and the computer attached to it sends in 7E1 or similar. I am working to merge in all of his changes into the mainline codebase, but I am unclear on prpper Hayes behavior. His Readme says: https://github.com/FozzTexx/tcpser/commit/5f0e28bb837463e597a1daf9b3c07e56af887b7d "I also made the modem routines automatically detect parity and ignore it in AT commands and print out modem responses in matching parity. Parity is *not* stripped when sending data over the connection, which is how a real modem behaves. This may or may not be what you want. Some servers will expect an 8 bit connection and may not work." Did Hayes modem really do that? I thought most later modems self detected parity and speed and thus would have switched both the comm on the serial port and the data sent to the other side in the same parity (if the terminal was 7E1, the modem would configure as 7E1 and send 7 bit data to the other side. But, maybe real modems did as Chris notes. Anyone have guidance on this? The goal of tcpser is to emulate a Hayes modem as much as possible, but I never really thought about mismatched parity on the RS232 line and how to deal with it. Jim -- ---8<---Corte Aqui---8<--- https://www.tabalabs.com.br https://tabajara-labs.blogspot.com
Re: Question about modems
I actually have an original Hayes 300 modem. Would it be any use if I could set it up for a a test, or would it need another genuine Hayes one to talk to for what you need? cheers, Nigel On 13/11/2019 02:25, Jim Brain via cctalk wrote: I am the author of tcpser, a UNIX/Windows program that emulates a Hayes modem. Some time ago, Chris Osborn (FozzTexx) forked a copy of my project to fix some bugs and he also added in some parity code, which looks to strip parity from the incoming serial connection (in the case that the serial port is set as 8N1 and the computer attached to it sends in 7E1 or similar. I am working to merge in all of his changes into the mainline codebase, but I am unclear on prpper Hayes behavior. His Readme says: https://github.com/FozzTexx/tcpser/commit/5f0e28bb837463e597a1daf9b3c07e56af887b7d "I also made the modem routines automatically detect parity and ignore it in AT commands and print out modem responses in matching parity. Parity is *not* stripped when sending data over the connection, which is how a real modem behaves. This may or may not be what you want. Some servers will expect an 8 bit connection and may not work." Did Hayes modem really do that? I thought most later modems self detected parity and speed and thus would have switched both the comm on the serial port and the data sent to the other side in the same parity (if the terminal was 7E1, the modem would configure as 7E1 and send 7 bit data to the other side. But, maybe real modems did as Chris notes. Anyone have guidance on this? The goal of tcpser is to emulate a Hayes modem as much as possible, but I never really thought about mismatched parity on the RS232 line and how to deal with it. Jim -- Nigel Johnson MSc., MIEEE VE3ID/G4AJQ/VA3MCU Amateur Radio, the origin of the open-source concept! You can reach me by voice on Skype: TILBURY2591 If time travel ever will be possible, it already is. Ask me again yesterday This e-mail is not and cannot, by its nature, be confidential. En route from me to you, it will pass across the public Internet, easily readable by any number of system administrators along the way. Nigel Johnson Please consider the environment when deciding if you really need to print this message
Question about modems
I am the author of tcpser, a UNIX/Windows program that emulates a Hayes modem. Some time ago, Chris Osborn (FozzTexx) forked a copy of my project to fix some bugs and he also added in some parity code, which looks to strip parity from the incoming serial connection (in the case that the serial port is set as 8N1 and the computer attached to it sends in 7E1 or similar. I am working to merge in all of his changes into the mainline codebase, but I am unclear on prpper Hayes behavior. His Readme says: https://github.com/FozzTexx/tcpser/commit/5f0e28bb837463e597a1daf9b3c07e56af887b7d "I also made the modem routines automatically detect parity and ignore it in AT commands and print out modem responses in matching parity. Parity is *not* stripped when sending data over the connection, which is how a real modem behaves. This may or may not be what you want. Some servers will expect an 8 bit connection and may not work." Did Hayes modem really do that? I thought most later modems self detected parity and speed and thus would have switched both the comm on the serial port and the data sent to the other side in the same parity (if the terminal was 7E1, the modem would configure as 7E1 and send 7 bit data to the other side. But, maybe real modems did as Chris notes. Anyone have guidance on this? The goal of tcpser is to emulate a Hayes modem as much as possible, but I never really thought about mismatched parity on the RS232 line and how to deal with it. Jim -- Jim Brain br...@jbrain.com www.jbrain.com
