The 74F32 is primarily used to provide a sufficient address space for 386DX and 486 systems. The CL-GD542x family of graphics chips only supports address lines up to A23, providing just 16MB of address space. The 542x chips can not distinguish an access to video memory at A000:0 from an RAM access cycle to 16MB + A0000 without external help. The external help is another input pin that enables the address decoder only if it is low. You could just connect this pin to A24, which means the CL-GD542x would only respond to 0..16MB, and disabled at 16MB..32MB. It will still interfere at 32MB + A0000. This was deemed insufficient by Cirrus Logic when they suggested the VL card design (and they needed some OR gates for another purpose anyway), so instead they use one gate of the 74F32 to detect whether both A24 and A25 are low, increasing the supported address space to 64MB. This means the card still interferes with RAM access at 64MB + A0000, but many system designs at that time were limited to 64MB address space anyway, so this is an acceptable compromise. This way of interfacing the CL-GD542x to the local bus thus allows operation in systems with up to 64MB address space, but as the Cirrus chip is completely taken off the bus at 16MB..64MB, the linear frame buffer, if enabled, is always located in the first 16MB. As this makes little sense, Cirrus Logic doesn't recommend to use the simple 74F32 solution if LFB usage is desired, but suggests a more complex solution involving a custom programmed PAL for high address decoding instead.

Except for keeping the 542x off the bus at 16MB..64MB, the 74F32 is also used to generate the BIOS read signal. We know that BIOS reads are working if the system is posting with something on the screen, as the BIOS is required to set up the graphics card to generate any kind of output at VGA frequencies. Furthermore, it seems more like data is bad than the cirrus chip responding or not responding at the wrong time, so I think the 74F32 is unlikely to be the culprit. The 74F32 only sees the top two address bits to decide whether the 542x should be enabled, so a failure of that chip would not explain why the text can be written to the screen memory, but the character shapes or character code numbers are messed up.

I've been trying to probe the signals to/from the 74F245s, but its proving to be tricky. Because of course the VLB side sees all the data bus activity from the CPU, seeing whether what's going in is also correctly coming out means one has to also look at the /OE and DIR pins, and I only have a 2-channel 'scope. 🙁 I tried using the /OE pin with the third external trigger input - assuming the buffers will only be enabled when the GD5429 either wants to talk or listen - but it's still tricky to tell what's going on.

What I can say is that when doing that, there's a bunch of activity during POST, but then the GD5429 seems to go 'silent' at the point the system doesn't progress any further in the boot process and no further activity.