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

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

On 11/13/19 9:17 AM, geneb via cctalk wrote: 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).

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

On 11/14/2019 11:05 PM, Brent Hilpert via cctalk wrote: thinking from root premises.) 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...

On 2019-Nov-14, at 9:30 PM, Jim Brain via cctalk wrote: ... 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<CR>", 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.

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.

On 11/15/2019 3:12 AM, Brent Hilpert via cctalk wrote: 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.

MCU should set receive line coding to 8,N,1. When in command mode, you don't care about parity

On 13/11/2019 13:36, Chuck Guzis via cctalk wrote: According to the diagram of the Smartmodem there is no UART, the 1488s and 1489s go directly to the Z80. 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!

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.

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.

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

On 11/13/19 1:31 PM, Fred Cisin via cctalk wrote: 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?

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

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.

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?

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?

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.