I do not know why it does not work with AMI bios but if it works with Award bios, why not use the Award BIOS. As one who messed with boards since early 90's have always been an Award fan, hated certain AMI bios back in the day from 486 up.
Just my opinion and also hated most Pheonix core bios which Intel used versus Asus/Giga/etc using Award bios for similar board even in the latter P4's and above....

Cross linking relevant thread.

Re: Dual Tag Ram mod For Intel 430HX Socket 7

Don’t think it has the answer, but perhaps the author might be able to help.

Btw mr bios may be an option?

I also prefer AWARD BIOS for this mainboard generation anytime.
But there aren´t too many 430HX mainboards with onboard SCSI.
There´s the Gigabyte "GA-586DX" - but this has a UMC super-I/O chip and
thers´s the ASUS "P/I-P55T2P4S" that comes with a Winbond super-I/O.

Does anyone know what the "Strapping Option" in the Intel datasheet means ?
Quote: "Default Value: SSSS0010 (S=Strapping Option)"

It looks like it´s valid for the first 4 binary values 7:4. Is this some kind of joker value?
If so this would reduce the number of possible combinations.

majestyk wrote on 2022-11-08, 07:43:

Does anyone know what the "Strapping Option" in the Intel datasheet means ?
Quote: "Default Value: SSSS0010 (S=Strapping Option)"

from the datasheet page you posted...

" after a hard reset, CC[7:4] reflect the signal levels on the host address lines A[31:28] "

Yeah, when power is first applied to a chip then it first reads the state of any strapping configuration pins, before then using them for their normal purpose. Setting the state is usually done by using a resistor to pull the line either low or high as appropriate. Resistance needs to be high enough that it doesn't place a significant load on anything else that drives the line once the chip has started up but low enough to guarantee the input to the chip can be read as a '0' or '1', something like 10-100k seems to be common.

So some register values can be set by the designer before any code has started to run. OTOH, the datasheet does say that the values in this register can be overwritten by writing the register. Maybe something else is configured by reading the register before your modification writes to the register? It must be important somehow for those 4 bits to be set very early on otherwise they would have just been left as ordinary pins and the register value set once code was running.

The register values I enter in the BIOS chipset init table seem to be disregarded.
I just tried with the first (7:6) values set to "00" and cache is still enabled and reported correctly in the BIOS summery. If I disable it in the BIOS setup menue, it gets disabled and is no longer reported.
So while BIOS can (and is supposed to) overwrite hardcoded values after reset, entries / switches in the BIOS setup menue overwrite any values I enter in the BIOSes chipset init table. They are applied towards the end of the process.
Somewhere inside the code for the setup menue switches the register strings get modified / overwritten. If the binary value for cacheable size is generally set to "0" there, my entries in the init table are useless.
Entries in the init table would - if this assumption holds true - only make sense for registers (strings) that don´t get touched by the menue switches at all.

Check TIO[10] : is it pull-upped or pull-downed ?
For 512mb cacheable area it should be pull-downed.

Yes, I did that - see second paragraph of my opening post.

Have you tried incorporating the scsi bios with the award bios ?
or use the scsi bios separately from the main bios ?

majestyk wrote on 2022-11-08, 14:56:

Yes, I did that - see second paragraph of my opening post.

Yes, I see now. I peeked into the bios a little bit and changed one byte (I took bios-image from theretroweb.com).
Maybe you will give it a try on your own risk if you have a hardware programmer and if you'd like, of course.

P.S. the modded bios was deleted as it has a bad checksum

Thanks for digging deeper!
The modded BIOS stops at "d0 --" (post-card output).

(The revision of my board is the one with onboard 2nd VRM below the CPU-socket.)

Here´s the BIOS the board came with:

majestyk wrote on 2022-11-09, 13:42:

Thanks for digging deeper!
The modded BIOS stops at "d0 --" (post-card output).

(The revision of my board is the one with onboard 2nd VRM below the CPU-socket.)

Thanks. Sorry to read it. The disassembling and modding is slick and unpredictable way.
Than maybe the more robust way would be to add a SCSI ext ROM into a working compatible BIOS or add a ROM extension that writes a necessary value into a some register ( e.g. 52h ).
First way can be done using a specific utility applied to a compatible bios (cbrom or something).
Second way ... I have read about it 😀

P.S. Ok. I'll peek into the original bios
P.P.S. It's the same. It just has config data of your system

P.P.P.S. It looks like I forgot to recalculate checksum and that causes "d0" error.
Yes, that's it. There's a checksum at 0x1E000 that covers the bootblock. AMIBCP 7 doesn't correct this checksum.

majestyk wrote on 2022-11-09, 13:42:

Thanks for digging deeper!
The modded BIOS stops at "d0 --" (post-card output).

I supposedly corrected the checksum. I hope the post-code "d0" is gone. My IDA-script gives a good result but who knows...

No more "d0", but still 64MB 🙁

I wonder if the "init early" settings get overwritten later during startup?
Thanks for your help!

majestyk wrote on 2022-11-09, 19:52:

No more "d0", but still 64MB 🙁

I wonder if the "init early" settings get overwritten later during startup?
Thanks for your help!

Welcome!
Yes, I've thought about it. And you have proven that some code overwrite the register

Fun fact: The AWARD BiOSes I tried here enable the enlarged cacheable area no matter if TIO10 is being pulled up or down at startup.

majestyk wrote on 2022-11-10, 10:20:

Fun fact: The AWARD BiOSes I tried here enable the enlarged cacheable area no matter if TIO10 is being pulled up or down at startup.

The behaviour is normal because straps can be overridden later.
Have you tried to inject the SCSI ext ROM into them using CBROM ? It might work

I have used CBROM a couple of times for simpler mods, so each time I have to re-learn the syntax.

In the meantime I found another (later) AMI BIOS from November 1997 for the AOPEN AP53 mainboard.
It provides the "enlarged cacheable area" option as a hidden entry under the chipset settings. I activated the option using AMIBCP, set the entry to 512MB and....
....snareroll....still 64MB 🙁
I then even added the 52h register string, needless to say - still 64MB.

This BIOS is quite promising otherwise with some additional features and it even detects "onboard SCSI" (without providing the Adaptec BIOS of course).
Here´s the Aopen BIOS with the cacheable area switch enabled:

majestyk wrote on 2022-11-11, 17:43:

...
This BIOS is quite promising otherwise with some additional features and it even detects "onboard SCSI" (without providing the Adaptec BIOS of course).
...

When Award bios , that you've mentioned in your first post , is installed does Windows find Adaptec AIC-7880P as a PCI device?
If it does then I can try to add the scsi oprom from the original bios into the award bios. Just attach it here.

P.S. There's an interesting problem - how BIOS detects the second tag-chip is installed.
Does it just believe that if you've chosen the option in settings then a chipset can start caching a bigger area ?