Quick update, my main concern was that pin 1 was either floating or grounded when it should have 5v for Vpp. I checked and it indeed does have 5v, and pin 27 (PGM’) has 4v.

The 28 series were meant as drop-in replacements for 27 series EPROMs, so yes, they're pin compatible. We can probably make the assumption that since 64kbit chips work with other peoples NICs of the same type, it should with yours too.

Do you have any chip with faster access time than 200 ns to try with? 200 ns is in the slow end.

Old leaf contact sockets aren't all that reliable, I'd continuity test all connections.

kaputnik wrote on 2023-07-29, 09:38:

The 28 series were meant as drop-in replacements for 27 series EPROMs, so yes, they're pin compatible. We can probably make the assumption that since 64kbit chips work with other peoples NICs of the same type, it should with yours too.

Do you have any chip with faster access time than 200 ns to try with? 200 ns is in the slow end.

Old leaf contact sockets aren't all that reliable, I'd continuity test all connections.

I have just used CheckIt and can see the allocated memory space for the ROM, so the computer can see it. As for faster EPROMs, I don't have any others to my immediate access. It would probably be a couple of weeks before I found others if I've got any faster ones.

BurntOutElectronics wrote on 2023-07-29, 09:46:

kaputnik wrote on 2023-07-29, 09:38:

The 28 series were meant as drop-in replacements for 27 series EPROMs, so yes, they're pin compatible. We can probably make the assumption that since 64kbit chips work with other peoples NICs of the same type, it should with yours too.

Do you have any chip with faster access time than 200 ns to try with? 200 ns is in the slow end.

Old leaf contact sockets aren't all that reliable, I'd continuity test all connections.

I have just used CheckIt and can see the allocated memory space for the ROM, so the computer can see it. As for faster EPROMs, I don't have any others to my immediate access. It would probably be a couple of weeks before I found others if I've got any faster ones.

Ah, then it's at least partly working 😀

You could try dumping the rom/address space a few times to images (can it be done with CheckIt perhaps?) and compare them by content to the image you originally flashed. They should of course be identical. If they are, you probably have the hardware part sorted. If there are random differences, my guess would be bad contact in the socket or timing issues. If there's a pattern to it, you probably have an addressing issue, that could be pinpointed by looking at the specifics of the pattern.

kaputnik wrote on 2023-07-29, 09:38:

Ah, then it's at least partly working 😀

You could try dumping the rom/address space a few times to images (can it be done with CheckIt perhaps?) and compare them by content to the image you originally flashed. They should of course be identical. If they are, you probably have the hardware part sorted. If there are random differences, my guess would be bad contact in the socket or timing issues. If there's a pattern to it, you probably have an addressing issue, that could be pinpointed by looking at the specifics of the pattern.

That’s an idea, there is a possibility that there is a connection issue. Could have even been the 30+ year old ZIF socket used to program it. I could pull it out and verify that isn’t the issue but I have no idea how to dump the rom whilst it’s in the network card.
I don’t think that’s a function CheckIt can perform.

BurntOutElectronics wrote on 2023-07-29, 10:44:

kaputnik wrote on 2023-07-29, 09:38:

Ah, then it's at least partly working 😀

You could try dumping the rom/address space a few times to images (can it be done with CheckIt perhaps?) and compare them by content to the image you originally flashed. They should of course be identical. If they are, you probably have the hardware part sorted. If there are random differences, my guess would be bad contact in the socket or timing issues. If there's a pattern to it, you probably have an addressing issue, that could be pinpointed by looking at the specifics of the pattern.

That’s an idea, there is a possibility that there is a connection issue. Could have even been the 30+ year old ZIF socket used to program it. I could pull it out and verify that isn’t the issue but I have no idea how to dump the rom whilst it’s in the network card.
I don’t think that’s a function CheckIt can perform.

There's universal EEPROM flashing software that can use network cards with option rom socket as host, that might be compatible with your card. Flashrom is one example. Otherwise there should be plenty of ways to dump a specific RAM address range to disk if CheckIt can't do that either.

I'm using the built in function in Total Commander to compare files by content, but there should be standalone apps too.

okay thanks, I'll take a look.
Is there a possibility there is a problem with the ROM image I used? I didn't do a custom configuration, just merely downloaded the newest compiled bin file for 386 computers. I understand I'd have to do a checksum if I customized a bios image, but seeing as I just used a pre-made image there was nothing I had to do other than copy paste it onto the EPROM correct?
I did just remove the EPROM and it verified in the programmer fine so there is no issues there. It has exactly what the contents of the IDE_386.bin file on their website has programmed to it.

Nope. That won't work. You MUST run the configure program as it adds the correct checksum to the image for it to work. The default .bin files which are available DO NOT work out of the box. The documentation needs to be much clearer on this.

You have no idea how many people this has bitten over the years!

megatron-uk wrote on 2023-07-29, 11:32:

Nope. That won't work. You MUST run the configure program as it adds the correct checksum to the image for it to work. The default .bin files which are available DO NOT work out of the box. The documentation needs to be much clearer on this.

You have no idea how many people this has bitten over the years!

Alright, I’m glad I asked haha. I loaded the 386 bin file into their little program, configured it with its auto configuration feature and saved it again. This made the bin file the full 8,192 bytes and I wrote this to a new EPROM. Now everything is working great!
I do feel like a dunce a bit but this was my first time writing to a EPROM.

No need to feel like that. I was in exactly the same position about 15 years ago, and the information still isn't as clear as it needs to be!

megatron-uk wrote on 2023-07-29, 13:16:

No need to feel like that. I was in exactly the same position about 15 years ago, and the information still isn't as clear as it needs to be!

Thank you, glad it is all working now anyway. Currently it's just got an old school Seagate 400MB drive but now I'll migrate to a CF card of larger capacity and partition it out.
To celebrate I just played some wolfenstein 3D and got the Adlib repro blasting which I built a few years ago now.
Not a bad 386sx machine if I do say so myself. It has networking, adlib sound, WD 90c31 video and 8MB of RAM.
I pushed it a bit running the RTM version of Windows 95 but I don't mind the slower speed in windows as I set it to boot straight into dos at startup anyway, and I only to go into windows if I want to run a light program.