Superfury, I found this post looking for phonebook solutions to run 688 Attack Sub in multiplayer mode. Reading from your posts it looks like you have done a lot of work on it and the phonebook is not the only issue. For me the nullmodem connection gives me Overrun errors whatever the rxdelay I use and the modem connection is impossible to use without a phonebook feature that translate fake phone numbers in IP addresses. It looks you have found other problems as well. Is that correct? Have you been able to run the multiplayer mode in any way? I am not a programmer so I do not fully understand what you achieved and what you have not achieved.
I am really interested in this topic and happy to do any test if that would help.

Well, using UniPCemu's serial modem and it's special phonebook support(after fixing some bugs in it), I've managed to get the 688 attack sub running. But it seemingly will only run when connecting through the phonebook(one setup for dialing out, another for answering) and even then, only when not using the loopback adapter Windows provides automatically for it's own IP address in the local subnet(so dialling to 127.0.0.1 or the computer's own IP address as known to the local router). When trying the very same thing using the WAN IP address and of course a port forwarding rule in the router itself to redirect said port request to the computer running the emulator makes it connect properly, not receiving weird unchanging values instead of the values that are sent.

So simply said, the only way it works seems to be routing it of of the LAN network and through the real ISP back to the local LAN and the emulator. When using the local LAN IP(of the computer running the emulator) itself or the local loopback(127.0.0.1), Windows 10(at least Windows 10, haven't tested others) will use/enforce it's loopback adapter instead, causing it to receive weird values instead of the proper values that should be received(received TCP data doesn't match sent TCP data using SDL(2)_net). Perhaps a strange bug with the Microsoft Loopback adapter? Or maybe a weird issue with SDL(2)_net(don't know, didn't look at it's source code in detail yet)?

That is very interesting indeed because when I tried it in Dosbox I have ever only tested on 127.0.0.1 with 2 instances of Dosbox open at the same time with the nullmodem connection. I thought if it did not work in such a simple way it would have never worked on a connection with a computer behind a router...
I want to try now in both ways: with UnipCemu (I have to install everything though) and in Dosbox going outside of my local network (but for this I have to resolve port forwarding yet). Again as said I am just learning now about all these things.
Have you ever tried the nullmodem connection in Dosbox running as you said outside of your local LAN?

EmanuelePulciDoria wrote on 2020-04-01, 20:32:

That is very interesting indeed because when I tried it in Dosbox I have ever only tested on 127.0.0.1 with 2 instances of Dosbox open at the same time with the nullmodem connection. I thought if it did not work in such a simple way it would have never worked on a connection with a computer behind a router...
I want to try now in both ways: with UnipCemu (I have to install everything though) and in Dosbox going outside of my local network (but for this I have to resolve port forwarding yet). Again as said I am just learning now about all these things.
Have you ever tried the nullmodem connection in Dosbox running as you said outside of your local LAN?

Well, I was primarily testing with UniPCemu, as using the Visual Studio debugger, I could actually see what bytes were being sent and received(although not both at the same time, due to the weird kind of packets used by 688 attack sub). One client kept sending the same byte eventually and the same kind of behaviour(with 0xAA bytes being received until disconnect) on the receiving side. When doing it over the internet, it immediately connected once the attempt was made, due to valid data being received instead of one unchanging value over and over again(which upon debugging the sender and receiver seperately I found out that what was being sent over the TCP connection wasn't what was received at all. E.g. 0x55 being sent and 0xAA being received, or another data entirely(I remember it sending some kind of 6-byte packet of sorts, with it having transformed into only 0xAA bytes at the receiver's side)).

Edit: OK. What was being sent and received was completely different from what I remember. See: Re: Hayes compatible modem emulation issues?
That explains exactly what happened with the two UniPCemu clients connected using a TCP connection through the Microsoft Loopback Adapter.

Btw, the nullmodem I haven't messed around with, as UniPCemu only supports a normal serial modem(dosbox's case: the modem option) connection instead of nullmodem(which is entitely different) cable emulation.

I tested yesterday the port forwarding and I was able to run Doom2 in multiplayer mode with IPX connection and with the nullmodem feature in Dosbox on 2 different computers at home going both through my local network with 192.168.0.13 as a server and connecting behind the rooter with something like 2.126.41.42 as a server through an open port that I setup on my router. When I tried to use the nullmoded feature repeating the same connections used before there was no way I could connect the 2 players. I am giving up on Dosbox to do this.
I was checking now the necessary downloads for UniPCemu. What is the difference between UniPCemu_win64server and UniPCemu_win64? I imagine I would need the UniPCemu_win64server to try this 688 multiplayer mode. Is that correct?

Just downloaded the server version of your emulator and spent some time to try to understand how to set it up and running it. It is not easy task I would say. I looked at your wiki but it assumes an IT knowledge definitely higher than mine. Do you have any more step by step guide to get it up and running? Any other chat different from this one to discuss this?

Sure: Getting UniPCemu up and running

You can post your questions there.

I've just implemented a proper loopback functionality on the data transfers instead of the instantaneous data transfer that was previously done on the UART (8250A documentation based(From the National Semiconductor PC8250A documentation)). Also added some more bit clearing in the registers to be more accurate.

Now the loopback data that's sent will actually use the normal timing mechanism for transfers, but instead of sending it to the peripheral it's received on the input register(with proper overflow detection)).
There's only one slight difference in receiving with real hardware: the UART won't receive new data while the buffer is still filled(preventing loss of data normally). The only exception is when activating loopback mode to ignore that(which will receive looped back data to a filled buffer). And of course now with loopback mode, the overflow/overrun condition can happen(when receiving data from loopback to a filled Data Holding Register).
And data can be lost(when receiving data and it's starting loopback mode, terminating the transfer mid-way(causing the transmitting data to get lost).

Just adjusted the UART emulation a bit. When it receives a Interrupt Enable Register with bit 1 set(value 02h), when both the transmitter holding and transmitter shift registers are empty and not sending anything to the peripheral, it will trigger a transmitter holding register empty interrupt.

This seems to make Windows 95 properly use the transmitting and receiving, properly sending data over the serial line? Although I've only tested it with the Serial Test program( https://connecttech.com/resource-center/portm … nostic-utility/ ).

Managed to dial out to the server version on Windows 95A, enter credentials, after which it got trouble with the data stream that came in. The console window on Windows 95 started to flood with packet information?

OK. I notice something after cancelling the script that's running. It will hang up. So far so good.
Then it sends "AT", without any carriage return following it, causing the next dial's AT command to append AT to the dial string, followed by carriage return?
So it will execute the command "ATAT", which is incorrect during a dial after a failed or aborted dial?
Or is any occurence of "AT" further down the command being sent being replaced to the start of a new string containing "AT"?
Currently solved the issue by making it send fake backspace characters being received over the serial line to remove anything after AT/at from the command line in both devices.
I've also changed the backspace to be properly echoed to the serial terminal (it wasn't being echoed back at all. Only the space followed by a backspace was).
Edit: The dial script now manages to authenticate itself and start the slip connection. But then Windows 95A seems to complain that the protocol is incorrect? It's received a 0xC0 SLIP END byte? Strange?
Edit: The same happens on Dosbox-SVN Daum I'm using for testing Windows 95 configurations with internet?
Hmmm...
It says (Title bar says "Dial-Up Networking") "The Microsoft Dial-Up Adapter is not configured to work with the current network configuration. Please check your server type and the network configuration in the Control Panel then try the connection again.".
So there's an issue in Windows 9x configuration?
Edit: Yup. I haven't properly installed the TCP/IP protocol inside the Dial-Up Adapter... Whoops!
Also found a slightly related bug when trying the SLIP server based on the current code: the MSR initialization was happening using negative array indexes(of -1) into the register set, which crashed the server(because it's CPU was set to a pre-Pentium CPU). This happened on the non-server version as well, due to obvious reasons.
Shutting down Windows 95 A with the TCP/IP seemed to hang while shutting down(Windows is shutting down screen with blue clouds). Eventually hard resetted UniPCemu.
Edit: It did manage to finish up. It now dialed to the SLIP server(using phonebook entry number 0 by dialing number 0). It managed to connect and not give said message anymore! 😁
Edit: Managed to configure IE to use said connection(it said PPP, but the dial-up connection is set to SLIP?). All that remains is the www testing.

Weird, it cannot find any website through DNS? It ran fine before on Dosbox?

Just tried Dosbox SVN Daum again, but with the Windows 95 image I've used for UniPCemu too. It too seems to fail in it's DNS request of any website? The connection details show it's actually sending and receiving data contiuously, so the data transfer is actually working? Perhaps there's an issue with the SLIP server somehow now?

Edit: No matter what version of Windows or Arachne I try now, somehow it cannot seem to find any web page properly? Either a wrong IP address is resolved or nothing at all. Or it says it's connecting, but fails on retrieving the / path on the server?

Just managed to get internet working somewhat using UniPCemu's Windows 95 RTM install running on Dosbox-SVN and UniPCemu's SLIP server running using the latest commit.

It just seems to have some weird requirement to be running for a little bit(a few minutes) before being able to properly start sending/receiving good packets somehow? UniPCemu's (setup for SLIP in this case) server build just waits a few seconds(0.3 seconds before starting to pass through the slightly filtered and converted pcap data).

Somehow, UniPCemu's Windows 95 version (running in Dosbox connected through a SLIP connection to the computer running UniPCemu's server build) even displays itself inside the Windows 10 network neighbourhood! So that's something that's at last working a little bit?

The dial-up script seems to login and communicate with the internet fine sometimes (if the login worked). But often, the login process seems to halt halfway through? Does that mean that the TCP connection itself is buggy? Or is there an issue with the modem emulation somehow? It's set up for 57600 baud, with FIFO disabled(it doesn't have any FIFO after all).

Testing shows that if it actually manages to connect, it will manage to retrieve non-SSL webpages(like google.com). SSL just being a limitation of Windows 95 itself.
Edit: Hmmm... Interesting enough, I don't always see a modem TX ready IRQ being fired when sending data? It might be an issue with the full/empty transition not triggering properly using some specific timings or state?
It could theoretically happen when the data transmit register loading(by the CPU) and the start clock happen at the same bus clock?

OK. I've just added some extra code that deals with such cases, where the transmit holding register is emptied and the data holding register is filled at the same UART clock as the opposite is done by the software and hardware. So when the THR is filled at the same UART clock it's emptied and sent to the transmitter shift register, the IRQ now properly fires. The same applies to reading the Data Holding Register the very clock it's filled, firing it's IRQ correctly now.

Edit: Disconnnecting and reconnecting 4 times shows that it's using a stable connection to the modem now! 😁
Too bad that Google doesn't seem to render all that well in Windows 95 RTM's IE 4.40.308. It's mostly a black screen with only the blue links at the top readable and some image below that that doesn't display at all.