VOGONS


First post, by anighosh2026

User metadata
Rank Newbie
Rank
Newbie

Hi everyone,

I've been working on RetroSLIP, a Hayes-compatible SLIP dialer for DOS. It is designed to provide a simple way to establish SLIP networking on DOS systems using a modem/serial connection.

I've been testing it extensively in 86Box with MS-DOS 6.22, using the Standard Hayes-compatible Modem device and COM1. The resulting networking stack is:

RetroSLIP → SLIPPER → mTCP

I've successfully tested the connection with Arachne, including loading modern surviving websites such as Win3x.org.

I also tested MicroWeb. While MicroWeb can establish networking through the same stack, I encountered a Divide overflow while loading a page. This occurred with both COM1 and COM2, so it does not appear to be a COM2-specific problem. At this point I consider this a MicroWeb-related known issue, rather than a confirmed RetroSLIP problem.

Project: https://github.com/aghosh2020/retroslip

I'm posting this here because I thought it might be interesting to people working with DOS networking, vintage PCs, and emulation.

Screenshot

The attachment rslip-current-version.png is no longer available
The attachment 86Box_Zje1LsPxjY.png is no longer available
The attachment 86Box_kzdivk5WTZ.png is no longer available
The attachment arachne-dialer-setup.png is no longer available
The attachment arachne-86box-modem-settings.png is no longer available

Reply 1 of 6, by mbbrutman

User metadata
Rank Oldbie
Rank
Oldbie

A few suggestions for the code:

  • Do not assume that COM1, COM2, COM3 or COM4 are at those addresses. That is often wrong on the PCjr, a fairly common machine. You can provide default values, but allow the user some way to override them.
  • Look up the stricmp function and use it if your compiler supports it, or make your own. (It is a case insensitive string comparison.)
  • Don't program the UART yourself - use the built-in BIOS routines to open the port (set the divisors) and to read and write to it. UART divisor constants might be different depending on the machine - the PCjr is a good example of this. Nothing you are doing is performance sensitive so there is no reason not to use the BIOS.
  • You don't need 32 bit values to compute elapsed times when using BIOS timer ticks. 16 bit values are fine, and probably even 8 bit values work. Also, you should check for wrap-around no matter what size counters you use.
  • Values like PROGRAM_SHORT_NAME that are defined in a #define do not need to be printed with printf. You can do something like this: puts( PROGRAM_SHORT_NAME " text string here..." ); If you really want to do it correctly, use the printf but use argv[0] (the name of the program as given to the command shell) as the argument to printf.
  • Multiple line printfs with static text and be consolidated into a single printf or puts with one string that has embedded new lines. The string can even be split across multiple lines. See https://github.com/mbbrutman/mTCP/blob/dbb161 … /DHCP.CPP#L1039 for an example.

Reply 2 of 6, by jakethompson1

User metadata
Rank l33t
Rank
l33t
mbbrutman wrote on 2026-08-17, 22:17:

Don't program the UART yourself - use the built-in BIOS routines to open the port (set the divisors) and to read and write to it. UART divisor constants might be different depending on the machine - the PCjr is a good example of this. Nothing you are doing is performance sensitive so there is no reason not to use the BIOS.

But the BIOS may require that DSR be asserted to communicate, which can be annoying if your null modem cable doesn't have it wired (eg CD-DTR instead of DSR-DTR or both). I'm more familiar with this issue because it breaks ctty com1.

Reply 3 of 6, by mbbrutman

User metadata
Rank Oldbie
Rank
Oldbie

It seems like that is something that the DOS Mode command should have been able to override.

Anyway, the NULL modem cable looks like a valid exception to the rule. But not using the BIOS means you have to set the divisors yourself. It is probably a good middle ground to use the BIOS to initialize the ports, then use direct hardware writes to adjust the signal lines as needed.

Reply 4 of 6, by Jo22

User metadata
Rank l33t++
Rank
l33t++

Hi, how about using FOSSIL drivers for hardware abstraction?
https://en.wikipedia.org/wiki/FOSSIL

"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel

//My video channel//

Reply 5 of 6, by anighosh2026

User metadata
Rank Newbie
Rank
Newbie

Another interesting compatibility test: RetroSLIP + EtherSLIP on an IBM PCjr (DOS 2.10).

The attachment 86Box_ZiUzexI6QC.png is no longer available

I got an unreleased development version of RetroSLIP working on an emulated IBM PCjr in 86Box.

I followed your suggestion and tried EtherSLIP with RetroSLIP, and it worked on the PCjr.

The PCjr is running IBM PC DOS 2.10, 8088 @ 4.77 MHz, 128 KB RAM, with the serial connection running at 9600 baud.

RetroSLIP supports two serial backends:

BIOS mode uses the BIOS Data Area to determine the COM port address and communicates through BIOS INT 14h. This is the default mode and was used for this PCjr test.

DIRECT UART mode bypasses the BIOS and directly programs the UART registers. It allows higher baud rates, including up to 115200 baud, when the hardware supports it. The UART base address can be explicitly specified with /DIRECT= (or /UART=).

The setup is:

RetroSLIP → Hayes-compatible modem → SLIP → EtherSLIP → mTCP → Internet

RetroSLIP correctly gets the PCjr's COM1 mapping from the BIOS:

COM1 / 02F8h / IRQ3 / 9600 baud

EtherSLIP was then explicitly configured as:

ETHERSL 0x60 3 0x2F8 9600

mTCP successfully reached Google and received 3 out of 4 ICMP replies, with approximately 122–146 ms response times.

So yes — an IBM PCjr running DOS 2.10 at 9600 baud can access the modern Internet through this setup. 😂

RetroSLIP v2.0.0 is still unreleased and under development; this is a compatibility test for now. :')

Reply 6 of 6, by anighosh2026

User metadata
Rank Newbie
Rank
Newbie

Hi everyone! 😀

A little update on RetroSLIP.

RetroSLIP v2.0.0 is now available, with several changes based on the feedback in this thread.

A lot has changed since my earlier compatibility tests. Based on the feedback and suggestions in this thread, I made several changes to the project. I implemented many of the suggestions, while some were considered but ultimately not adopted.

The biggest change in v2.0.0 is that the BIOS INT 14h serial backend is now the default. RetroSLIP reads the COM-port address from the BIOS Data Area instead of assuming the traditional COM1=03F8h / COM2=02F8h mapping.

This turned out to be particularly useful for the IBM PCjr, where the rear RS-232 port can be logically COM1 while using I/O address 02F8h.

I also added an optional DIRECT UART backend for high-speed operation. I tested 56000 input (mapped to 57600 bps) with a 16550-compatible UART on an Intel 486 and an Amstrad PC2086.

The attachment rslip-current-version.png is no longer available

Current compatibility testing in 86Box includes:

- Intel 486 / MS-DOS 6.22
- Amstrad PC2086 / 8086
- IBM PC AT 5170 / 286
- IBM PC 5150 / 8088
- IBM PCjr / 8088

I also tested the networking side with SLIPPER and EtherSLIP together with mTCP. SLIPPER is generally faster in my testing, but EtherSLIP proved useful as a compatibility alternative, especially on the PCjr.

mTCP Internet access, TELNET, Arachne and MicroWeb were also tested on various machines. The results naturally vary depending on the machine, video hardware and driver.

The modem hang-up handling was also improved. In v2.0.0, /H and /HANGUP no longer accept a baud-rate argument. The modem hang-up sequence was tested successfully and returned NO CARRIER after disconnecting.

GitHub release:
https://github.com/AGhosh2020/RetroSLIP/releases/tag/v2.0.0

YouTube demo:
https://www.youtube.com/watch?v=V9WMD1h2ED8

And finally, thank you to everyone here who contributed suggestions, ideas and feedback to the project. This thread was genuinely useful during development.

Thanks again! 😀