Hmm... I left the system running while I wrote the post above, and I just rebooted to check something and now it hangs completely after the Promise banner. And I noticed the 286 chip is very hot, nearly too hot to touch! 😟 Do these typically run that hot? It's a 286, so I assume not...

I've also just thought, I have no idea whether the RAM in the card is any good. There are two SIMMs, I think 2MB. I can probably throw them in the motherboard and test them there.

Edit: No, 8MB total! Two sticks each with 8x NEC 424100-80 4Mx1.

Perhaps your roms have bit rot? Or maybe you have the older roms that don't work with drives larger than 512MB ?

Can you burn a new copy of the roms from here? https://theretroweb.com/expansioncards/s/promise-dc4030vl-1

The best roms I've found work with drives up to 8.4GB.

I'd also check the decoupling capacitors. They are labeled "TCx" near the edge connector.

There's a possibility I can dump the ROMs and check their contents. I don't have a programmer, but I have done so in the past using an Arduino on a breadboard. Tedious to set up, though. I don't have a way to write new ROMs though, because of lack of programmer and spare chips.

The three ROMs on the board are labelled "P43205-E", "P43205-O", and "P43204-X". All with copyright date of 1993. I presume E and O stand for even and odd. I guess the E and O are the ROMs for the embedded 286 CPU, and the X is the BIOS ROM? If the numeric part of the label is anything to go by regarding version number, then they are the same as the "2.20 Bios / 2.3 Firmware" on TRW, which says that is for "CHS 8GB".

What about the capacitors should I be checking? They're all present and in good condition. I assume they're tantalums, so I measured for shorts with a meter, and all okay; about 2.3kΩ across each of them. It was a bit of a pain to measure the ones in-between the SIMM slots! You have to poke one probe in through the gap in the side.

I'm currently running a RAM test using CheckIt on the 2 SIMMs from the card now installed alongside 2 other 4MB modules in my motherboard. A quick test passed successfully, and I expect the full test to also pass. Edit: full memory test also passed, so the RAM is confirmed good.

I found this YouTube video which shows a DC4030VL-2 in action, and I see that on boot it should show the Promise banner, then report the ROM versions, then do a cache memory check, and will prompt to press F2 to enter the setup. I assume the -1 is similar? Edit: I opened the BIOS ROM image I downloaded from TRW in a hex editor, and I can see text strings in there that confirm that I should be seeing similar boot messages on the -1. But when the card was initially "working" I didn't see anything except the Promise banner. 😞

One other thing that occurred to me about the RAM is that I have no idea what kind of RAM configuration the card supports. The EIDE4030plus manual I found says that for that it supports 256K, 1MB, or 4MB modules, parity or non-parity, 70ns or faster. Anyone know what the RAM requirements are for the DC4030VL-1? The RAM that was in this card is 4MB modules, so that's fine... but it is 80ns. I have some 1MB 70ns modules I could try.

HwAoRrDk wrote on 2026-09-25, 08:14:

The three ROMs on the board are labelled "P43205-E", "P43205-O", and "P43204-X". All with copyright date of 1993. I presume E and O stand for even and odd. I guess the E and O are the ROMs for the embedded 286 CPU, and the X is the BIOS ROM? If the numeric part of the label is anything to go by regarding version number, then they are the same as the "2.20 Bios / 2.3 Firmware" on TRW, which says that is for "CHS 8GB".

What about the capacitors should I be checking? They're all present and in good condition. I assume they're tantalums, so I measured for shorts with a meter, and all okay; about 2.3kΩ across each of them. It was a bit of a pain to measure the ones in-between the SIMM slots! You have to poke one probe in through the gap in the side.

Sounds like you got the newest roms that we've found (my card is pictured on TRW btw). They should work with your drives. And yes, you are interpreting the E, O, and X labels correctly.

You did the appropriate checks for the capacitors. Make sure they didn't pop off or explode. The issues with the decoupling caps is more of an DC4030VL-2 & EIDE4030Plus kind of thing, and the symptoms are different. But it was worth a check.

Valid ram configs are shown in this document: https://theretroweb.com/expansioncard/documen … ation/20681.pdf

Sort of sounds like the BIOS kicks in but then has trouble taking to the card, yes? Sorry about the basic questions here, but it's always best to ask-- Did you check JP3 to make sure you have a valid IRQ setting? What bus speed are you trying to run this at? What other VLB cards do you have in your system? Have you tried different VLB sockets?

douglar wrote on 2026-09-25, 13:07:

(my card is pictured on TRW btw)

Hah, yes, I noticed that. 😀 The stickers on my ROMs are exactly the same as yours.

douglar wrote on 2026-09-25, 13:07:

Valid ram configs are shown in this document: https://theretroweb.com/expansioncard/documen … ation/20681.pdf

Whoops, don't know how I missed the second page on that! That was what I had been referring to for the jumper settings. 🤦

So it seems 8MB consisting of 2x 4MB is supported, but one thing I note on that list is that all are specified as "x9", i.e. parity RAM. The modules that were on the card are non-parity - they only have 8 chips. The other 1MB 70ns modules I have that I mentioned earlier are parity RAM, so I suppose I should try those instead.

douglar wrote on 2026-09-25, 13:07:

Sort of sounds like the BIOS kicks in but then has trouble taking to the card, yes? Sorry about the basic questions here, but it's always best to ask-- Did you check JP3 to make sure you have a valid IRQ setting? What bus speed are you trying to run this at? What other VLB cards do you have in your system? Have you tried different VLB sockets?

Yep, that seems to be what happens. I initially got only the Promise banner, and then after about 10 seconds a "Get configuration failed" message, and then the system booted normally. Now, it just hangs the system after the Promise banner.

I have JP3 set with only the middle position installed; that is, open-closed-open, which corresponds to IRQ14. And that was what it was already set to, I didn't change it. I've checked and IRQ14 is free.

The system is a 486SX-25. I have the VLB motherboard settings currently set to: "<= 33MHz" and "o WS". JP4 on the card is correspondingly set closed for 'normal' bus speed. I suppose I could try the 1 WS motherboard setting.

I don't have any other VLB cards installed. I will try other VLB sockets.

I tried a few things:

1. Put 4x 1MB 70ns parity RAM modules in the card instead of the 2x 4MB that were originally in the card.
2. Tried the card in all the VLB slots. On this board, two are marked "Slave" and one "Master/Slave" (I forget what the difference is).
3. Changed the motherboard jumper for VLB wait states to 1 (from 0).

None of these had any effect.

But it's at least back to allowing the system to boot, with floppy controller functional, but still just giving a "Get configuration failed" message about 16 seconds (I timed it) after showing the Promise banner.

I'm still concerned that the 286 chip on the board is getting worryingly hot. 🔥 It feels about as hot as the 486 gets. None of the other chips on the board are getting warm.

Actually discovered in my stash I have a spare Intel 286 12MHz PLCC chip that is literally identical! No memory of where or when I got it, or what condition it's in. Shame the DC4030VL-1 doesn't have a socket for the 286, otherwise I could've tried a swap!

If the firmware is on a socketed IC, I would start removing it and seeing if the card works in windows (obviously the card is not bootable this way, you need to boot from another controller)

I took a shot in the dark and decided to throw the BIOS ROM binary (that I downloaded from TRW) at Gemini AI and ask it to work out under what circumstances the "Get Configuration Failed" messages would be shown.

It said that a cause for that message to be shown is a configuration EEPROM read/communication failure. There is indeed a 93C46N 8-pin serial 1024-bit EEPROM on the board. I presume configured drive settings, etc. are stored there. Another cause is that if the code only thinks the contents of the EEPROM are corrupt (checksum mismatch), but then it also shows an "EEPROM Check Sum Error" message, which I have not seen, so that's not the cause. So just the "Get Configuration Failed" message would almost certainly be a read failure.

Such a failure also apparently ties in with the timeout period I observed:

[…]
Show full quote

1. The Read Sequence: The ROM attempts to issue a standard 93C46 READ instruction (Start bit 1, Opcode 10, followed by a 6-bit or 7-bit memory address).
2. Clocking & Polling: The BIOS toggles the CLK line high and low in a software loop to drive bits out on DI and sample the DO pin.
3. The 17-Second Timeout: Before or during the read, the ROM checks if the chip is ready or if valid bits are shifting back on the DO line. Because the serial protocol relies on software delay loops, a dead chip or floating DO line forces the x86 code into a massive timeout countdown loop before it finally sets the AX error flag and moves on.

And also apparently explains why I never see the "Press F2..." message, etc:

When the 93C46 read times out, the sub-routine returns a failure flag to the main POST sequence: […]
Show full quote

When the 93C46 read times out, the sub-routine returns a failure flag to the main POST sequence:

• Normal Path (EEPROM Read Succeeds):
  1. Print DriveCache DC-4030VL: Cache Memory Test... and run the SIMM test.
  2. Query onboard PDC20330 controller chipsets and print Primary Controller: Firmware V... / Secondary Controller: Firmware V....
  3. Hook INT 13h interrupts.
  4. Display Press F2 to Enter Cache Setup Utility....
• Error Path (EEPROM Read Fails):
  1. The routine jumps straight to the failure handler.
  2. It prints Get Configuration Failed !.
  3. Crucially, it skips the cache test, controller status queries, and interactive prompt entirely. The BIOS assumes that without valid EEPROM parameters, attempting to initialize the cache RAM or interact with the local controllers using custom setup profiles could lead to data corruption or hardware locks.
  4. It forces hardcoded safety defaults, finishes minimal BIOS initialization, and hands control back to the motherboard BIOS so the machine can still attempt to boot (e.g., from floppy).

Sooooo... maybe my entire problem is a duff 93C46 EEPROM? It is a DIP-8 chip, which I suppose could be de-soldered, a socket added, and a brand new chip sourced and put in place. 🤷

I might get the oscilloscope out and try and look at the signals on the pins of the EEPROM and see what it's doing to confirm if this is all a valid hypothesis.

That’s the eeprom that holds the board configuration, yes? Maybe that’s the issue. But before you mess with that, I’d check to verify that the contents of "P43205-E", "P43205-O", and "P43204-X" still match what’s posted on TRW. That seems a little more likely and is a much easier task to complete.

Yes, I probably will check the ROMs as well.

By the way, what type are they? I don't want to have to remove the stickers if I can help it. They're all 16KB, 28-pin DIP, so that would make them... 27C128?

HwAoRrDk wrote on 2026-09-26, 11:43:

Yes, I probably will check the ROMs as well.

By the way, what type are they? I don't want to have to remove the stickers if I can help it. They're all 16KB, 28-pin DIP, so that would make them... 27C128?

I have seen them with 27C128 chips or with 27C256 chips that have the prom image burned twice. Pin A14 probably is grounded or held high.

I scoped the pins on the 93C46 EEPROM. It's doing... something.

The only activity I'm seeing is literally immediately after coming out of reset, where something does some brief communication with the chip, and nothing else happens after that.

From reading the datasheet of the 93C46, I interpret the above as a 'READ' command on DI with an address of 0x0, and a 16-bit data word output on DO of 001000010010 or 0x212.

This activity would not seem to be the doing of the card's BIOS ROM, because - correct me if I'm wrong - the BIOS ROM doesn't execute at that point in time. It'll only execute once the system BIOS has executed, initialised, and scanned for option ROMs, right?

AI seems to think that the PDC20130A chip is the one doing this, to bootstrap its own internal configuration:

Bit-fields within this initial configuration word tell the PDC20130A which I/O port range to map its control registers to (e.g., Primary 0x1F0, Secondary 0x170, or alternate non-standard ranges like 0x1E0 / 0x160).

I don't know where it's getting this from, because as far as I'm aware there aren't any datasheets for these Promise chips. It thinks if this data is incorrect, the PDC20130A will initialise itself incorrectly, and the BIOS ROM won't be able to talk to it, so can't read the config EEPROM. It thinks to fix things I should try and erase the 93C46 EEPROM... 😬 I'm not so sure about that. Why the hell would the controller chip work that way? It creates a chicken-and-egg scenario. How are you expected to change a blank/corrupt config when the blank/corrupt config is what's stopping the whole thing working?

Think I'll forget about the 93C46 for now, as that chip seems to be working. I'll try checking the code ROMs.

douglar wrote on 2026-09-26, 13:33:

I have seen them with 27C128 chips or with 27C256 chips that have the prom image burned twice. Pin A14 probably is grounded or held high.

How do I tell the difference? On a 27C128, pin 27 is /PGM, and on a 27C256 it's A14. For the former, I assume that pin will always be held high. So I guess check if p27 is connected to VCC (direct or with pull-up) and just read it out like that if so?

I figured out the ROMs. Removing the ROM chips from their sockets revealed that "27256" is written on the silkscreen under the X ROM socket. 😀

The X ROM has A14/PGM connected to VCC. So that is only using the upper half of the X ROM? And could be substituted with a 27C128.

The E and O ROMs have A14 both connected together with Q7 output pin of the 74LS373 latch underneath the O ROM; the Dx input pins of both the 74LS373s under the E/O ROMs are connected to some of the address pins of the 286. That means A14 is capable of being driven by the 286 CPU, so these must be 27C256s, even if one half of the capacity isn't used.

BTW, pins on the chips all look great - nice and shiny. No corrosion on the sockets either.

I dumped the ROMs using an Arduino. Turns out my chips are actually all 27C128s, because if I connected pin A14 up as an address line, the ROMs read as blank (all zeros); I had to connect A14 to VCC to get data out. So that pin must be PGM, not A14, which means they are 27C128.

Verified against files download from TRW (SHA-1 checksums):

1a31c9942fd1a0c693236dfaa74485ff01fcb0faf *p43205-e.BIN
2a31c9942fd1a0c693236dfaa74485ff01fcb0faf *Mine P43205-E.bin
395b82978e328704e60dd6a32c3499388882632d7 *p43205-o.BIN
495b82978e328704e60dd6a32c3499388882632d7 *Mine P43205-O.bin
53563936130b1bdf991bc422edfee272f63da0923 *p43204-x.BIN
63563936130b1bdf991bc422edfee272f63da0923 *Mine P43204-X.bin

So my ROMs are perfectly fine.

HwAoRrDk wrote on 2026-09-26, 19:32:

My ROMs are perfectly fine.

Ok, thatks great!

But that also sucks because all of the solutions from this point forward are probably harder and beyond my skill level. I hope you can figure it out. I’ll watch your progress closely.

HwAoRrDk wrote on 2026-09-24, 18:25:

then very briefly shows a message I can't fully read that says something like "Get configuration failed"

for the next time record the screen with a cellphone in 60-120 fps

HwAoRrDk wrote on 2026-09-26, 14:45:

I scoped the pins on the 93C46 EEPROM. It's doing... something.
...
Think I'll forget about the 93C46 for now, as that chip seems to be working. I'll try checking the code ROMs.

Im also dubious about that secret promise bootstrapping, but it could totally be 286 reading that eeprom and failing to initialize Promise chip. Since you already started I would throw 286 rom dumps at AI too.

rasz_pl wrote on Yesterday, 08:39:

for the next time record the screen with a cellphone in 60-120 fps

Having seen it so many times now, I'm 99.9% sure the message is exactly what I first thought it was: "Get Configuration Failed !", and only that. No need for high-tech shenanigans. 😀

rasz_pl wrote on Yesterday, 08:39:

Im also dubious about that secret promise bootstrapping, but it could totally be 286 reading that eeprom and failing to initialize Promise chip. Since you already started I would throw 286 rom dumps at AI too.

Me too. But I'm not so sure that the 286 has anything whatsoever to do with the 93C46 EEPROM. I was trying to trace out where the data-out (DO) pin of the EEPROM goes, and it doesn't appear to go anywhere near the 286:

1. DO first goes through a 74LS125 tri-state buffer. The OE is controlled by a 74LS32 OR-gate, of which one input comes from the PDC20230B IDE controller chip. I couldn't find where the other OR input comes from. But given OE is active-low, it means it's effectively an AND-gate, so the PDC20230B and something else have to agree to allow the 93C46 to talk.
2. After that, DO goes to a 74LS245 tri-state buffer, pin A8. But the corresponding B8 output goes to pin D15 on the secondary IDE connector?! 🤨 I assume this is a red herring, and the IDE data bus is essentially just the conduit for whatever is communicating with the EEPROM.