Implement handling of the RI pin, mostly useful for IP232 (VICE)

[mrdudz]

This implements additional signalling of the RI pin via IP232. Some obscure Software relies on RI, so this is needed :) Will commit the implementation in VICE right after this. Please merge soon - my current weekend project needs it badly :=)

closes #21 (There are no other lines left)

[mausalimi]

maybe i have done something wrong, but

tcpser -V

now tells me

tcpser: option requires an argument -- V

[mrdudz]

try again :)

[mausalimi]

ok, that works as expected (again).

i haven't done any real testing, i'll leave this to people who actually know how it is supposed to work.

[mrdudz]

i haven't done any real testing, i'll leave this to people who actually know how it is supposed to work.

That said, the patch contains a bit of guesswork - if someone knows better, please tell.

The thing is, i couldn't find accurate information on how the RI pin is supposed to behave exactly, http://www.bitsavers.org/pdf/hayes/Hayes_44-012_Technical_Reference_For_Hayes_Modem_Users_1993.pdf says this:

Ring Indicator (pin 22) gives an indication of a ring being received on the telephone line. This circuit carriers signal information to indicate the modem is receiving call signals (ring/tones). The modem turns on this signal whenever an incoming ring is detected.

While this gives a clear indication of what the "set" condition for RI is, it seems a bit vague on what the "reset" condition might be. My educated (hopefully) guessing went like this:

• i am willing to read the above "The modem turns on this signal whenever an incoming ring is detected" as "while the phones bell is ringing, RI is enabled"
• using the same circuit, that would normally drive the actual bell on a phone, for detecting ringing on a modem, and simply connecting the "bell" signal to a i/o pin, seems the logical and most straightforward thing to do - which means it was probably done :)

Because of this, what the patch does is basically:

• run the "ring" timer twice as fast, which lets us divide the ringing period into an "on" and an "off" period
• when the "on" period starts the "ring" string is sent. also RI goes active
• when the "on" period ends the RI line goes inactive

This assumes that the "bell" would ring every 4 seconds, for 2 seconds. Which is probably not quite right - BUT this should not matter in practise, because the whole timing depends on the local phone system and could be god knows what (should this ever matter in some obscure software, we'll have to make this configurable).

BTW the RI signal could (probably should) be promoted to the real RS232 port too, i think - some obscure software might use it :) Since i don't have a way to test this, i did not look further into it though. It might just work :)

[go4retro]

Hmm, looking at the patch:

• We can't do this: "if(cfg->s[0] == 0 && cfg->rings == (10 * 2)) {", because that messes up the meaning of s[0], and other pieces of SW may use or need this s register. s[0] must contain the number of rings, not the number of half ring periods.
• Is there a reason we need to optionally enable RI? I'd feel better just turning it on all the time
• I'd prefer we hold on -R for RI inversion until it's needed by someone, especially since it's only usable on IP232, and only VICE uses IP232

The rest looks fine and I can merge, but we have to fix the s[0] field being set to 102 default. Maybe set cfg-rings to be cfg->s[0] 2, which may offer the same behavior but preserve the meaning of s[0]

Jim

[mrdudz]

We can't do this: "if(cfg->s[0] == 0 && cfg->rings == (10 * 2)) {", because that messes up the meaning of s[0], and other pieces of SW may use or need this s register. s[0] must contain the number of rings, not the number of half ring periods.

OH! I didn't think of this. I will fix it :)

Is there a reason we need to optionally enable RI? I'd feel better just turning it on all the time

dunno? I felt it was safer :) If you want i will remove the option, of course.

I'd prefer we hold on -R for RI inversion until it's needed by someone, especially since it's only usable on IP232, and only VICE uses IP232

Well, as said before, it could be usable for the real rs232 port too. I only added this for completeness - VICE itself allows to invert it, so its not needed at all. So, if you prefer it that way, i can just remove the option.

The rest looks fine and I can merge, but we have to fix the s[0] field being set to 102 default. Maybe set cfg-rings to be cfg->s[0] 2, which may offer the same behavior but preserve the meaning of s[0]

I will come up with something (and fix the other things)....

edit: there actually IS a reason to completely disable the RI thing - it will (i think, i did not try) stop working with older VICE when it is enabled, which expect the value after the ip232 byte to be 0,1 or 0xff. Not that i am against "just use current version" :)

[mrdudz]

The rest looks fine and I can merge, but we have to fix the s[0] field being set to 102 default. Maybe set cfg-rings to be cfg->s[0] 2, which may offer the same behavior but preserve the meaning of s[0]

I have looked at it again now ... and i am wondering what the problem is :) cfg->s[0] never contains the doubled value, its only cfg->rings that will count twice as fast (and twice as far), and at every place it is used there is either /2 or &1 - looks all fine to me :)

Regarding the -r option... you decide :) (Removing it may result in tcpser being incompatible with older VICE)

[mrdudz]

@go4retro ping? :) lets fix this this weekend... :)

[go4retro]

Hehe, I had to find time to set up a modem to trace out the RI line.

The Hayes modem I used (14400 unit) does indeed set the line once per ring. But, interestingly, it's 1second on, 3 seconds off, for a 4 second period. US RINGs are 6 second period (2s on, 4 off), so not sure what is going on there.

[go4retro]

I'm going to merge into a branch, as there's more work to be done.

[go4retro]

Where do you run the timer twice as fast? I just see things taking twice as long (timer is still set to pop every 4 seconds.)

[mrdudz]

I'm going to merge into a branch, as there's more work to be done.

What then? Please don't overcomplicate it - the timing of the ringing is mostly irrelevant, there is no point in making it exactly the same as it is today in the US with your specific modem.

Where do you run the timer twice as fast?

The timer period is divided into two parts by ANDing with 1. Looks like i somehow forgot to change the actual timer value. (But as said, its irrelevant anyway).

That said, i have no idea how to continue, now that the PR is in a branch... please don't let it rot away

[mrdudz]

The timer period is divided into two parts by ANDing with 1. Looks like i somehow forgot to change the actual timer value. (But as said, its irrelevant anyway).

To make that more clear: the "rings" value is ANDed with 1. The timer still runs at the same speed apparently, i must have forgot about making it twice as fast.