Question about modems

[Brent Hilpert]

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

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