Oh now I realize your card is an ISA one, whereas my cards are PCI. (yeah it read in the whole thread title, but didn't register to me..)

I wonder if the ISA bus speed in BIOS might have any effect? Try lowering the bus speed if possible?

Other random ISA bus things that come to mind are to
- double check the zero versus one wait state thing in board jumper, and in BIOS?
- try removing all other ISA cards on the system (they are all electrically connected)
- try placing the graphics card in another ISA slot
- try adjusting video BIOS shadowing (the C000h - C800h segment shadowing)

Might be irrelevant wild gooses, but maybe one of these things might get lucky.

The vga palette register is fairly easy to access, even from quickbasic.

What I would do, is probe the palette register, and collect what all the current indexed color designations are, then do the same thing from inside, eg, dosbox, then compare the dumps.

If I understand correctly, all other palette-changing software works out ok, just Windows 3.1 was acting odd. So manually writing code to probe palette indices might not reproduce the issue.

From existing games and demos that utilize the palette register: Wolfenstein 3D (uses REP STOSB palette updates in screen fade-in and fade-out), Kukoo 2 demo (reprograms the palette register mid-frame), Wiering's Mario (does palette fading traditional way), Jazz Jackrabbit (does palette cycling animation e.g. in waterfalls) and One Must Fall 2097 (multiple screens with different palettes)

If those don't show any issues in DOS, then it should definitely be something that only manifests in a very specific code pattern, maybe due to the 2D GUI blitting acceleration.

Board capacitor recapping in order?

This is clearly not a palette issue, but a video RAM data corruption issue. If it were a a palette issue, all occurrences of the same color would be broken. As we see in the windows screenshot with the title bar "Main" for one of the groups, most parts of that bar have the blue color that is supposed to be there. Just the parts near the buttons and below the title are magenta instead of blue.

Unstable supply to the CL-GD5434 chip or the RAM may cause RAM data corruption, so the recapping idea might apply. On the other hand, this card uses tantalum caps, and as long as those caps do not burn down (or "explode"), they don't tend to go bad as easily as wet aluminum electrolytics. I currently assume that a broken trace, via or solder joint between the CL-GD5434 and the RAM, which still provides capacitive coupling, but fails for DC, is the most likely cause, but of course we also can't exclude a broken GD5434. There are tools to adjust the memory/accelerator clock of the GD5434. You might want to check whether underclocking the chip makes any difference.

Okay, flashed 2.01 to an EEPROM and it works fine with the card. However, the issue still persists. I did notice one thing is different in the 256 color palette test.

Bios 2.02

Bios 2.01

Bottom right is different between the two versions. My other cards have different values there too, so not sure that matters, but interesting.

Next step a recap? Or should I try to do some continuity tests on the memory lines/reflow those?

Try disabling your CPU's external cache (if present) and see what happens. I had an issue like this with my speedstar 64 and it turned out to be a bad motherboard cache chip. There were other hints though, like stability issues in games - but not as often as I would have expected.

mkarcher wrote on 2024-09-02, 12:54:

This is clearly not a palette issue, but a video RAM data corruption issue. If it were a a palette issue, all occurrences of the same color would be broken. As we see in the windows screenshot with the title bar "Main" for one of the groups, most parts of that bar have the blue color that is supposed to be there. Just the parts near the buttons and below the title are magenta instead of blue.

Unstable supply to the CL-GD5434 chip or the RAM may cause RAM data corruption, so the recapping idea might apply. On the other hand, this card uses tantalum caps, and as long as those caps do not burn down (or "explode"), they don't tend to go bad as easily as wet aluminum electrolytics. I currently assume that a broken trace, via or solder joint between the CL-GD5434 and the RAM, which still provides capacitive coupling, but fails for DC, is the most likely cause, but of course we also can't exclude a broken GD5434. There are tools to adjust the memory/accelerator clock of the GD5434. You might want to check whether underclocking the chip makes any difference.

I tried MCLK to change the ram clock, but the problem is the 5434 resets the ram clock on mode changes. So I can't underclock, then start windows or something, it just ends up back to the default value. I could modify the bios I guess to change that value.

furan wrote on 2024-09-02, 14:36:

Try disabling your CPU's external cache (if present) and see what happens. I had an issue like this with my speedstar 64 and it turned out to be a bad motherboard cache chip. There were other hints though, like stability issues in games - but not as often as I would have expected.

This is a 386SX-40 system. No FPU, no external cache. New ram that tests fine in memtest86+.

ahyeadude wrote on 2024-09-02, 14:32:

Okay, flashed 2.01 to an EEPROM and it works fine with the card. However, the issue still persists. I did notice one thing is different in the 256 color palette test.

Bottom right is different between the two versions. My other cards have different values there too, so not sure that matters, but interesting.

It does not matter. The last 8 colors in the 256-color palette are not defined by IBM. I expected them to be black, but obviously different cards handle it differently. I suspect the 2.01 BIOS does not initialize the last 8 colors at all, so you get those colors left over from the last application that programmed these colors.

ahyeadude wrote on 2024-09-02, 14:37:

I tried MCLK to change the ram clock, but the problem is the 5434 resets the ram clock on mode changes. So I can't underclock, then start windows or something, it just ends up back to the default value. I could modify the bios I guess to change that value.

Too bad. Depending on how the graphics card virtualization works, MCLK might work in a DOS window, but I'm afraid that likely MCLK will do nothing in windowed mode, and will be reset when switching from a full-screen DOS session to Windows.

Removed all other ISA cards, same result.

Post on the system:
Childhood 386sx turned up to 11

Also, as mentioned previously, I've changed every possible bus timing and memory setting in the system bios with no effect. I've always been confused on what the ISA bus clock is on these 386SX systems. Does the 14.31818 mhz oscillator get divided down to 7.15 mhz? Or is there an internal clock source in the chipset? Either way, no other ISA bus related issues with this system, everything works fine.

ahyeadude wrote on 2024-09-02, 15:16:

Also, as mentioned previously, I've changed every possible bus timing and memory setting in the system bios with no effect. I've always been confused on what the ISA bus clock is on these 386SX systems. Does the 14.31818 mhz oscillator get divided down to 7.15 mhz? Or is there an internal clock source in the chipset?

These chipsets often allow either a divided processor clock (like processor clock / 5 on a 40MHz processor) or an asynchronous clock like the 14.318 oscillator to be used for the ISA clock. There is most likely no completely independent internal clock source, and quite definitely no internal PLL to generate 8MHz bus clock from 14.318.

mkarcher wrote on 2024-09-02, 14:45:

Too bad. Depending on how the graphics card virtualization works, MCLK might work in a DOS window, but I'm afraid that likely MCLK will do nothing in windowed mode, and will be reset when switching from a full-screen DOS session to Windows.

Yea, I tried in a DOS window, but Windows 3.11 protects those registers from writes. Here is the relevant code snippet from MCLK. I am completely unfamiliar with how it works. It mentions it is modifying the SVGA registers. Trying to understand how I can translate these register addresses to locations in the video BIOS so I can modify the memory clock lower.

Damaged 5434 / internal breakdown / degradation somewhere. One of the internal data buffers corrupting on a certain address?

Different drivers/firmware may access/utilize parts of the chip slightly differently so what is "wrong " may change between them.

ahyeadude wrote on 2024-09-02, 14:37:

I tried MCLK to change the ram clock, but the problem is the 5434 resets the ram clock on mode changes.

Hah, that is the same bug that this card BIOS suffers from for another bit in the PCI Configuration space registers. The reason why I have two of these cards in my lab, a 1.01 BIOS and a 2.01 BIOS card is that I saw that reset bug on every mode change to take place for PCI configuration space snoop register, and wanted to know if a card with a newer BIOS would have the same bug. (and yeah, it did) This is actually the only VGA card in my lab (out of several dozen ones) that has this bug, none of the other Cirrus-Logic cards have this problem.

To work around that bug, I developed a TSR program that kept the PCI config register bit latched to the value that I want across mode changes. The same kind of strategy should work for the MCLK register, if you identify the I/O register values you want to reset at each mode change.

You can find the TSR software here: https://github.com/juj/crt_terminator/blob/ma … ITSR/PCITSR.CPP , it is only a few lines of Borland Turbo C++ code.

Finally got my test bench going. I should be able to test things more quickly now. It's a completely different system, with no common components to the other machine.

The issue remains. So it is definitely the card and not a compatibility issue.

Will start more testing tomorrow.

Before I get medieval with flux and heat, any reason to test the SN74LS245N (U13; I think this is an ISA buffer) or the MC74F04N (U15; not sure what this is)? I found both in Xgpro logic tests.

I would have said no, but there was someone found a 245 buffer glitching his memory on a 386 board, so could be worth a check.

Those ICs tested fine, good to eliminate those as the cause.

I've got 3 NOS CL-GD5434-J-QC-F chips on the way. I'll try a reflow today of the 5434 (can't see anything visually with magnification). If that doesn't work, I'll remove the 5434 and get the board cleaned and prepped for a new chip when they arrive.

Reflow with flux did not work.

Removed the original 5434 with some low temp solder and hot air. I've got it cleaned up and ready. Also have the new chips. Will make an attempt to install maybe later today or in the morning. Wish me luck!