If you have a mystery ISA network card with no recognizable brand name on it, chances are it’s an NE2000 clone of some sort. These cards were common in their day, but difficult to get working if you don’t have the original disks and manual. Here are some tips for using an NE2000 network card in DOS without them.
And these tips are helpful for using other cards in DOS as well, especially what you can do with the card once you have it up and running.
Why the NE2000?
I was mainly interested in the NE2000 because I had a couple of old NE2000 clones and decided to try to get them working before I bought something else. If you have to buy a card, I recommend buying an Intel 8/16 LAN Adapter because the utility disks are easy to find so you don’t have to fumble through the configuration, and you can use them in XT or AT-class machines.
But if you have NE2000s laying around, you might as well try to put them to use before buying something.
NE2000 clones can use the same packet driver. But the plug-and-play setup for one card doesn’t necessarily work with another one, and figuring out who made your card so you can find a setup disk is more trouble than just working through the possibilities.
NE2000s weren’t the best cards. Novell designed the card using the minimum viable product model, hoping to get cheap NICs on the market to help it sell its cash cow, Netware. It then spun off manufacturing and was happy when other companies cloned it. While not great, they’re fine for light use.
Early NE2000s didn’t have an RJ-45 connector. Make sure the card you plan to use does, since you’ll need that connector to connect up to a modern switch. A modern gigabit switch will happily talk at 10 megabits with older cards. The BNC and DB-15 connectors are obsolete. You can get an adapter to convert the DB-15 to RJ-45, but it will cost more than a nice ISA network card.
While it’s possible to create a network boot disk with a Microsoft network client, this client won’t work with modern Windows operating systems without a lot of tweaking. It’s a lot of trouble and it decreases your security, so I don’t recommend it. The DOS networking client was never all that easy to configure anyway, even when the OS on the other end was cooperative.
Instead, I recommend using a packet driver and Mike Brutman’s MTCP. This implements basic TCP/IP commands like ftp and ping, as well as a DHCP client. What a lot of retro enthusiasts recommend is standing up an FTP server on your DOS machine, then you can use an FTP client or command-line FTP on your modern computer to connect to your DOS machine and upload whatever you want to it. At 10 megabits it’s not quick, but it’s much more convenient than shuffling disks or memory cards around. And given it’s a DOS machine, you’re not going to be schlepping hundreds of megabytes of data over the connection most of the time.
Isn’t FTP insecure?
Yes, FTP is insecure because it doesn’t encrypt any of the data. Don’t forward port 21 of your DOS machine from your router to open it up to the outside world. But it’s OK for this use case. It’s on your home network, which is closed off from the rest of the world. You’re only using it for a few minutes at a time, and you’re not transmitting sensitive data to and from it.
Setting up MTCP
Download Brutman’s MTCP and copy it to your DOS machine somehow (a Gotek floppy emulator can help), along with the NE2000 packet driver, which you can download from here. If you wish, you can load them into a DOS boot disk if that makes things easier. I like to put all of the files in a directory named C:\NET.
When you unzip MTCP, you’ll find two sample configuration files in the samples directory, one for the MTCP package as a whole and the other for the FTP server. The example config worked well enough for me, mostly. You need to open the file and scroll down to the line that specifies the FTP passwords file, uncomment that line, and direct it to your file.
I started with the example file, and deleted all the entries except the brutman entry. I changed the username and password to something for myself.
You’ll need to set an environment variable pointing at your configuration file. I set mine in autoexec.bat. The command is set mtcpcfg=c:\net\mtcpcfg.txt .
Setting up your packet driver
First, you need to get your packet driver working. I copied the driver into the same directory as MTCP. In my case, the command ne2000.com 0x60 11 0x300 did the trick. If you’re lucky, you can get away with the simpler ne2000.com 0x60 and omit the interrupt and memory address parameters.
The NE2000 can only reside at five possible addresses in memory: 0x280, ox300, 0x320, 0x340, or 0x360. Most of these addresses are likely to be free of conflict. They can live at almost any interrupt, except they probably won’t be at 0, 1, 2, 6, 13, or 14. They’re most likely to be on IRQ 9, 10 or 11, followed by 3, 4, 5, and 7.
DOS doesn’t share interrupts well, but if you’re only using one device at a time you can get away with it. So if it conflicts with another device you’ll be OK as long as you’re not trying to use both at the same time. That said, if you’re bootstrapping a DOS machine and want to be safe, remove the sound card and disable the serial and parallel ports if you can to reduce the chances of conflict.
Brute-forcing your NE2000 in DOS
Looping through the commands is a hassle but you don’t have to loop through every possible combination. You can try the command ne2000.com 0x60 and see if the driver can figure out where the card is. It will tell you the address and interrupt it thinks it’s using, and if the MAC address is something other than all 00 or all FF, it probably got the address right. I found the driver had a harder time getting the interrupt right than the address.
I recommend you use the value 0x60 for the first parameter, as Brutman’s configuration file uses that by default.
To test connectivity, run the command dhcp in the MTCP directory. If it pulls an IP address, you got the interrupt right. If it times out, you got the interrupt wrong. Issue the command ne2000 -u and then try it again with a different interrupt. As I said earlier, 9, 10, and 11 are the most likely candidates, followed by 3, 4, 5, and 7. The command ne2000 0x60 9 0x300 is an example.
If you successfully pull an IP address, try pinging yahoo.com or google.com. If it works, you know TCP/IP is working right.
Setting up FTP
To set up FTP, edit your mtcpcfg.txt file. Scroll to about line 80, look for a line referencing ftppass.txt, and delete the # character at the front of the line and adjust the path if needed. Then create the file ftppass.txt in the same directory, which really only needs to be one line for your own use:
username password [none] [any] all
Just substitute the username and password you want to use for username and password.
Setting up autoexec.bat
I added the following lines to my autoexec.bat file to enable networking. You’ll have to adjust the second line to match your card:
lh c:\net\ne2000.com 0x60 11 0x300
Running your FTP server
Once you have your network card working and pull an IP address, transferring files to your DOS PC becomes easy. On your DOS PC, run the command ftpsvr. Note the IP address.
Then on your modern computer, load an FTP client. You can use command-line FTP if you’re comfortable with that, or download a GUI FTP client. Open a connection to your DOS PC’s IP address, then log in with your username and password. Navigate the directory structure, make sure you’re transferring files in binary mode (most clients default to binary but not all), and then transfer files to your heart’s content.
You can also run the FTP server on one DOS machine and the MTCP FTP client from another DOS machine. As long as you’re fine with using command-line FTP (see below for a primer), it’s useful for copying your favorite utilities from one DOS machine to another without having to mess with floppies.
Command line FTP commands
There are several commands but you really only need a few.
- cd to change directories
- binary to change to binary transfer mode. Always issue this command first!
- get to download
- put to upload
- bye to log out
- ? to get a list of allowed commands