When I rry it in UniPCemu running Windows 95 RTM, I see Windows executing an "AT\r" command(echoed back exactly the same without modification to the UART read buffer), after which the modem immediately adds "\r\nOK\r\n", which is also read by the OS serial driver?

But then it does something weird: it sets bit 4 of the Modem Control Register, activating the serial loopback instead? Then it reports that the modem isn't responding(it was connecting using the dial-up connection connect dialog)? What happens to the UART's buffer for receiving, sending and status in that case?

I see Windiws, immediately after completing to receive the "AT\r" command, it sets the loopback mode to on(this clears any status for send/receive fifo's to become empty), then proceeds to send a 0x00 byte to the loopback, receiving it on the 2f8 register(of course, the line status bits behave accordingly). Then I see it lifting the loopback, restoring normal operation. Then it sets rts, but not dtr? Immediately after, it gives up?

Hmmm... Weird... After fixing the DSR to always be 1 when AT&S0(the default) is in effect, Windows 95 doesn't even try to execute any commands anymore?

Hmm... With the latest CPU and modem/UART fixes, Arachne at least seems to find the Google website?
Edit: Hmmm... Stack overflow happened running Arachne...

Whoops! Just found a bug in the serial modem's DSR line that made it force the CTS line high instead when the force of DSR is supposed to be in effect(due to &S0).

Edit: Running Modemd70(from http://www.elhvb.com/webhq/download/index.htm) with the different CTS/RTS and DTR/DSR line settings(entered using the manual command line function) now confirms that the line is properly operating(at least from the hardware perspective and the modemd tool reporting it toggling all(CTS/RTS/DTR/DSR) correctly). 😁

Hmmm... Looking at what Windows 95's portmon is reporting while trying to connect to some other location(using the dial-up modem), it enables RTS&DTR(correct), then the portmon.exe reports it's trying again, setting DTR(but it's setting RTS after clearing it only), then proceeding to do nothing and eventually clearing RTS&DTR? The modem hasn't processed a single command yet in Windows 95 RTM?

Hmmm... Running Miniterm(from Arachne) goes fine until I try to type a special shift-character(e.g. @). At that point, miniterm stops properly sending the input?

Edit: That seems to be the case with any and all non-alphanumeric characters?
Edit: Perhaps not even that... It looks like some timeout is preventing input into miniterm somehow(a few seconds)?

Hmmm... Simply removing credentials from the server(for a minimal 4-character('slip')+carriage return input), it seems to properly open the vogons.org website! 😁

There also was a setup problem that was incorrectly setting up the UART port for the Arachne web browser(3e8 for COM2).
So far 2000 bytes of the index page read...
Edit: Also, I'm now running it from real mode instead of with EMS memory(or perhaps with XMS memory instead). Perhaps that's part of the issue?
Edit: I do see some dial-up communication being done by the app(according to Windows' perfmon(monitoring traffic to/from the SLIP server and UniPCemu's normal version(that's running under Visual Studio)).

Hmmm... Trying again with mouse drivers installed makes it connect to vogons.org(it says it's connecting to vogons.org, requesting '/'), but immediately after that... Stack overflow! 😖 Something's definitely wrong with the CPU(or mouse.com drivers combination of it? Perhaps corrupted drivers?)

Just found a little 'issue' when running 688 attack sub's modem multiplayer. I noticed that the application sent a "ATDn" command instead of the usual "ATDTn" command when dialing. After having fixed that, I can at least confirm that the two instances of UniPCemu are actually connected(the dialing from the originating modem seems to be successfull) on the TCP layer. The Windows Performance Monitor at least confirms that the two are connected on their respective(same from the perspective of the application itself) TCP ports. So the dialling out itself seems to have succeeded at least.

The other side might not have seen that it's being called somehow? Perhaps there's an issue there?

Hmmm... I see something strange on the autoanswer side: it's sending an ATS0=1 command(enabling autoanswer) followed by an empty command(just 0xD byte), which means according to documentation(in this case Dosbox's softmodem.cpp): turn autoanswer off? Shouldn't this actually be on the "AT\r" command instead?

Hmmm... I see the modems transferring values 0x55/0xAA, then both sending and receiving 0x16?

Although there's a 256-byte buffer in between(both at the sending and receiving side)?

Hmmm... Weird... When I look at Perfmon in Windows, I only see a very slow transfer between the two entities(or perhaps just very little throughput by the app, but I doubt that).

It identifies the connection as only transferring about 20 bytes/second somehow?

Just found a little 'bug' in the modem's ringing algorithm. When it starts ringing the virtual telephone line(acting like someone's calling us, while in actuality it's already accepted, but not acnowledged for the software transferring, except the buffers not working yet), it sets the ring indicator to value 3 and gives off the 'RING' message through the text input of the UART. But after 3 seconds of ringing, it switches said ring signal from 3 to 1(still waiting for a new ring, preparing to do another ring after 3 more seconds etc.). Basically the bit 0 is the current request bit(requesting a client for the server), while bit 1 is the current ringing signal itself.

Now, of course, when it clears bit 2 after each 3 second ring, it does it's usual stuff (increase a ring counter if possible, comparing said counter(register #1) against the ring autoanswer value(register #0) and if it's overflowing the autoanswer value, answers the call). Nothing wrong with that.
But when it autoanswers the call, it clears the ringing status to 0(thus not ringing anymore) and makes the rest of the modem aware of the connection(recording of the connection ID as active, marking the modem as being connected to some other computer(for the purposes of hanging up(ATH), online status(ATO) and software reset stuff(ATZ)). That will also have effect on the signal lines themselves.

Now there was a problem with the ring indicator line as specified by the Modem to the UART. As is known, it raises said line when it's supposed to be ringing(UART does nothing with that) and lowers it when it's finished ringing(also when autoanswering, which happens at that point). The UART has some simple bit toggle checking in it that (like the raising and lowering delta bits of the CTS, DSR and DCD) also checks the ring line(but only sets the 'delta' bit when the line goes from high(ringing) to low(not ringing anymore)). But the Modem only raises said line when it's ringing(having an incoming call, in other words bit 0 is set) and not ringing at the moment(it's in the delay between rings). So the modem was essentially doing the reverse of what the UART was doing, but on the actual ringing line itself. So, it starts out to ring(ring line lowered), then stops ringing(which might have raised the line), but never raises the ring line because it's auto-answering the call(and clearing the whole 2-bit value). So in that case, the ring line never gets raised and the software didn't even know that it was being called at some point(through the UART modem delta status and the current status).
Luckily, the fix is easy: instead of making the 2-bit value (val&1)&(~((val&2)>>1)), make it (val&1)&((val&2)>>1), thus giving the correct ring indicator(thus the software sees the ring line raised, then lowered together with the ring delta being set, the carrier going high(and it's delta too) and of course the modem being connected to the other side due to the autoanswer functionality).

Didn't notice that bug until I looked at the ring indicator line itself... Whoops! No idea if the software uses it for anything, though.

And by accident, while debugging the weird case were the clients of the modem couldn't connect anymore, I noticed that there was a little leftover code (from earlier changes) in the SDL_Net wrapper that caused the client TCP connection to be made 'unused' (thus making it unavailable for deallocation) instead of leaving it alone(and let the modem's automatic disconnect properly disconnect and cleanup properly do it's job). And because it's made 'unused' status from 1(Client-based connection) or 2(Server-based connection), the automatic disconnect would fail, thus never properly clean up all required SDL_Net TCP data(TCP socket, socket set, various allocation information) and most importantly, never release the connection resource, thus never allowing the TCP server to start back up when it needs to(thus never accepting any new connections when this happens with only one connection available(which is the case in a normal modem build)). So once said disconnect happens as was detected by the TCP Send wrapper, it would leave almost all data structures and said allocations permanently allocated(which need reallocation later for new connections and deallocations during cleanup), block the server from ever starting up again(due to the one single TCP client resource incorrectly having been released and the server not starting up anymore due to there being no clients slots free to use anyways(in the case of the serial modem it's only once resource anyways(either connected or unused and running as server for one connection at most))). The server stops serving when that one connection is being used and starts serving once it's fully released and freed. So in that way it's handling it like a normal modem(and connections from other applications or networks won't connect while the modem is connected to something else and can't serve them anyways). Otherwise it would accept the connections(making the other side think it's connected) then immediately having to disconnect due to there being no resources or ways to properly handle them(a modem can only handle one connection at a time after all). Of course for the SLIP server it's a whole different case, as it can handle up to 256 clients at the same time(and thus has a lot more leeway on that). Although, once all those connections are taken, it will do the same as the modem with one connection taken: shut down the TCP server component until a connection is available again(and released). And said check is a simple counter. It counts down towards zero when allocations are made, and the opposite when they're freed. And when it becomes zero, the server is stopped. And when it becomes one again(due to a client disconnecting or being disconnected by error or other method(e.g. wrong identification of the client during the login process)) the server is started back up again.
So with connections available, the server is running and can be connected to, but without connections available the server is temporarily stopped until there's connections available again.

Hmmm... Just a little question: does 688 attack sub connect properly to another session of Dosbox running in autoanswer mode with the same app? Is there perhaps an issue with the app itself there?

I don't know if Dosbox supports aliasing(I don't think it does), but UniPCemu does using it's phonebook support(the phonebook being supported normally). So when a program dials ATDSn, ATDn (quick dial), ATDTn or ATDPn (single digit numbers dialed are redirected to the phonebook entries) it actually starts calling said phonebook entry. The phonebook entry is taken as input to the ATDT<phonebookentry> command instead, making a connection to said address. So if phonebook entry 0 contains the localhost with or without the used port(defaulting to the emulators own port of course. The port being seperated by a ':'-character), executing ATDT0, ATDP0, ATD0 or ATDS0 will all make it dial the localhost like with a ATDT command.

Perhaps the 688 attack sub game itself is somehow damaged inside the disk image? Or it can't handle the modem's 256-byte buffering of I/O? Although, looking at the modem's buffers shows that the I/O is pretty much done without the buffer ever getting more filled than 1 byte(according to the head, tail and filled status of the buffer), so it should be immediately sended one byte as it's sent at a time(so before sending a second byte, the first byte is already sent by the modem to the other side over the TCP connection).

Hmmm... Even after all the issues fixed, Windows 95 RTM still refuses to send any proper commands to the actual modem? Hardware autodetection(serial PnP) still works, but Windows still aborts when sending the "ATZ." command(which is probably "ATZ\r"), which never seems to reach the modem?

After fixing some little bugs with the Hayes-compatible modem commands(commands defaulting End-Of-String to become it's 0-parameter instead(e.g. "E\0" becoming "E0" etc.), support for spaces in the command string(although ignored when processing the command(stripping before processing)), allowing spaces when sending the dialing string(and allowing them to be removed like other characters), special dial character scanning to include only the dial string(e.g. ATS0DT0 not including the 'S0' part when scanning the dial string('0' in this case) for the special dial characters(';', ',' and '!' in this case), I managed to make one UniPCemu session call the other, shoot each 'other'(me and me2) a bit, until killing the client side off 🤣

That confirms that at least basic communication is working without issues! 😁

Hmmm... Since 688 attack sub has modem sending issues, does that mean there's an issue with the Compaq Deskpro 386 BIOS serial I/O routines or 808x CPU emulation running the app in some way?

Hmmm... I'm running it on the Pentium(which has known non-V86 mode issues with real mode)... Perhaps it's fixed on the 808x emulation or 80486 emulation? I'll try it on such a chip later.

Edit: Eventually, after pressing ESC, it gives a "SetupGameMaster aborted" error and dropping DTR, +++, finally "AT Z H0" hangup command is sent to the modem(nothing is said about any response)?