Recently, I’d repaired an old PC which I’d had since my childhood. The machine in question was a Compaq Portable III, released in 1987, with a stunning 640 KB of RAM and a 286 CPU.
Sporting CGA graphics on a gas-plasma display with a few pleasing shades of orange, the classic whirr of its power supply fan and odd smell of old electronics that wafts out of it always brings back memories of late nights spent playing Flight Simulator 3 on it. Obsolete even for my childhood, my dad had gotten it for me from a computer junkyard for $10 in a time when Windows 95 was the hot new thing.
Definitely a dinosaur, by all things considered… and, until now, it had been completely cut off from the outside world. In its mind, the world stopped in 1987.
In 1987, the optional 1200 baud modem would’ve been the ideal way to connect to the precursors of the internet, but as very few dial-up internet services exist today (and I have broadband internet), that wasn’t a real option. I therefore had only two real options to get the machine connected in a way that would let it talk to another computer, let alone the internet: the COM port, or parallel port.
Traditionally, the parallel port was used to connect to old printers, and while there were a few adapters designed to give network connectivity to a parallel port (such as the very handy and now very expensive Xircom PE-3), most external modems of the era used a serial connection, and this was how most early home computers that lacked internal modems first connected to online networks.
The great thing about serial is the simplicity: the protocol, known as RS-232, hasn’t really changed much since it was invented in the 60’s. It works by sending a single bit at a time over a cable, represented by a high or low voltage that the other device detects. Unfortunately, most computers today lack the traditional 9-pin serial connector, which is a shame, because it would look great sticking out the side of an iPad.
Doing some research online, I found this article, which seemed pretty promising:
In order to carry out the steps, I’d need a way to connect the serial port on the Compaq to my Windows 10 desktop machine. There was no physical serial port on my W10 machine, naturally, but luckily there are USB adapters to fix this, one of which below I ordered off Amazon for about $15.
I also ordered a null-modem cable (Startech brand) for about $7 off Amazon, as the male serial port wouldn’t connect to the male port on the back of the Compaq. A null-modem cable (named because there’s no modem in the cable) works by simply crossing the TX (transmission pin) of one computer’s serial port to the RX (receive pin) of the other computer’s and vice-versa. This lets two PC’s talk to each other directly.
After I plugged the USB cable into the W10 machine, it recognized it immediately as a Prolific PL2302 serial adapter and installed the appropriate driver automatically. Moments later I had a new COM port show up in my Windows device manager.
First order of business was making sure that the serial ports between the two computers could actually communicate now. As far as I knew, the serial port in the Compaq had never been used before. Using a program called Simple Serial Port Monitor on the Windows machine and SERMON.EXE on the 286, I could send characters back and forth over the respective COM ports (once I had gotten the bit rate settings correct (115200 bps, 8 data bits, no parity bits, and 1 stop bit, also known as the 8N1 setting).
Setting up the Point-to-Point connection
Now that the computers could talk to each other, I set up the point to point (also known as PPP) connection between the machines. While I followed the guide, I realized that starting with Windows Vista, Microsoft had placed the “Incoming Connections” setup under the “File” menu in the network adapters screen, rather than being part of the setup wizard. No big deal. I actually managed to get the connection active in Windows, but even with the settings from the matejhorvat.si link above, I couldn’t get a stable connection, nor could I reliably ping computers on either my network on on the internet.
So, more research online. It seemed like the most of the leads I’d found online for PPP connections had people using Linux to act as the host between the internet and the other device. The below link in particular was particularily helpful, coming from the mTCP set of applications for DOS, which would prove useful later:
While I lacked a Linux machine, I decided to try something different and use a virtual machine (the software being Virtualbox), and so installed a lightweight version of Ubuntu called Lubuntu.
After telling Virtualbox to use the computer’s physical COM port as the Linux computer’s COM port, as well as creating a bridged network connection so that the virtual machine appeared on my LAN network as an actual machine (both necessary steps for proper internet connectivity to the DOS machine), I entered the commands on the Linux virtual machine’s terminal to initiate the PPP link:
pppd ttyS0 115200 local lock passive proxyarp defaultroute noauth mtu 576 192.168.0.161:192.168.0.162
echo 1 > /proc/sys/net/ipv4/ip_forward
The first command starts the ppp daemon (essentially a mini-server) on the Linux machine, with the host (the Linux box) having a local ip address of 192.168.0.161, and the remote host (the DOS computer) getting assigned an address of 192.168.0.162. I found that running both commands as root and adding noauth to the first command was the only way to get it running for me properly. I used an MTU of 576 (which was recommended for such slow connections) in order to avoid packet fragmentation problems, as the MTCP documentation advised.Typing ifconfig -a into the terminal verified that it was waiting for a connection:
Now that I had it the Linux machine running, I used the DOS PPP packet driver known as epppd.exe, which simulated an ethernet interface on a DOS machine by sending ethernet packets over a serial port. Running it on the 286, using the following command, gave me the results I finally desired:
epppd com1 115200 local
After deciding to use the mTCP software suite for DOS and writing in the appropriate configuration settings in the mtcp.cfg file, I was ready to go on the information superhighway! Luckily, mTCP provided ping tools, a telnet client, an FTP client (and server!) as well as a host of other useful tools for browsing the internet (or at least the DOS equivalent of it) in today’s world.
The Online Experience
The first thing I tried using was the ping command, to see if I could access Google’s famous DNS server, 18.104.22.168:
It was a success! The response time was about right for the slow serial connection, which was far slower than even a 14.4K modem in practice.
The first place to start was where many had their first online experiences: Online BBS systems, accessed by Telnet! Telnet is a simple text protocol that a great deal of early terminal systems used to talk to each other. You could check the weather, news, talk online to others, and most importantly, play games!
Of course, I also had to try mTCP’s FTP client. I could connect locally to both the computers on my LAN network, and any FTP servers on the internet itself. This meant I had a way to transfer files back and forth from the 286 without having to use a floppy drive! Definitely handy in a pinch, even if the transfer speed was quite slow.
I also had to see what the internet itself looked like. While text-based browsers for DOS computers definitely exist, most require a 386 (or higher) PC, rendering those with a 286 and below rather limited in options. Luckily, there was DOSLynx 0.43b, a slightly updated port of the original DOSlynx text browser from the 90's.
With the browser installed on the computer and a bit of setup to point the software to the correct packet vector of 0x60, I could go on actual web pages!
It worked rather well for sites that were mainly text-based, rendering links, lists, alt tags in images, and even input forms. Unfortunately, it had no ability to access any SSL sites (those starting with https://). This unfortunate limitation was because, even though DOSLynx 0.43b technically can do SSL, my 286 CPU, a 16 bit device, couldn’t properly handle the SSL certificates with any real progress before the connection would time out. Thus, HTTPS sites were inaccessible, and the growing number of websites going to full SSL-only status limited options for web browsing this way in 2019.
Overall, I had a lot of fun and many sleepless nights trying to get this old machine online. The BBS and Telnet sites still running (a suprising number of them, with new ones springing up all the time) probably worked the best, and actually allowed me to enjoy myself online. I also managed to get online using the mTCP IRC client, and I was actually chatting to other people online over my 286, which brought me a real magical feeling (and realized how much we take modern electronic communications for granted).
I also learned a lot about the importance of accessibility, in a rather ironic fashion. Making sure a website is laid out correctly, with proper headings, alt text in images and sensible anchor tags, was key to letting users navigate your site with ease. Sure, very few, if any, will be using DOS to look at your site, but a great many may have accessibility needs that require something simpler like a text-based browser, and it’s important to remember that no matter how advanced the internet gets, ease of access to information should always be the first priority when you embark on any web development project.
I’ll still be looking into more online activities I can do with my little 286 now that I have it connected, as well as ways to get it online more easily without a Linux virtual machine. A raspberry pi could serve as a small ‘modem’, perhaps. A good project, for another time.
Until then, I can always play some Commander Keen.