OK. Having setup the COM0COM app as on a real serial port, although the lines from the second port are received from the second port.

I now make the following connections in COM0COM:
Primary ports:
DTR-DSR
RTS-CTS
DCD&RI - inverted of ON (so always off, as they are done by the second port inputs instead)
Control ports:
DTR-DCD
RTS-RI
DSR&CTS - inverted of ON (same case as the above ports, but on the control ports instead, as they're on the primary port).

I see the DCD&RI signals on the control port and the remainder of the signals on the primary port working as UniPCemu intends.

The RI goes high and low during rings, DCD properly indicates the signal as programmed with AT&C0 and AT&C1.
Then, on the primary port, DSR and CTS reflect the DTR and RTS from the emulated modem correctly.

So that at least confirms that the signals produced by UniPCemu are correct. It's just not able to set them on the very same port using COM0COM.

It makes me wonder, though...

Do the RTS, CTS, DTR, DSR, DCD and RI all use the same TTL and polarities? So can you connect RTS to RI and DTR to DCD and make DTR being set to 1 setting DCD to 1? And the for raising RTS to raise RI (Making the modem spew out a "RING" message if setup to. Lowering it instead triggers the IRQ or autoanswer(ATS0=1) if programmed to)?

Anyone out there who wants to try and use UniPCemu's dual serial port dial-up modem configuration (using the modified nullmodem cable split into two serial port headers to connect to the two serial ports for UniPCemu to provide the device on)?
It can easily be combined with another UniPCemu instance in dial-up server mode, providing a serial dial-up modem with SLIP/PPP internet support when combined in that way (it can also call other IP addresses (using 9 digits for the IP address optionally, or a single digit for quickdialing on the phonebook) and hostnames).

The wirings for that should be pretty simple (looking at https://en.wikipedia.org/wiki/Null_modem#/med … odem_Wiring.png), using one nullmodem cable to take apart, one extra header for the second port (to connect the two wires to), andtwo extra (for for a full version twice that) simple electrinic wires for the full modem support (supporting the seperated RI and CD signals).

Simply remove the CD connection from the DSR connections. Then connect the second port DTR header's wire to the opposite side's wire and header on the CD pin (on the nullmodem cable's end), replacing CD's input with DTR from the second port header. Finally, do the same for the RI on the nullmodem end to connect to the RTS pin on the second port header.

Finally, just put the plugs into their ports, with the nullmodem's end into the device you want the modem to appear on and the remaining unmodified end of the nullmodem cable onto the primary port UniPCemu's server uses (the one mentioned in the directserial line in the configuration file). Then the other newly created header goes into the port setup in the directserialctl line.

This makes the UniPCemu report it's modem UART COM interface on the newly created header of the nullmodem cable.
Although the modem can of course be replaced by other Dosbox-compatible nullmodem configuration if wanted.

That's of course if you're wanting to modify a working nullmodem cable with two extra cables and a bit of soldering skills to create the split cable (if requiring the DCD and RI lines to be supported and seperated from DSR(for RI) or supported at all (for RI)), as afaik said split cables don't exist yet.

Anyone wanting to give it a try?

Just adjusted the little image of the wiring of the cables from Wikipedia to show how UniPCemu assumes it is (although one of the two bottom's wires might be ommitted and grounded instead).

UniPCemu is then connected to one of the top serial ports as the primary port, on the same side the bottom one for the control port. The device that connects to UniPCemu is then connecting using the top port on the opposite side.

Said setup could even be used to provide a virtual DCE-DCE connection using 4 DTE driving ports.
Although I don't know if the opposite (unused) port at the bottom of the diagram should be grounded in the case only 3 are used (either top left, bottom left (for UniPCemu emulating the DCE) and top right(for the DTE connecting to UniPCemu) or top right, bottom right (for UniPCemu) and top left(for the DTE connecting to UniPCemu)).
Although full DCE-DCE communication using 4 DTE ports could also be done when implemented as in the image.

OK. A slight revision of the cable, with signal ground (pin 5) connected on all four devices:

I'm confused about this, is the goal here to work around a limitation in the number of control lines in com0com or 9-pin ports so you can more fully emulate a modem's behaviour?

doshea wrote on 2022-08-07, 00:40:

I'm confused about this, is the goal here to work around a limitation in the number of control lines in com0com or 9-pin ports so you can more fully emulate a modem's behaviour?

Both, actually.
I use COM0COM to test the configuration for physical serial cables.
UniPCemu ofc supports both using a second COM port(for the cable mentioned in earlier posts) and using COM0COM with it's OUT1/OUT2 being wired up for the second COM port lines instead (mostly for testing) by setting the control port to "::OUT12::" or "::OUT21::" (without quotes).

Perhaps it's better to simply remove the bottom-left connector and connect it's DTR output to the right-side DTR as well? And the same with RTS?
So bottom-right connector changes to:
DTR(bottom-right)->CD(top-left) and CD(top-right)
RTS(bottom-right)->RI(top-left) and RI(top-right)
And the bottom-left connector removed (leaving cables between the top connectors and some wires to the bottom-right connector only)?

Or, starting out with a normal null-modem cable, just connect RI pin(top-left) to a breakout connector(bottom-right) RTS pin instead, the same with top-left CD pin (requiring disconnecting from DSR's signal first) to the breakout connector DTR pin.
The top two connectors are from the normal full-handshake nullmodem cable, with all but those two pins unmodified.

The latest commits of UniPCemu allow for adding a suffix of "::COM0COM::" (w/o quotes) to force COM0COM detection on a port. In that way, it can be used with ::OUT12:: for example and provide a full Hayes modem on a serial port using the older signed COM0COM drivers, allowing for it to be used outside of unsafe boot on Windows 10/11.
Verified it working with Windows 10 connecting and dialing the UniPCemu server using PPP and get it's local network connectivity.
FTP on such a network runs fine. SMB 1.0 with Windows 95<->10 not yet, due to unknown packet issues (or it preferring the real physical LAN network instead).