VOGONS


Noisy video from ET4000

Topic actions

First post, by eesz34

User metadata
Rank Member
Rank
Member

I have a Boca ET4000 ISA video card that was in a 286 and it worked perfectly there. I moved it to a 386DX and the video output is now what I'd call noisy. I had previously tested the 386 motherboard with some other non-ET4000 and had no issues.

I'm seeing this even at the DOS prompt, but it's also visible in graphics mode like Windows 3.1. I have found others complaining about "snow" on an ET4000 but I wouldn't call this snow because it's not causing pixels to light in random areas of the screen. It's also affected by by shadow settings, and if DOS 6.22 is loaded bare.

If BIOS shadow is enabled, it's always present even at DOS prompt.

If BIOS shadow is disabled and I skip config.sys and autoxec.bat with F5 it's nearly perfect except for some during hard drive access. If I load only

dos=high

it's the same.

If BIOS shadow is disabled and I load only

dos=high

and

himem.sys

it's really bad.

The POST screen and BIOS setup screens always look perfect. I am using MR BIOS on this, but I'm seeing similar problems with the original BIOS. What is going on with this? It's a little strange.

Here's a video: https://youtu.be/BvnCdPIeXo4

Reply 1 of 15, by clb

User metadata
Rank Oldbie
Rank
Oldbie

To me this looks like a video signal timing problem with the horizontal sync signal. That is, the hsync signal timing is not completely in perfect sync, so the start of the scanline fluctuates a bit. With CRT Terminator Digital VGA Feature Card ISA DV1000 I can sometimes coax the same kind of signal by deliberately misconfiguring the video signal sampling phase setting (making scanlines jitter one-off)

Is that an LCD or a CRT monitor you are viewing this on?

eesz34 wrote on 2024-11-13, 21:46:

I have a Boca ET4000 ISA video card that was in a 286 and it worked perfectly there. I moved it to a 386DX and the video output is now what I'd call noisy. I had previously tested the 386 motherboard with some other non-ET4000 and had no issues.

This is quite interesting. Different PCs have different PSUs and different motherboard power generation circuitry, those could affect this kind of a thing. The ISA bus provides a clock signal, which could give slightly different timings to the card.

eesz34 wrote on 2024-11-13, 21:46:

I have found others complaining about "snow" on an ET4000 but I wouldn't call this snow because it's not causing pixels to light in random areas of the screen.

Yeah, this is definitely not VGA adapter snow.

eesz34 wrote on 2024-11-13, 21:46:

It's also affected by by shadow settings, and if DOS 6.22 is loaded bare.

If BIOS shadow is enabled, it's always present even at DOS prompt.

If BIOS shadow is disabled and I skip config.sys and autoxec.bat with F5 it's nearly perfect

Well, these are extremely peculiar results.

eesz34 wrote on 2024-11-13, 21:46:

it's nearly perfect except for some during hard drive access.

Now that's a clue. Is that an old HDD that consumes noticeable amount of power? If so, then I would think that something towards the PSU, motherboard or VGA adapter capacitors or clock oscillators would be to blame. I.e. signal integrity kind of a thing.

eesz34 wrote on 2024-11-13, 21:46:

The POST screen and BIOS setup screens always look perfect. I am using MR BIOS on this, but I'm seeing similar problems with the original BIOS. What is going on with this? It's a little strange.

BIOS screen and BIOS setup are likely in EGA 640x350 text mode (80x25 text mode with 8x14 pixel font characters, pixel clock = 25.07MHz), whereas the regular DOS video mode is VGA 720x400 text mode (80x25 text mode with 9x16 pixel font characters, pixel clock = 28.2 MHz). These are two different video modes with different pixel clocks and video mode timings, so it is not so unexpected that a timing related problem might manifest only in one video mode or the other.

You can try for example to run Sim City in DOS. That uses the 640x350 resolution video mode, so you can see what the video parameters are there.

Reply 2 of 15, by eesz34

User metadata
Rank Member
Rank
Member
clb wrote on 2024-11-13, 22:23:
To me this looks like a video signal timing problem with the horizontal sync signal. That is, the hsync signal timing is not com […]
Show full quote

To me this looks like a video signal timing problem with the horizontal sync signal. That is, the hsync signal timing is not completely in perfect sync, so the start of the scanline fluctuates a bit. With CRT Terminator Digital VGA Feature Card ISA DV1000 I can sometimes coax the same kind of signal by deliberately misconfiguring the video signal sampling phase setting (making scanlines jitter one-off)

Is that an LCD or a CRT monitor you are viewing this on?

eesz34 wrote on 2024-11-13, 21:46:

I have a Boca ET4000 ISA video card that was in a 286 and it worked perfectly there. I moved it to a 386DX and the video output is now what I'd call noisy. I had previously tested the 386 motherboard with some other non-ET4000 and had no issues.

This is quite interesting. Different PCs have different PSUs and different motherboard power generation circuitry, those could affect this kind of a thing. The ISA bus provides a clock signal, which could give slightly different timings to the card.

eesz34 wrote on 2024-11-13, 21:46:

I have found others complaining about "snow" on an ET4000 but I wouldn't call this snow because it's not causing pixels to light in random areas of the screen.

Yeah, this is definitely not VGA adapter snow.

eesz34 wrote on 2024-11-13, 21:46:

It's also affected by by shadow settings, and if DOS 6.22 is loaded bare.

If BIOS shadow is enabled, it's always present even at DOS prompt.

If BIOS shadow is disabled and I skip config.sys and autoxec.bat with F5 it's nearly perfect

Well, these are extremely peculiar results.

eesz34 wrote on 2024-11-13, 21:46:

it's nearly perfect except for some during hard drive access.

Now that's a clue. Is that an old HDD that consumes noticeable amount of power? If so, then I would think that something towards the PSU, motherboard or VGA adapter capacitors or clock oscillators would be to blame. I.e. signal integrity kind of a thing.

eesz34 wrote on 2024-11-13, 21:46:

The POST screen and BIOS setup screens always look perfect. I am using MR BIOS on this, but I'm seeing similar problems with the original BIOS. What is going on with this? It's a little strange.

BIOS screen and BIOS setup are likely in EGA 640x350 text mode (80x25 text mode with 8x14 pixel font characters, pixel clock = 25.07MHz), whereas the regular DOS video mode is VGA 720x400 text mode (80x25 text mode with 9x16 pixel font characters, pixel clock = 28.2 MHz). These are two different video modes with different pixel clocks and video mode timings, so it is not so unexpected that a timing related problem might manifest only in one video mode or the other.

You can try for example to run Sim City in DOS. That uses the 640x350 resolution video mode, so you can see what the video parameters are there.

It's an old high end Eizo LCD (weighs a ton too!) that I've had good luck with on everything else.

It's a PATA SSD, so power consumption is low. But I had the same thought as you with regards to the power consumption "pulses". I even had another power supply out to try but came to the conclusion it's not power related but now I'm reconsidering that. Tomorrow I will try the other power supply and possibly put my scope on it to check for power quality. The power supply I am now using is an AT model from the late 90s and the case it came out of looks cools but is pretty flimsy. Makes me wonder about that power supply too. As I think about this more, power is to blame for a lot of weird stuff.

Do you think a clock signal off ISA bus could cause this? I assume the VGA controller continually generates the VGA signal and so shouldn't rely on the motherboard for that.

Good advice about trying Simcity. I should try some other games too.

Reply 3 of 15, by Postman5

User metadata
Rank Member
Rank
Member

Maybe try a different power supply, it will probably have slightly different frequency characteristics.

Reply 4 of 15, by clb

User metadata
Rank Oldbie
Rank
Oldbie
eesz34 wrote on 2024-11-14, 02:06:

It's an old high end Eizo LCD (weighs a ton too!) that I've had good luck with on everything else.

Good to give another LCD also a test. Different LCDs implement the pixel lock differently, so that might also provide a visible difference.

eesz34 wrote on 2024-11-14, 02:06:

Do you think a clock signal off ISA bus could cause this? I assume the VGA controller continually generates the VGA signal and so shouldn't rely on the motherboard for that.

The video pixel clock is always generated on the VGA adapter board, but the VGA adapter can use the ISA clock for a number of other things, and there will be some amount of clock domain crossings to combine the two. So it is not easy to conclude "the ISA bus clock could not cause this", but then again, it won't be the primary video pixel clock (nor will the video pixel clock be derived off the ISA bus clock either).

Also, given that it is a LCD, and a timing related thing, there might be occassions where when the system is in a good mood (i.e. PC is cold, or PC is warm, or similar), it might give a situation where first at cold boot the image is good, and then turns bad, or vice versa. This might give an odd impression of "if I change BIOS shadow settings, it affects the video output.", when in reality it could be the time in between flipping those options that gave enough time for the components to warm up. So there might be some amount of repeats to do to verify some of those very odd reading results about himem.sys and other settings.

This reminds me of this observation that on several old VGA graphics adapters in my lab, I see the hsync and vsync signals to be very "lazy" to toggle, sometimes taking several pixel clock cycles of creeping to do so. This has been very surprising, and I've made a mental note to try to recap some of those boards to see if that might have an effect, but never quite got around to it. If you have access to an oscilloscope, it might be interesting to see what the switching period of the VGA hsync line is, compared to the switching period of the individual pixel data.

Reply 5 of 15, by eesz34

User metadata
Rank Member
Rank
Member
Postman5 wrote on 2024-11-14, 08:19:

Maybe try a different power supply, it will probably have slightly different frequency characteristics.

I tried two others, an ATX with an adapter to AT, and the AT power supply that was running the 286 that previously held this card. Still there 🙁

Reply 6 of 15, by eesz34

User metadata
Rank Member
Rank
Member
clb wrote on 2024-11-14, 11:04:
Good to give another LCD also a test. Different LCDs implement the pixel lock differently, so that might also provide a visible […]
Show full quote
eesz34 wrote on 2024-11-14, 02:06:

It's an old high end Eizo LCD (weighs a ton too!) that I've had good luck with on everything else.

Good to give another LCD also a test. Different LCDs implement the pixel lock differently, so that might also provide a visible difference.

eesz34 wrote on 2024-11-14, 02:06:

Do you think a clock signal off ISA bus could cause this? I assume the VGA controller continually generates the VGA signal and so shouldn't rely on the motherboard for that.

The video pixel clock is always generated on the VGA adapter board, but the VGA adapter can use the ISA clock for a number of other things, and there will be some amount of clock domain crossings to combine the two. So it is not easy to conclude "the ISA bus clock could not cause this", but then again, it won't be the primary video pixel clock (nor will the video pixel clock be derived off the ISA bus clock either).

Also, given that it is a LCD, and a timing related thing, there might be occassions where when the system is in a good mood (i.e. PC is cold, or PC is warm, or similar), it might give a situation where first at cold boot the image is good, and then turns bad, or vice versa. This might give an odd impression of "if I change BIOS shadow settings, it affects the video output.", when in reality it could be the time in between flipping those options that gave enough time for the components to warm up. So there might be some amount of repeats to do to verify some of those very odd reading results about himem.sys and other settings.

This reminds me of this observation that on several old VGA graphics adapters in my lab, I see the hsync and vsync signals to be very "lazy" to toggle, sometimes taking several pixel clock cycles of creeping to do so. This has been very surprising, and I've made a mental note to try to recap some of those boards to see if that might have an effect, but never quite got around to it. If you have access to an oscilloscope, it might be interesting to see what the switching period of the VGA hsync line is, compared to the switching period of the individual pixel data.

I have not yet tried another monitor, but I've used this one with all sorts of systems including when the ET4000 was in a 286 and it's always been good.

This is definately not when the computer is warmed up or not as I have switched between all these combinations multiple times in one session and it always follows the configuration.

I have also tried two other power supplies including the one that I was using with the 286/ET4000 (!) and they do roughly the same thing. One interesting observation is when I connect an electrolytic across the ground and +5V it improves a little. There is 400 - 500 mV of noise on the +5 line, but it's made up of very fast rise/fall time switching noise of around 75kHz so that seems like the power supply switching frequency. I'm not too convinced right now it's a power problem.

I will have to scope out the VGA output. Seems I should be able to see this as jitter assuming it's the card.

I also tried powering the system with my bench supply, but it wouldn't detect anything on the super I/O card meaning I couldn't boot DOS. Not quite sure what's going on there. I know the RS232 ports often need +/-12V but looking at the datasheet for the I/O card controller, it should be fine with just +5V to get IDE working. Ahh the joy of PC clone hardware!

Reply 7 of 15, by clb

User metadata
Rank Oldbie
Rank
Oldbie

Gotcha, so the cold vs hot components have been ruled out.

Also, not sure if a coincidence, though in an older video I did about CRT Terminator, I posted about its compatibility quirks with different VGA adapters: https://youtu.be/i14WJheyG14?t=875

There in the compatibility matrix

The attachment crt_terminator_compatibility.png is no longer available

I commented about an observation that some VGA adapters took an unconventional approach to require video signal to be sampled at the falling edge of the clock signal, as opposed to the phase being on the rising edge, which is the norm.

ET4000AX was one of those unconventional adapters. So I wonder if that could relate to the root cause. Because if I the sampling phase is off (in this case with respect to hsync and pixel data), then exactly that type of one pixel horizontal jitter would result (sometimes the hsync signal might get interpreted one pixel early, vs one pixel later). Then if the LCD display VGA pixel lock struggles with trying both sampling phases, it might not synchronize to get the right lock. -> trying another LCD display might give interesting info.

That, or the adapter has a roaming hsync signal would be my guesses here. Oscilloscoping hsync vs a busy pixel data signal line could be interesting. (will require referencing between the two to see how stable they run with respect to each other)

Reply 8 of 15, by eesz34

User metadata
Rank Member
Rank
Member
clb wrote on 2024-11-14, 19:03:
Gotcha, so the cold vs hot components have been ruled out. […]
Show full quote

Gotcha, so the cold vs hot components have been ruled out.

Also, not sure if a coincidence, though in an older video I did about CRT Terminator, I posted about its compatibility quirks with different VGA adapters: https://youtu.be/i14WJheyG14?t=875

There in the compatibility matrix

I commented about an observation that some VGA adapters took an unconventional approach to require video signal to be sampled at the falling edge of the clock signal, as opposed to the phase being on the rising edge, which is the norm.

ET4000AX was one of those unconventional adapters. So I wonder if that could relate to the root cause. Because if I the sampling phase is off (in this case with respect to hsync and pixel data), then exactly that type of one pixel horizontal jitter would result (sometimes the hsync signal might get interpreted one pixel early, vs one pixel later). Then if the LCD display VGA pixel lock struggles with trying both sampling phases, it might not synchronize to get the right lock. -> trying another LCD display might give interesting info.

That, or the adapter has a roaming hsync signal would be my guesses here. Oscilloscoping hsync vs a busy pixel data signal line could be interesting. (will require referencing between the two to see how stable they run with respect to each other)

Oh that's interesting. I will be putting my scope on this today and trying a different monitor. Although that doesn't explain why changing cache settings and what TSRs load has any effect on this, nor why it's ok in another motherboard. And I should try this in that 286 motherboard again just to make sure something hasn't happened to the card.

Reply 9 of 15, by eesz34

User metadata
Rank Member
Rank
Member
clb wrote on 2024-11-14, 19:03:
Gotcha, so the cold vs hot components have been ruled out. […]
Show full quote

Gotcha, so the cold vs hot components have been ruled out.

Also, not sure if a coincidence, though in an older video I did about CRT Terminator, I posted about its compatibility quirks with different VGA adapters: https://youtu.be/i14WJheyG14?t=875

There in the compatibility matrix

I commented about an observation that some VGA adapters took an unconventional approach to require video signal to be sampled at the falling edge of the clock signal, as opposed to the phase being on the rising edge, which is the norm.

ET4000AX was one of those unconventional adapters. So I wonder if that could relate to the root cause. Because if I the sampling phase is off (in this case with respect to hsync and pixel data), then exactly that type of one pixel horizontal jitter would result (sometimes the hsync signal might get interpreted one pixel early, vs one pixel later). Then if the LCD display VGA pixel lock struggles with trying both sampling phases, it might not synchronize to get the right lock. -> trying another LCD display might give interesting info.

That, or the adapter has a roaming hsync signal would be my guesses here. Oscilloscoping hsync vs a busy pixel data signal line could be interesting. (will require referencing between the two to see how stable they run with respect to each other)

Got more information.

First, I have a correction to make. The ET4000 *was* always somewhat noisy in the 286, but not nearly as bad as in the 386. I think my brain drive space is running low 😀

It's still noisy on a different monitor, this one a much newer LCD.

I tried the ET4000 and the same super I/O card in both motherboards, connected to the same keyboard, power supply, and monitor, and they both have the issue, but the 286 is much better. It's almost good enough to ignore which is probably why I forgot about it.

Here's a scope capture of the ET4000 output on the 286. Channel 2 is V sync, 3 is H sync, and 4 is red. The probe grounds are each connected to pins 6,7 and 8 which are grounds. I'm not seeing noticeable jitter, but they sure seem noisy.
https://youtu.be/ZcARGZo_Du4

Next I connected the scope to a Prolinea I have, same exact method. Much less noise. That has to be the issue.
https://youtu.be/Li4Vk0kyWho

I did try powering the 286 with my bench supply, +5V only, but it wouldn't get through POST so it likely doesn't like the missing voltages. The VGA output was still noisy though.

Something odd I noticed on my card though: pins 84 and 85 are bridged and it doesn't appear intentional. It does appear factory though. As the chip is the 144 pin version this means these two are bridged:

HS pin
(datasheet explanation: Horizontal retrace synchronization signal, supplied to the CRT monitor)

and

TKN1
(datasheet explanation: Token Status output:
TKN (1) = ET4000's MCU is processing font cycle.
TKN(O) = ET4000's MCU is processing pixel cycle.
TKN ( 1:0) are redefined if CRTC index
35 bit 5 = 1:
TKN ( 1) = interlace mode active.
TKN(O) = even field. )

This is very suspicious and I feel like removing the bridge and retesting it. These two pins do not appear to belong together. EDIT just removed the bridge and no change.

Reply 10 of 15, by clb

User metadata
Rank Oldbie
Rank
Oldbie

I think both of those scope traces look good, although the time scale is a bit unknown there.

If you'd like to check individual pixel timings, you could try filling the screen with e.g. alternating red and green pixels. I wrote a quick test program to do that, see https://github.com/juj/crt_terminator/raw/ref … in/REDGREEN.zip

Given you can scope three leads, while viewing that program, checking the red and green pixel line vs the hsync line. The R and G lines should alternate, and show the duration of one pixel. Then there should be less jitter in the hsync line than half the length of the red and green pixel transition times.

Also it's good to check the falling edge of hsync, if there might be any jitter there.

Also, any chance you might have an actual CRT to try the VGA output on? I wonder how it will behave.

Reply 11 of 15, by eesz34

User metadata
Rank Member
Rank
Member
clb wrote on 2024-11-15, 21:03:
I think both of those scope traces look good, although the time scale is a bit unknown there. […]
Show full quote

I think both of those scope traces look good, although the time scale is a bit unknown there.

If you'd like to check individual pixel timings, you could try filling the screen with e.g. alternating red and green pixels. I wrote a quick test program to do that, see https://github.com/juj/crt_terminator/raw/ref … in/REDGREEN.zip

Given you can scope three leads, while viewing that program, checking the red and green pixel line vs the hsync line. The R and G lines should alternate, and show the duration of one pixel. Then there should be less jitter in the hsync line than half the length of the red and green pixel transition times.

Also it's good to check the falling edge of hsync, if there might be any jitter there.

Also, any chance you might have an actual CRT to try the VGA output on? I wonder how it will behave.

Will try your program, thank you.

I will also check the falling edge of H sync. I had a thought too that I could run the H and V sync through a buffer to see if it makes any difference. I admittingly haven't looked at a lot of VGA signals but all that noise and that discontinuity on H sync at almost the center of the screen makes me uneasy but then again the monitor should be ignoring it.

Unfortunately no CRTs. That would be interesting.

Reply 12 of 15, by eesz34

User metadata
Rank Member
Rank
Member
clb wrote on 2024-11-15, 21:03:
I think both of those scope traces look good, although the time scale is a bit unknown there. […]
Show full quote

I think both of those scope traces look good, although the time scale is a bit unknown there.

If you'd like to check individual pixel timings, you could try filling the screen with e.g. alternating red and green pixels. I wrote a quick test program to do that, see https://github.com/juj/crt_terminator/raw/ref … in/REDGREEN.zip

Given you can scope three leads, while viewing that program, checking the red and green pixel line vs the hsync line. The R and G lines should alternate, and show the duration of one pixel. Then there should be less jitter in the hsync line than half the length of the red and green pixel transition times.

Also it's good to check the falling edge of hsync, if there might be any jitter there.

Also, any chance you might have an actual CRT to try the VGA output on? I wonder how it will behave.

I take back my previous assertion that it's not power related. I'm now convinced it is. It might be that this card is simply very sensitive to noise on the power rail.

I looked at the rising and falling edge of H sync referenced to V sync and it's solid. Same with the RGB outputs. I keep coming back to how noisy the H and V sync outputs are. Those two signals are of course generated by the ET4000, then fed into a 74F244 bus driver. They look good going into the bus driver, but noisy coming out. The power rails into the F244 don't look nearly as noisy so I'm not sure what is going on there. It's almost like there's a lot of crosstalk occurring inside the chip but I don't totally trust my measurements when it comes to noise. I breadboarded an external F244, powered from the decoupling cap for the card's F244 so it's the same power, and routed the H and V signals through that and into the monitor but it didn't make a difference. I realize the extra wires to connect this all up isn't helping with signal integrity. If the onboard chip were socketed I'd try swapping it but I hate to desolder and replace it without firm evidence it's bad. I'll have to investigate this more.

Back to the impact from the power supply. Having tried three different power supplies I'm reluctant to say it's power, but perhaps this card is very sensitive to power noise. I think I may have mentioned this before, but sticking a 2200uF capacitor across the +5 and ground on the motherboard power connector dramatically improve the video output, although still not perfect. Another power supply I've tried, a well-used ATX that generates squealing noises, shows a definite correlation between noises it makes and video quality. This power supply has some problems since it shouldn't make that noise (probably bad output caps) but during POST and up to the boot manager, the power supply is quiet and the video is perfect. The moment it begins making the noises, the video artifacts start. This occurs sometime during the DOS boot process. The video artifacts are also influenced by accesses to the SSD.

TLDR; there seems to be an issue with power quality, but then every power supply I've tried has the same issue. I'm recapping the AT supply I intend to use with it, using good caps and increasing the capacitance of the output filters.

Reply 13 of 15, by clb

User metadata
Rank Oldbie
Rank
Oldbie

Given the YouTube video capture, I didn't get an impression that the noise is too bad here. I've seen way more horrible signal quality on some VGA adapters.

Still would be interesting to test out different LCD displays with VGA inputs or even actual CRT displays, if I understand that is not a variable that has yet been tried(?).. reads like everything else has been switched around it already.

Edit: Err nevermind, now I found the line where you did mention having tested another LCD.

Reply 14 of 15, by eesz34

User metadata
Rank Member
Rank
Member
clb wrote on 2024-11-18, 19:58:

Given the YouTube video capture, I didn't get an impression that the noise is too bad here. I've seen way more horrible signal quality on some VGA adapters.

Still would be interesting to test out different LCD displays with VGA inputs or even actual CRT displays, if I understand that is not a variable that has yet been tried(?).. reads like everything else has been switched around it already.

Edit: Err nevermind, now I found the line where you did mention having tested another LCD.

My thought is maybe the noise is bad enough that the monitor interprets these glitches as edges. I may be missing something on the scope that is infrequent enough in terms of the number of scope triggers, and this is where I need to use the persistence setting or increase the trigger level to find that.

I will continue tracking this down in my free time and report back here if I find anything interesting. It's a deceptively simple problem considering it's repeatable and involves only a few signals.

Reply 15 of 15, by eesz34

User metadata
Rank Member
Rank
Member
clb wrote on 2024-11-18, 19:58:

Given the YouTube video capture, I didn't get an impression that the noise is too bad here. I've seen way more horrible signal quality on some VGA adapters.

Still would be interesting to test out different LCD displays with VGA inputs or even actual CRT displays, if I understand that is not a variable that has yet been tried(?).. reads like everything else has been switched around it already.

Edit: Err nevermind, now I found the line where you did mention having tested another LCD.

I've been working on this occasionally and believe I've determined what's wrong. In short, the pixel clock from the VGA clock generator chip gets really jittery once himem.sys loads. The chip in question is to the left of the crystal and can be seen here: https://www.x86-guide.net/en/graphic_card/Boc … rd-no18594.html

I discovered this by noticing that if I trigger on a V sync pulse, then shift so I can view the next pulse on a small timebase (5 or 10ns) I can see the jitter get considerably worse once himem.sys loads. In reality it's probably not fair to blame himem.sys, but it must do something that causes much more activity on the bus and hence, more noise on the +5 rail.

Since this chip has it's own crystal attached to it, the only explanation is power quality. For anyone not aware, this chip contains a PLL and they don't like noisy power. However I've tried powering the entire system with a regulated bench supply and it still exhibits the issue. The clock generator has two tantalums in parallel on the analog supply pin, so I zeroed in on that. One is 22uF and I'm betting the other is too but I haven't pulled the board out of the MB yet to see. I held a 10uF low ESR electrolytic across one of the tantalums, and the issue magically goes away. So I will be replacing those and expect it to fix that problem.

This is interesting to me because I always thought if a tantalum isn't shorted or blown up, it's probably good. But apparently there's other failure modes. And I'm wondering if both caps are bad considering adding only 10uF fixes it. And maybe the remaining tantalums are bad too? I will certainly test them once they are removed and suspect the remaining 3 or however many are there might also be bad. If so, it might explain why the VGA output signals are so noisy.

According to this post (https://www.hpmuseum.org/forum/thread-16894-post-147709.html), they like to fail after 30-40 years. This board is right in that range.

Tantalums: they might not leak, but if they don't blow up they will drive you crazy in other ways.