Internet access from Pocket 386 retro laptop using Wemos D1 ESP8266 serial Wifi adapter

Although there is a USB port on the Pocket 386, I seldom use it for file transfer. The device driver, CH375DOS.SYS, often conflicts with other software and has to be put into a dedicated CONFIG.SYS menu entry, to be loaded only when necessary. The controller only supports certain FAT16 drives up to 2GB. The ability to transfer files from a network file share, no matter how slow, would certainly be more convenient, and I decided to spend the weekend trying to get my Pocket 386 on the network.

The first obvious choice would be to connect a network card through the ISA expansion board. Using a 3Com Etherlink 16 ISA Card, the process was very straight forward. I was able to configure my Samba file share and browse the Internet on my Pocket 386 within just a few hours. The ISA backplane was however bulky and the ISA card would become loose after a while, causing the Pocket 386 to freeze. I soon decided that the ISA idea was just a novelty and unsuitable for long term usage.

The next choice would be a Xircom PE3-10BT Ethernet adapter on the parallel port. On a typical 80386 in nibble mode, the Xircom would be able to reach around 35KB/s transfer speed, more than enough for my use. However, the parallel port on my unit was already attached to a Covox Speech Thing for WAV playback, using SBPLAY’s Digitpak driver (CVXSND.COM). The LPT port was therefore not an option for me.

The only alternative was the serial port, using the Wemos D1 serial Wifi adapter. The Wemos D1 is just an ESP8266 development board with built-in Wifi (2.4GHz only) and some breakout pins (D0.D8, TX, RX, A0, RST, 3.3V, 5V). I got mine from AliExpress for a mere $2. Using a spare MAX3232 RS232 DB9 to TTL adapter from my junk box, I was able to assemble my serial Wifi adapter in less than 5 minutes:

Programming the ESP Slip Router firmware was done using the esptool package available on Ubuntu (sudo apt-get install esptool). Ubuntu did not recognize my ESP8266 as a USB device until I removed the brltty package (sudo apt remove brltty). I then downloaded the OLDNET archive, which contained ETHERSL and MTCP, from the author’s website and ran the following for a COM1 serial port (0x3F8) at 115200bps:

ETHERSL 0x60 4 0x3F8 115200
SET MTCPSLIP=TRUE
SET MTCPCFG=C:\OLDNET\MTCP.CFG

I then connected to the controller via telnet (telnet 192.168.240.1 7777), pressed ALT + E and ALT + N to enter Wifi setup mode, and entered the following commands:

CMD>set ssid 
CMD>set password 
CMD>set use_ap 0
CMD>save
CMD>reset

Take note that you must connect via telnet. Entering the same command through the serial terminal will not configure anything, although the command will still be echoed back.

The D1 then rebooted. After that, I was able to ping Google from my Pocket 386:

HTGET (which comes with MTCP) worked well too, taking around 3 seconds to download 18KB. The speed was around 6-7KB/s, on par with a 56K dial-up modem.

It was time to browse the Internet from my beloved Pocket 386. For this, I chose Minuet (Minnesota Internet Users Essential Tool), developed by the University of Minnesota in the 1990s. The built-in HTTP-only web browser loaded http://www.textfiles.com just fine on its 80×25 Turbo Vision text user interface:

Unfortunately, Minuet’s built-in FTP client was not able to access any of my FTP servers, complaining “Can’t open data connection”. The same error message occurred when I tried with VSFTPD on Ubuntu. However, Minuet was able to connect to the same server on my 80486 using a 3COM ISA card.

This was the corresponding FileZilla log:

It appeared that the LIST command sent after the PORT command failed. On VSFTPD, there was an error in the log, “Illegal PORT command”. Likely, Minuet was attempting to setup an active FTP connection, which would not work due to the NAT created by our serial Wifi adapter. This attempt was rejected by VSFTPD but incorrectly accepted by FileZilla. The last version of Minuet was released in 1994, several years before passive FTP became widely used. Minuet worked fine with other DOS Ethernet hardware such as the Xircom LPT adapter or the 3COM Etherlink ISA card, which created a direct connection to the network without any NAT being involved.

On a whim, I decided to try patching the PORT command into the PASV command, or replacing it with NOP (so that VSFTPD would not complain about illegal port settings), by hex editing MINUET.EXE around offset 0x31A40 and replacing “PORT” with “PASV” or “NOOP”:

This obviously had no chance of working. Although the server log showed that PASV/NOOP was sent, there was more to getting an FTP client to work behind an NAT than just sending PASV or commenting out PORT, and the end result was still a timeout error. The source code for Minuet was never released, so modifying it to support passive FTP would be out of the question. The patch experiment took almost a day, with me also trying various networking setups, only to learn nothing new, except that “quote noop” could be used from the MTCP FTP client to send a NOOP command!

MTCP’s built-in command line FTP client, as well as modern DOS FTP clients with built-in support for passive mode, have no issue connecting via the Wemos D1 SLIP adapter. However, the only FTP client for DOS with a text user interface, visftp, did not work on the Pocket 386. I believe it was compiled to expect a 80387 math co-processor, which the Pocket 386 lacks.

Breadbox Ensemble 4, an MS-DOS office application suite which offered a GUI resembling GEOS (or maybe Windows 95), worked well on the Pocket 386. I experimented with its built in FTP client, File Transfer, but was not able to establish a connection. Only two types of connection were supported, dial-up or ODI. There were no options to set COM port or baud rate for dial-up and in any case, I did not have a dial-up server to connect to. I tried PDETHER to simulate an ODI connection using the ETHERSL packet driver, which either resulted in Breadbox Ensemble crashing due to low conventional memory or just saying “disconnected” right away.

Other built-in software (Text Editor, Word, games) worked well and was much faster than Windows 95 running on the Pocket 386. The games were just enough to be entertaining, and the built-in word processor (Writer) was quite matured for the time. You could perhaps write a memoir on this!

The next objective was to set up file sharing between the Pocket 386 and my Samba server. Microsoft Network Client 3.0, despite its heavy conventional memory usage (around 100KB), was still the best choice as it did not mangle upper case file names (unlike NFS). However, I couldn’t find any NDIS2 driver for the SLIP interface, not even on this page which seems to offer a very comprehensive list of MS-DOS network drivers.  After a lot of searching, I did find PKTNDIS, an experimental NDIS2 packet driver developed as part of the DOSEMU project. When tested on my Pocket 386, PKTNDIS and Microsoft NMEMM loaded successfully but Netbind refused to load, complaining “Unloadable TCP 1.0 not loaded”:

I suspected this was merely because Netbind expected certain values (function return values, flags, exit code) to be set after PKTNDIS had been loaded, failing which it would refuse to load. Without the source code of PKTNDIS, fixing the issue would not be feasible.

Next, I tried to set up NFS file sharing using XFS191 and my simple Windows NFS v2 server. Running XFS.BAT produced “No Redirections” error message after a long delay:

Despite tweaking various settings, I was not able to get XFS191 to work. I suspect that the driver did not expect the machine to be behind an NAT and failed to establish a suitable connection for data transfer.

TSoft’s NFS Client v1.0.2 had no issues with the NAT and was able to mount my NFS shared drive:

Directory listing and files copying worked well to:

However, TSoft’s NFS Client v1.0.2 was not able to make changes to the NFS shared drive emulated by my Windows app. Deleting or renaming a file or directory produced an “access denied” message. Creating a directory froze the machine, while creating a file produced a 0 bytes file, followed by an “access denied” error. I traced the issue back to a slight difference in the RPC payload produced by TSoft, and the format expected by my NFS server app. This caused my NFS server app to ignore most requests to modify the filesystem, making the NFS drive effective read-only.

I didn’t bother patching the code. Instead, I spent 24 EUR on haneWIN NFS Server for Windows, which ran NFS v2 and worked fine with TSoft, supporting both files download and upload. All file names should still be in lower case; otherwise they may not show up properly when accessed via TSoft. Since TSoft only handled NFS v2, WinNFSd, an open source NFS v3 server for Windows, would not have worked at all . Modifying a modern Linux installation to support NFS v2 would introduce security risks and is not recommended.

The Wemos D1 ESP8266 serial Wifi adapter worked fine in Windows too, using Trumpet Winsock 3.0 in SLIP mode. You need not install the Microsoft TCP/IP for Windows 3.1 (which wastes disk space and consumes a lot of memory) or run WINPKT.COM as suggested by the author. Just configure Trumpet to use SLIP with IP 192.168.240.2 and gateway 192.168.240.1 (the D1 IP):

Internet Explorer 3.0 worked fine as well, showing textfiles.com in the photo below. This version is just nice for my 386 as it doesn’t attempt to parse Javascript only to produce tons of error messages and slow down the machine. I disabled images loading to make things even faster, just like how I would configure my browser for Internet access back in the day:

WS_FTP for Windows 3.1 also worked in passive mode:

This is the WS_FTP configuration screen where you can also configure a firewall, which is just a fancy name for a proxy server:

The 16-bit version of Total Commander also worked fine with my FTP server in passive mode:

Of course, passive mode needed to be manually enabled, as early FTP clients defaulted to active mode:

With this, I am finally able to transfer files between my PC and the Pocket 386 without messing around with USB drives. The transfer speed of 7KB/s is not that great, but still sufficient to copy many MS-DOS applications for use on the 386. I also discovered that the IDE controller on the Pocket 386 only supports hard disk up to 8GB. To make full use of the large disk space, I installed System Commander 2000 for dual booting between DOS/Windows 3.1 and Windows 95:

Just in case you are wondering, modern bootloaders such as GRUB4DOS do not work on this machine. These tools will complain that the BIOS does not support E-IDE (a fancy term for LBA) and will automatically reboot the computer. System Commander 2000, designed for machines of the time, works just fine.

You can download a ZIP file containing PKTNDIS, ESP Slip Router and the above OLDNET package here.