Hi, I speak under correction, but I always thought that Win 9x is simply sending Hayes commands (ATI0 .. ATI7) to any serial port it finds.
Windows 3.x originally had no bult-in detection of modems, I believe. It was up to the user application to handle modems.
Perhaps this later changed, not sure. Some versions of 3.11 were bundled with ISDN support, for example.

How does the Internet Explorer 5 for Windows 3.1 detect the modem? I see CTS&DTR being set, then DTR being dropped, finally resetting and aborting detection without anything found?

I don't know, sorry. One possibility to find out would be to use one of these cheap old Creatix modems (or any other model) and record the status LEDs with a camera.
Later on, someone could watch the whole process in a time lapse and see how PC and modem interact with eacht others.
On Windows 3.x, there's no other system service running that possibly could things mess up.. Anyway, that's just one possbility.
The lo-tec one, I suppose. Using a serial port monitoring program/debuger/logger thing would be another one.

Well, the CTS, DTR, RTS and DSR lines are all implemented as is documented(which some extra logic for online modes, but that's a different story altogether).

I even applies the delays now with my latest commits, but it still isn't detected. The delays aren't even utilized by default, as the default for those lines are both CTS and DSR always being on.

So it makes no sense with Windows 3.x' IE5 Install a new modem wizard to toggle both of them, as nothing can be observed anyways. It still will fail detection.

Or is the modem supposed to report something on the data lines(RxD to be exact) when it's toggling the DTR line from off(0) to on(1)?

I see. I'll dig out my 386DX PC within a few days and try to test IE5/WfW with a real serial modem.. 😀

OK. I'll wait for your results.

Btw, what IS the effect of register S25/26? A timeout until results? Or the time a signal doesn't need to change to be acnowledged as being in said state(unchanging status time for acnowledge of the signal's value)?

The hardware handshaking stuff isn't characteristic for Hayes modems only.
I think the "OK" message after certain Hayes commands, like ATZ, tells that the thing connected speaks Hayes.

I've just improved the way the signals from DTR/RTS are handled. Changing RTS has a direct effect on received data being blocked or not(e.g. whether or not the UART sees and receives data from the device on it's TxR line), but all other effects related to them now require the settle time(depending on registers 25 and 26) before their effect is observed and handled by the modem(e.g. by default, DTR won't have an effect until left alone for 5/100th second(RTS in 1/100th second)). Of course, the modem's other settings(by the modem's commands) still affect the reporting of CTS and DSR as documented(by the &D,&S,&C,&R commands documentation).

Since the defaults are &R2&C1&S0&D2, usually detection by observing CTS and DSR based on DTR and RTS is impossible? The only way to know is by actually send AT commands and retrieving results?

One interesting thing about detection only being possible by executing commands, while the software only toggles DTR and RTS, never sending/receiving any data to/from the modem while detection means what? That the software or UART is malfunctioning? Or is the modem supposed to do something undocumented?

superfury wrote:

...TxR line...

what's that?

superfury wrote:

Since the defaults are &R2&C1&S0&D2, usually detection by observing CTS and DSR based on DTR and RTS is impossible? The only way to know is by actually send AT commands and retrieving results?

I think this is the first stage of detection: is there anything actually connected that does hardware handshaking? (which does not need sending/receiving anything)

superfury wrote:

One interesting thing about detection only being possible by executing commands, while the software only toggles DTR and RTS, never sending/receiving any data to/from the modem while detection means what? That the software or UART is malfunctioning? Or is the modem supposed to do something undocumented?

The next stage after determining that something using hw handshake is connected would be the +++AT... (with the +++ delays ofc)
There were also modems with xon/xoff handshaking, usually with the rts/cts and dsr/dtr on the computer bridged or even being ignored, which potentially complicates things. That was the usual way with 20mA lines.

retardware wrote:

what's that? […]
Show full quote

superfury wrote:

...TxR line...

what's that?

superfury wrote:

Since the defaults are &R2&C1&S0&D2, usually detection by observing CTS and DSR based on DTR and RTS is impossible? The only way to know is by actually send AT commands and retrieving results?

I think this is the first stage of detection: is there anything actually connected that does hardware handshaking? (which does not need sending/receiving anything)

superfury wrote:

One interesting thing about detection only being possible by executing commands, while the software only toggles DTR and RTS, never sending/receiving any data to/from the modem while detection means what? That the software or UART is malfunctioning? Or is the modem supposed to do something undocumented?

The next stage after determining that something using hw handshake is connected would be the +++AT... (with the +++ delays ofc)
There were also modems with xon/xoff handshaking, usually with the rts/cts and dsr/dtr on the computer bridged or even being ignored, which potentially complicates things. That was the usual way with 20mA lines.

Whoops. I mean the modems TxD line(or PC's RxD line from the terminal side).

superfury wrote:

OK. I'll wait for your results.

Thanks, I'll try in a few days then.😀
(And please excuse the delay - I'm very busy with real-life right now. 😒 )

I'm terrible sorry for the delay. 😢
This week turned out to be much more stressful than expected.

I'll try on weekend, I guess.
I already dug out my 386 and found my Creatix modem.

If that's too long, please go on without waiting for me.
I'd undertstand that.

No problem. Just a little longer wait won't hurt. I'll eagerly await your results.

Thanks. I'm in the process of tidying up the room. I'll check as soon as I'm able to reach the desk without stumbling over all my stuff.
Edit: Sorry for the delay (again!). The room is tidy now, but we have some worries at home (our pet needs to see the vet).

No problem! Good luck with your pet btw! I'll await results when you've gotten some.

Thanks! I'll try in the next 1-2 days then..

(Btw, turned out the 386DX has 16450 FiFos on the ISA multi-i/o card still..
So I'll try with the Pentium 133 first, perhaps.)

Edit: Modem is a Creatix LC288 FC.
Edit: I uploaded a quick video here: https://youtu.be/67ERJPLaXfc

OK. And what happens on the modem lines when that detection is running? What does the modem status register and sent/received data do during detection?

I'm sorry, I don't know right now. I'll have to check.. Perhaps using some sort of emulator, which logs the serial data comming from/going to the modem ?
I was thinking of some debug version DOSBox, perhaps.

Or I could assemble a piece of hardware to tap the RXD/TXD lines each.
A terminal program on a dedicated PC could then log that data.

So there's three things to know:
- What the outgoing Modem lines do when detecting(Modem Control Register low 4 bits).
- What the incoming Modem Status Register do when detecting(Modem Status register high 4 bits).
- What happens on the TxD(Data sent to the modem)/RxD(Data received from the modem) lines when detecting.

And of course their timings (of line changes?) with said detection, when what happens.

One nice thing is that the Modem Control/Status register can easily be combined into one 'status' by combining the low and high nibbles of them(=(Control&0xF)|(Status&0xF0)), since their other nibbles(High 4 bits of modem control aren't used by the hardware and the low 4 bits of the Modem status is the delta of the high bits anyways).