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.

I believe this video card ended up on my desk. 🙂

I made a repair video as usual. If you don't want to watch the video, below is what the problem was:

https://www.youtube.com/watch?v=X3Cw34WQEXM

tony359 wrote on 2026-11-04, 18:04:

I believe this video card ended up on my desk. 🙂

Indeed it did. Great job Tony identifying the problem part so quickly! 👍 Thanks again.

Ok., I need some help from the community before I shred this card in a thousand pieces 😀 (Sorry @HwAoRrDk !)

So, a little plot twist and also spoiler, after I made the repair video I went to test the card again and it was preventing the system from booting. Which was the original fault that could be seen UNDER the video corruption. But it worked fine during my final tests! Most of the time it wouldn't say "Starting MS-DOS", sometimes it would say it but stop there. Other times it would boot and then end up in lots of errors.

Very very long story short, I found that if I warmed up the 244 which is connecting the VGA BIOS to the 8-bit ISA BUS, I could make it boot and I could run a graphic benchmark indefinitely. But once I'd quit the test and go back to the OS, I'd have HDD read/write corruption almost immediately.

So I replaced the 244 and it started working fine.

However, the video output was flickering - that is, the brightness was flickering - whenever the HDD was being accessed and also whenever some CPU activity happened. That has always been there, I thought it was my capture device but no, it happens on a monitor too.

I thought it was a third fault. I left the card alone for 3 days, went to test it again as I wanted to make sure the "unable to boot" issue was resolved first. And it wasn't. The card worked for 5 minutes and then started misbehaving again.

So I removed XT-IDE and installed a 16-bit ISA IDE controller card with the same Compact Flash card.

Now the system worked fine. I ran hours of RAM and HDD tests with Check-it, zero issues whatsoever. Even with the "bad" 244 transceiver.

But, the video output still flickered - but not as bad as with the XT-IDE in the system! 😀

On the Cirrus Logic, the video output is set by the IREF pin of the main chip. It's a constant current connection. To make that happen, there is a TL431, a transistor and a resistor. I cooled down the TL431 while the card was running a memory tests and the flickering went away. 😀

However, if I check with my scope, I don't really see a lot of voltage instability on the 2.5V of the 431, it's barely visible with 100mV resolution. And with XT-IDE in the system, the flickering is always there, regardless of cooling down the 431 or not.

If it helps, I've noticed that the flickering happens when CheckIt says "Lower Address Lines" only. I'm just joining the dots: the XT-IDE is an 8-bit device, the IDE controller is a 16-bit. Maybe the card has an issue with the lower bits? But that's ONLY the BIOS on this card.

I have checked on an actual monitor and the flickering is there too. Also, a different VLC board in the same system doesn't show the issue.

My question: is this Cirrus Logic card known for this bad video output? Does any of what I've said make any sense to any of you? Is the XT-IDE known for conflicting somehow with a VLB card?

I don't have another VLB motherboard to test it with but with another VLB card I have zero issues.

Help 🙂