VOGONS


First post, by superfury

User metadata
Rank l33t++
Rank
l33t++

When I start up the slip driver on Arachne(MS-DOS 6.22), the hardware seems to receive and execute commands(emulated Hayes-compatible modem receiving AT commands) correctly, but when sending back the results for some odd reason the dial-up program that's used by Arachne seems to print out each character with spaces between it(e.g. "OK" is received as "O K " on UniPCemu(displayed on the VGA output)). It does so both for the loopback by the modem, thus displaying the modem init string and OK on two rows, all with spaces added. After displaying thesr two results, it simply gives up and errors out after a large delay, returning to the MS-DOS prompt saying it didn't get a valid result(in time). It runs without problems when used on Dosbox, so the program itself should be fine. Is this some weird emulation bug within the CPU, is it somehow doing some weird port i/o to receive the input or is it decoding the message in some incorrect way? Anyone knows anything about this?

Last edited by superfury on 2018-07-27, 00:21. Edited 1 time in total.

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 1 of 12, by superfury

User metadata
Rank l33t++
Rank
l33t++

Just found a little bug in the UART emulation that caused it to send a byte received interrupt for each UART while it's buffer was filled and not emptied yet. So if it would have multiple interrupts to raise, while not being able to satisfy the byte received interrupt, it would keep sending a byte received interrupt each time it sensed that the buffer was still filled, instead of only triggering it once when receiving a byte of data. Sending data doesn't have said effect, since it was already handling it that way.

That fixes the weird spaces(or repetitions when not clearing the Data Holding Register when reading it) that were displayed in MINITERM.

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 2 of 12, by superfury

User metadata
Rank l33t++
Rank
l33t++

Yay! With those latest changes, I can finally use miniterm and connect to the UniPCemu server version(which communicates using a simple protocol and uses a simple SLIP connection). It now at least gets into logging in properly and receiving packet data! 😁

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 3 of 12, by superfury

User metadata
Rank l33t++
Rank
l33t++

Just tried Windows 3.0 with it's mouse support. Having fixed the bug in the UART also seems to have fixed the serial mouse usage in Windows 3.0(which of course uses the UART for it's mouse in this case). 😁

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 4 of 12, by superfury

User metadata
Rank l33t++
Rank
l33t++

Eventually needed to add a little 3 second delay before starting to receive/send TCP/IP packets on the SLIP connection on the server side. Now I can get it into arachne after loading the slip driver without it crashing on it's own slowness(since I currently still need to press ALT-P in order to load the SLIP driver after the CONNECTED message is displayed from the server)...

Now it returns to Arachne, being on-line(reporting a green TCP/IP in the lower-right corner):D

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 5 of 12, by superfury

User metadata
Rank l33t++
Rank
l33t++

Whoops. Another bug found: the receiver was blocking the sending process. So if software were to be trying to send something, the sending of data would never finish because the UART receiver would block the sender from even activating, even if the receiver buffer is full and nothing can be received anyway.

Edit: This fixes the slip8250.com program from hanging up on itself when running after Arachne's miniterm application 😁

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 6 of 12, by superfury

User metadata
Rank l33t++
Rank
l33t++

So, so far I've managed to get them partly working: First executing miniterm to connect to the UniPCemu server executable(which handles login and then starts receiving/sending TCP/IP packets over a SLIP-encoded connection).
https://superfury.itch.io/unipcemu
I then start slip8250 with some parameters ("slip8250.com 0x60 SLIP 3 0x2f8"), which sets up the SLIP connection on UniPCemu's second serial port(the first is used by the serial mouse).

I then configure the MTCP suite with a static IP address(set up the MTCPCFG to the configuration file before calling the MTCP suite programs) as is required for the SLIP connection with the server(commenting the first two lines(which describe the DHCP lease stating time?)), but running any of the MTCP suite programs tells me it cannot initialize the TCP/IP stack(and I remember it also saying something about the server not being able to start(interrupt 0x60? SLIP8250.COM is loaded, so that should be present?)?

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 7 of 12, by superfury

User metadata
Rank l33t++
Rank
l33t++

Hmmm.... "pkttool stats 0x60" gives me a "Divide overflow"?

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 8 of 12, by superfury

User metadata
Rank l33t++
Rank
l33t++

Using slipper instead seems to have more luck. At least the software(pkttool) detects the driver:D

It somehow can't seem to send the packets correctly, or the packet receiving fails for some reason... Hmmmm....

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 9 of 12, by superfury

User metadata
Rank l33t++
Rank
l33t++

Hmmm... Now, running pkttool to view the packets using it's verbose mode gives me errors about some checksum being invalid, containing two increasing numbers as a 16-bit word(0000, 0101, 0202, 0303 etc.) for each error? Anyone? The packet server itself should be running fine, as is proven by Dosbox's Arachne browser and Windows 95 running internet explorer 5.5 and firefox 2.0(non-HTTPS on Windows 95), which load websites without problems?

Just tried configuring Arachne on UniPCemu(while connected using miniterm and slipper), it crashed on me with a stack overflow saving settings(applying the new modem settings trying to work out the autoinput for automatic login)...

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 10 of 12, by superfury

User metadata
Rank l33t++
Rank
l33t++

Is there any simple tool I can use to diagnose the SLIP packet driver? I want to know if it has a problem somewhere? Other than not seeing any packets being sent over the network(when using Windows network diagnostic sniffing), receiving seems to be working without (many) problems.

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 11 of 12, by superfury

User metadata
Rank l33t++
Rank
l33t++

Hmmmmm..... Receiving the packets seems fine, but when I try to run telnet to dial to the PC itself, I see it emit a SLIP packet starting with what seems to be a broadcast address(ff-ff-ff-ff-ff-ff), followed by NULL MAC(00-00-00-00-00-00), followed by 08 and then 06? So if this is a ethernet packet it's sending, it's sending an ARP packet, according to https://en.wikipedia.org/wiki/EtherType ?

Why would a program that uses SLIP send an ARP packet in ethernet format over a SLIP encoding? Slip encoding seems to work, but it doesn't run ethernet packets? Receiving doesn't seem to have any problems?

Edit: Hmmmm..... So since it's sending an IP packet within a Ethernet header as payload of a SLIP(which adds a second ethernet header when sending the packet(removing it when receiving it)), it results in invalid IPv4 packets being sent(and/or received).

Edit: Hmmmm.... Adding the parameter "ether" to the slipper.com parameters doesn't seem to affect it's output. It only makes it worse: no packets are now sent anymore(not even SLIP special identifiers).

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 12 of 12, by superfury

User metadata
Rank l33t++
Rank
l33t++

Hmmmm... With the latest server fixes, Dosbox using Arachne seems to function fine with either "slip" and "ethernetslip" protocols. Both seem to load web pages using Arachne without problem.

Oddly enough, UniPCemu keeps failing to use the server to send/receive packets somehow? So it must actually be some CPU problem(which shows itself using e.g. Arachne)?

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io