Pull the sound card and try the NIC setup again. There may be more issues to that sound card you had issues with than you actually know after reading the Sound card issue thread: Addonics A151-910 YMF718-S Card Resource Conflicts
Seriously: I would try to get the NIC working and then try any other sound card as a test.

Oops, should've mentioned that in the initial post, that was one of the first things I did. After that was when I switched it to all three different slots, no dice.

I have also tried this NIC in a completely different computer, and am getting the same EEPROM Vital Data test failure. I'm guessing this means the EEPROM is somehow bad? I've made sure to clean the contacts on the card so that dirt isn't interfering, I just don't understand how it up and died one day.

I've seen this happen several times to people on vcfed with the same card. Just about every time it is an addressing conflict.

Interesting, thanks for the information.
I'm also using an Etherlink III card, but was lucky so far.
Does disabling Shadow Memory help, maybe?

wiretap wrote on 2020-06-28, 18:44:

I've seen this happen several times to people on vcfed with the same card. Just about every time it is an addressing conflict.

But I tried every single address on the other computer- I can't believe that every single address on that computer is being used when I can add other cards to the system (ie. modems) which use their own addresses and work just fine. I somehow doubt that address 300h is taken on two entirely different computers as well.

It's very frustrating because if it is an address conflict, it's one that seemingly can't be solved. That's the trouble I've been having, if it is an address conflict, how can I solve it if no addresses I can change it to allow the card to work?

Jo22 wrote on 2020-06-28, 18:51:

Interesting, thanks for the information.
I'm also using an Etherlink III card, but was lucky so far.
Does disabling Shadow Memory help, maybe?

Like a BIOS shadow? I can try it, I'll start with the video BIOS shadowing first which I enabled a little while back to get a small performance boost out of the system, and see if that helps.

[EDIT]

I got that confused with the video shadowing capabilities on the 486, my bad. The P200 doesn't allow you to change any shadowing settings at all. Would enabling shared ISA memory size/reserved I/O spaces help? If so, I have 4 different I/O space reserved sections, with no way to differentiate which of the slots or cards the memory reserved settings go to.

Hi all. I suffered this problem recently and I managed to solve it... sort of xD so here is what I found out and what I did.

Apparently, I think the configuration data and the “vital data” are saved together in the same EEPROM chip. In my case, my card went nuts and configured itself into EISA mode. To get it back to ISA, I started to mess with the EEPROM until I bricked the card. Eventually, I figured out that I had deleted the entire EEPROM (including the vital data) and I managed to restore it back to normal as follows:

1) First, I got the correct EEPROM values from another card. To do so, I configured it into “service mode” connecting two test pads of the card. (I have attached the picture). When this is performed, the values of the EEPROM are ignored on boot and loaded some default values. The card then is found in 0x200 address and it’s EEPROM can be read and patched.

2) The utility to get the EEPROM from the working card and load it again to the faulty one is for Linux (3c5x9setup.c). The data of the working card is as follows:

13c5x9setup.c:v1.00 6/19/2000 Donald Becker (becker@scyld.com)
2 http://www.scyld.com/diag/index.html
3 No interrupt sources are pending.
43c5x9 found at 0x200.
5 Indication enable is 0000, interrupt enable is 0000.
6 EEPROM contents:
7    0020 afd4 5185 9550 b4c8 0036 4a41 6d50
8    0010 a000 0020 afd4 5186 bf10 0000 b920
9    2083 0000 0000 0004 0001 0000 0000 ed05
10    6d50 9550 5185 afd4 0a0b 1010 1982 3300
11    6f43 206d 4333 3035 4239 4520 6874 7265
12    694c 6b6e 4920 4949 5015 506d 0295 411c
13    80d0 22f7 9ea8 0147 0210 03e0 1010 3779
14    0000 0000 0000 0000 0000 0000 0000 0000
15  Model number 3c509 version 5, base I/O 0x300, IRQ 10, 10baseT port.
16  3Com Node Address 00:20:AF:D4:51:85 (used as a unique ID only).
17  OEM Station address 00:20:AF:D4:51:85 (used as the ethernet address).
18  Manufacture date (MM/DD/YY) 6/8/90, division 6, product AJ.
19  Options: force full duplex, enable linkbeat.
20  The computed checksum matches the stored checksum of b91f.

3) The utility is able to modify only the 32 first bytes (first two lines) so I edited it to be able to flash the rest of the EEPROM data detected by the application (128 bytes). To do so, I modified the 3c5x9setup.c (3C3.c) when invoking the –E parameter (emergency rewrite).

4) I changed the working card by the faulty one, compiled the modified tool and reflashed the EEPROM and voilà! It worked. The card operates normally again but the testing tool keeps failing when checking the EEPROM. This can be because there might be something I did it was not correctly. For instance, I modified the vaule of the MAC in the EEPROM in two places, so both cards can work in the same network without problems, but I did not modify the checksums accordingly. Anyhow, the card is working again, so I think it is ok.

I have attached some pictures to illustrate the explanation and the Linux tool (original and modified)