So I'm about to attempt a DX2/80 meaning bumping VLB up to 40 MHz and am interested in hearing some of the background details since it seems there are a few here with intricate knowledge of 486 chipsets 😁

The board has UMC 82C491; it's an EFA HL3S. It supports only 5-volt CPUs and I've got a Cx486DX2/80 that should be arriving today.

There is a JP18 jumper for VL-BUS speed <= 33 MHz or > 33 MHz. I assume that has something to do with wait states.

There is another JP7 for CPUCLK >= 40 MHz or CPUCLK <= 33 MHz. Why is this needed and why would it ever be set differently than the VL-BUS speed jumper? It appears for DX2s it's set based on the external clock, so I should have it on the 40 setting for a DX2/80 and the 33 setting for a DX2/66.

I assume, if I wanted to experiment with more aggressive VLB timings just for the fun of it, I can experiment with JP18 and 7 on the 33 setting and not set anything on fire? I might get scramble the file system though.

On the same note, my Trident 9440 VGA card appears to have similar jumpers - one for "standard" vs "alternate" VLB timing, and one for CPU speed <= or > 33 MHz.

There are a few undocumented motherboard jumpers that it says to set the same regardless of clock settings - JP13, JP29/30, and JP31.

I have the printed manual. There's also a jumper advisor program on Internet Archive from EFA Corp's website.

By the way, why is there different jumpering depending on whether you have a plain 486 or 486 OverDrive? I thought the only motherboard-perspective difference for OverDrive was if you had an onboard 486SX to disable.

Thanks - I haven't dealt with VLB in many years and it's interesting looking at it now with much more technical knowledge. I've been studying some of the code for the driver for my UMC 8672 I/O controller and how it sets all the different timings. The DOS driver seems to get it into a mode where if I loadlin with ide0=umc8672 the Linux driver can't recognize it, but I wrote a short program to do some of the same I/O port poking that the UMC drivers (something about 491 1T delay - would that be i/o recovery time?) do before running loadlin and it seems to fix it.