I thought I would have a crack at disassembling and reverse-engineering the BIOS ROM myself, in case AI is just making things up. I don't really know what I'm doing, or much about x86 assembly, but I know how to use Ghidra well enough to be dangerous. 😜

Trying to track down the source of the "Get Configuration Failed !" message leads me to some code in the 'main' function (i.e. where the JMP at the start of the ROM goes to) at offset 0x27e6. It calls a function and depending on the result (carry flag), either continues or prints the error message and skips to near the end of 'main'.

This function seems to do some kind of testing/resetting/initialisation of the primary and secondary IDE controllers. It starts off with the primary IDE controller and then the secondary in turn. For each:

1. Tests if the controller is present by reading Sector Count and Sector Number registers. If they both read as 0xFF, the controller is not present and it skips to step 5.
2. Calls another function which has several other sub function calls, none of which I have worked out yet, but one does appear to have a lengthy Status register 'busy' flag timeout loop (655,360 iterations!). This function doesn't seem to have a success/fail return value.
3. Reads the Status register; if 'busy' skip to step 5.
4. Calls yet another function which is very complicated, with many sub-function calls. The success/fail return value of this function is used. If fails, skip to step 5.
5. Loads a 16-bit word from... somewhere ( MOV BX,word ptr [DI + 0xe]), mask off bits 10..8 (0-7 value), subtracts 2, and shifts right by 7 bits. Then uses this value as a lookup index into a table of ROM base addresses (6 entries, C800h through DC00h) and compares that lookup value to the current code segment (CS). It breaks out if there is a match.
6. Calls BIOS INT 13h, issuing disk system reset for first fixed disk (argument 0x80).

If there was no breaking out, sets carry for 'failure' and returns.

I'm wondering whether this mysterious 16-bit read is somehow reading from the 93C46 EEPROM - which is a 16-bit word ROM. If it's returning a junk value, I suppose it will indeed fail out. But anyway, even if it is, I think this could be a red herring. And maybe my problem is the "test if the controller is present" step. Problem is, I don't understand the architecture of the card enough to know if the controllers are directly on the bus, or they communicate via the 286.

from LLM description eeprom readout would be way earlier

HwAoRrDk wrote on Yesterday, 14:17:

And maybe my problem is the "test if the controller is present" step.

Like I said first test if the controller itself works, with bios removed/disabled, then, if the answer is NO, you have bigger problems than BIOS, if the answer is YES, you can dedicate to the BIOS itself being more or less sure of not wasting your time.

The Solutor wrote on Yesterday, 14:30:

Like I said first test if the controller itself works, with bios removed/disabled, then, if the answer is NO, you have bigger problems than BIOS, if the answer is YES, you can dedicate to the BIOS itself being more or less sure of not wasting your time.

If I'm running the card at the same time as another disk controller, would I need to adjust the IRQ jumper JP3 to something else (e.g. 15)? The other disk controller card I have doesn't have selectable IRQ for IDE, just enabled/disabled jumper, so I assume it is fixed at IRQ 14. I guess I'll also need to disable the floppy controller with jumper JP2.

And what exactly do you mean by "see if the card works in windows" then? And are we talking Windows 3.1 or 95?

I can't really do such a thing at the moment, though. 🙁 Like I explained earlier, I only have a CF-to-IDE adapter handy, but I can't use that to boot a Windows install because the connector on it is keyed with a plugged pin and the IDE connector on my other disk controller card doesn't have a missing pin.

HwAoRrDk wrote on Yesterday, 17:25:

If I'm running the card at the same time as another disk controller, would I need to adjust the IRQ jumper JP3 to something else (e.g. 15)? The other disk controller card I have doesn't have selectable IRQ for IDE, just enabled/disabled jumper, so I assume it is fixed at IRQ 14. I guess I'll also need to disable the floppy controller with jumper JP2.

Probably. I suggest to have an os up and running with whatever you have working , then insert the promise card with nothing connected to it, just to solve any conflict with resources/ IRQ, whatever, install the drivers for the Promise card (assuming it is detected and working)

If the above goes smoothly, connect an HDD to the card, and boot the system to see if it's actually detected and if it works properly.

In case of positive outcome you can assume the controller is working OK, and your problems are (as you guessed) all related to the BIOS/Eprom/NVRAM/ whatever may me involved there.

In case of negative outcome, likely your problem comes from something else, and the BIOS problems are just a consequences of that.

Most plain controllers work just requiring just the drivers in Windows/Linux/Modern OSes. And the BIOS extension is there just to make the card bootable, and to make the connected HDDs visible to DOS.

RAID controllers may be different, in that case their firmware is used to assemble groups of physical HDDs in various way in logical HDDs. In that case the BIOS is needed to do the initial configuration, when starting from scratch, and sometimes may be needed even when the RAID is already configured. (here the kilometrages varies wildly, depending the HW taken in account)

And what exactly do you mean by "see if the card works in windows" then? And are we talking Windows 3.1 or 95?

First question already answered above, for the second one both should be working, but for sure W95 with it's device manager and detection routines would be surely more practical/effective.

I can't really do such a thing at the moment, though. 🙁 Like I explained earlier, I only have a CF-to-IDE adapter handy, but I can't use that to boot a Windows install because the connector on it is keyed with a plugged pin and the IDE connector on my other disk controller card doesn't have a missing pin.

So you have to fix the bootability status of an HDD controller, but no HDDs to test? 😮

Not exactly the best scenario.

Whatever the usual Plop bootloader may help to boot from a device which isn't seen by the bios as bootable, but this way start to be complicate...

P.S. never break pins, cut traces with a blade instead, in the first case there isn't a simple way to go back, the second one implies just a small drop of solder.

I had an idea last night: remove the BIOS ROM (so that nothing gets initialised/affected), boot from floppy and have a poke at the controller with MS-DOS DEBUG utility. Using the "I" command I can read from the I/O port address just like the BIOS ROM does when it's doing various tests.

First off, I thought I'd do the same 'controller present' test that the BIOS does: read the Sector Count and Sector Number registers, if 0xFF controller assumed absent. Also check the Status register while I'm there. I got the following:

• Primary Sector Count, 0x1F2 = 0x00
• Primary Sector Number, 0x1F3 = 0x00
• Primary Status, 0x1F7 = 0x02
• Secondary Sector Count, 0x172 = 0xFF
• Secondary Sector Number, 0x173 = 0xFF
• Secondary Status, 0x177 = 0xFF

I'm not quite sure what the architecture of the card is supposed to be; is there only supposed to be a single IDE controller from the host system's point of view? I guess so, because looking at the BIOS ROM disassembly again, I realise that the code looks at the secondary controller (at 0x170) only if it fails at any of the checks on the primary. So the secondary returning all 0xFF would appear to be fine.

So, the primary controller (whether that's one or other of the PDC chips, or the 286) is alive and responsive, and would pass the 'present' check at least. The Status register value of 0x02 decodes to all flags/values being zero apart from IDX being set to 1 (which as far as I can tell is unusual - this says it should always be zero). So not BSY, no ERR, no DF, but also not RDY. This would also pass the 'not busy' test the BIOS does.

I need to dig more into the BIOS disassembly to see what else is checked.

I've dug a bit more into the disassembly of the function whose result triggers the "Get config failed" error.

There's one function that's called after the 'controller present' check where the return value is not acted upon. It seems to perform some kind of vendor-specific command on the controller.

1. Writes a bunch of values to the disk controller's registers: sector count, sector number, drive/head, command. The command is 0xF0, which is 'vendor-specific'.
2. In a timeout loop, polls the sector count register for either the value 0x50 or 0x70. If it times out, returns failure.
3. Checks the error register for a zero value. If non-zero, returns failure.
4. Otherwise, returns success.

A sub function the above uses to write the collection of values to registers has two variants: a short timeout, and a long timeout. It uses the short version in this case. These two functions are largely the same:

1. Waits for the controller to not be busy, with timeout. Returns with failure if timed out.
2. Enables IRQs 12, 6, and 7 on the slave 8259 PIC, and IRQ 2 on the master. (No idea why these IRQs - they're unrelated to IDE, right? PS/2 mouse, floppy, and parallel port, yes?)
3. Writes to the disk controller's control register (e.g. 0x3F6) and sets nIEN=0 to enable hardware interrupts.
4. Write the 7 register value bytes to controller registers 1 through 7 (e.g. 0x1F1..0x1F7).

However, as I said above, this is not the cause of the error, as the return value isn't checked. But there is one other function call (I missed this in my earlier post) that is much more involved and has many sub-calls to several other functions, and the return value of this is checked. It's going to take me much longer to analyse that one. 😓

This card has a PDC20230B yes? It was jumper configured but software detectable

Looks like they removed VLB support from legacy_pata.c this year, which makes it a little more difficult to find those coding examples.

The linux code was based on this:

http://web.archive.org/web/20030919194021/htt … /pdc20230b.html