I reverse engineered the complete initialization code of the BIOS. We started the test of different processors, because I noticed the BIOS contains a processor clock determination function that doesn't check for Cx486 before assuming specific clock cycle counts, so I suspected that function might misbehave with Cyrix processors.
Deeper analysis showed that this function is used to chose one of two parameter sets in the BIOS (actually, the BIOS also contains a third set, which is never used), and it likely is meant to measure the internal CPU clock assuming Intel/AMD timings. If that clock is above 35MHz, the "FSB50 parameter set" is activated; if that clock is lower, the "FSB33 parameter set" is activated. I suspect the third set is a "FSB25 parameter set". The function is implemented quite straight-forward, and the only risk of that function is an integer overflow on division (which will crash the system) if an Intel-equivalent clock exceeding 320MHz is determined. I am quite confident that this is not our issue here.
I strongly suspect the actual issue is marginal timing/signal quality on the VL bus, although I don't quite understand how this could end up in a system that is blocked during POST, but still responds to interrupts (NumLock can be toggled, after 16 keypresses, the keyboard interrupt starts beeping). I'm trying to trace execution of the POST using a logic analyzer clipped to the BIOS chip with L1 disabled in Setup, hoping that I can observe at what point things go wrong.
I am not impressed by some aspects of the coding style of that BIOS. For example, that BIOS uses the classic I/O delay pattern, which IIIRC was already used by IBM in the 5150 BIOS: Place one or multiple copies of JMP $+2 between two port I/O instructions to ensure that the prefetch queue is flushed and re-filled via the front-side bus, which makes back-to-back I/O cycles impossible and provides plenty of recovery time for the accessed resource. This scheme is efficient and effective, but only up to the 80386! Given the pattern "OUT dx, al; JMP $+2; JMP $+2; IN al,dx", the 486 may put the value to be written to that port into its four-stage write buffer, continue executing the "JMP $+2" instructions from L1 cache (without any FSB cycles), and then block on the "IN al, dx" instruction until the write buffer drained. As soon as the write buffer drained, the IN cycle is executed back-to-back with the posted OUT cycle, entirely defeating the purpose of this pattern to prevent back-to-back I/O cycles. I don't expect this pattern is the cause issues I am observing, but seeing this pattern in code specifically targeted to 486 systems (it's a VL controller BIOS!) feels kind of nauseating.
EDIT: I hooked up the logic analyzer to the ROM (which obviously involved re-inserting the VL card another time), swapped the processor back to the Cx486DX2, and now the system works perfectly even at 2*40MHz = 80MHz. Also, the BIOS starts up with a message "Press F5 to skip BIOS installation, or other keys to continue" which is supposed to have a 1 second timeout. That timeout didn't work properly yesterday, but it does today. The timeout is based on polling for a key 500 times with a 2ms delay between attempts; the delay is based on observing the toggling of bit 4 in port 61h, which is supposed to happen at 32kHz, derived from the RAM refresh timer that triggers at 64kHz. With the system working properly now, I tested that "slow refresh" in the chipset options does not affect the rate of that bit, the "divide-by-4" circuit to generate a lower refresh rate is obviously located further down the processing pipeline. The timeout misbehaving yesterday (even with processors listed as "works") points to serious issues on the mainboard - possibly a marginal Opti 82C802 system controller chip. The "beep" for the PC speaker works fine, so we know the PIT works and the 14MHz clock is present. Yet the VLB I/O controller "press F5" time-out based on another PIT output did not work. So definitely take the list of working CPUs with a big grain of salt.
