Also now I see that the message about latching behavior that SNOOP.EXE reports is wrong and can be ignored (this was a bug in SNOOP that I have fixed, but I notice I didn't uploaded a fixed version of SNOOP to GitHub)

The palette snow message is likely related to the palanim flashing.

When you write that "palanim [...] looks perfectly smooth from the VGA out.", do you mean that the palette animation effect also correctly cycles when viewed on VGA? Or does VGA show static unmoving image?

clb wrote on 2025-02-01, 10:16:

That sounds unexpected/something that I feel like I haven't seen before. Would you be able to record a video of what that looks like?

https://youtu.be/FDsmeTsNm9s

My guess is that since the Terminator thinks its getting corrupt palette information, Entry 0 (or which ever is the entry for the background color) is being "updated" incorrectly, causing the flashing. The colors of the bars themselves are also often wrong, looking rainbowish.

Thanks for the video. Something is definitely off here.

It does look like CRT Terminator is thinking that palette index 0 is getting programmed with something non-black (likely a result of some corruption/confusion). The PALANIM.EXE test program explicitly writes color 0=(0,0,0) at every loop iteration, so something unexpected is happening.

I added a new PALTEST.EXE program for unit testing palette upload behavior. Would you be able to give that program a go and see what it prints? Hopefully there might be able to give some clues to what is the source of the problem.

The PALTSR program should NOT be running when PALTEST.EXE is run. (it would confuse the test)

clb wrote on 2025-02-03, 20:28:

I added a new PALTEST.EXE program for unit testing palette upload behavior. Would you be able to give that program a go and see what it prints? Hopefully there might be able to give some clues to what is the source of the problem.

Thanks for the fast response! 😀

I've attached the output from the command, and yeah, its totally not happy all over the place. This is from a fresh-boot straight into DOS with a nearly empty autoexec.bat/config.sys

Ouch, yeah, the results are quite unexpected.

I presume if you run that multiple times, the printout will be randomly different with fluctuating fail rates and actual fail numbers that it prints?

This is starting to paint some kind of picture. There is definitely a problem with interfacing the ISA bus in general, and not just with the palette read/writes.

I updated PALTEST.EXE with a couple of new tests to probe a bit more information about the issue. Can you give this updated version a go?

https://github.com/juj/crt_terminator/commit/ … 5cbd9989d219205

Hopefully that will tell us a bit more about where the root cause of the ISA interface problems could lie.

One more thing I notice is that you are on Windows 95. As a sanity check it might be good to try out real-mode DOS 6.22 to make sure there aren't any wholly unexpected things at play with Win95. (not sure what those could be, it should work there as well, just I haven't actually tested Windows 95 or newer with CRT Terminator, just on Windows 3.11)

clb wrote on 2025-02-04, 13:23:

I updated PALTEST.EXE with a couple of new tests to probe a bit more information about the issue. Can you give this updated version a go?

1) For testing, I've been booting straight into DOS, bypassing Windows loading. I've only been using my Windows CF card because it has easy network access to download new test files. 😀

2) The color issues persist even in the BIOS before the OS even loads. The palettes are entirely arbitrarily random. I've gotten a few times now where the initial bootup was black text on a black background through the Terminator, while of course will perfectly fine on the normal VGA output.

3) And yes, the errors seen while running the text are entirely random and different each time it is ran. Running it over and over again without rebooting or running anything else, and the error list changes.

4) Terminator has been tested in 3 separate ISA slots, all the same behavior. Card wont reach the 4th slot.

5) Other cards in the ISA slots work just fine, including the 3Com network card, Adaptec SCSI card, and SoundBlaster card.

Thanks for all the details, and the patience to persist to debug.

In the screenshot, I now see that the result from the first tests actually scroll outside the screen and are not visible in the screenshot. Were there any tests that would have showed a PASS, or did all the tests fail, even those that scrolled off the screen?

One hypothesis here is an ISA I/O address conflict with another device on the ISA bus. CRT Terminator uses ISA I/O address range 120h-12Fh.

If you haven't already, try removing any other ISA cards to see if that would affect the issue.

Also if there might exist any BIOS settings that might affect ISA bus communication, could be useful to try.

Another hypothesis is some kind of a timing issue with ISA bus reads or writes. The test [Test ISA bus Read no intr] in the beginning of the run might be able to help diagnose this.

Okay, this setup is getting super duper weird.

I disabled the onboard IDE controller and pulled all ISA cards from the machine.

Doing so, no more palette errors.... but even worse, no more palette reading -at- -all-

Putting in ANY ISA card into any slot, regardless of card (sound, modem, SCSI, NIC) would allow the Terminator to see palette updates again, but often corrupt.

But I noticed, despite some tests "passing" with all the cards removed, info from the Terminator card seems bokt? Just look at the reported version number from it!

I've also been testing with and without the paltsr just in case, but that changes very little.

Also, just now while uploading these pics, I realized that the two runs of "snoop" show wildly different model numbers for the card at the top.

The card looks like it gets stuck sometimes reporting 0xE8 for all responses. 0xE8E8 being 59624 value seen as well.

Voltage stability problem?

keenmaster486 wrote on 2025-02-06, 16:04:

Voltage stability problem?

I highly doubt it in my case. Symptoms don't line up. And when I've tested voltage stability for other things with this rig prior, it was perfectly fine. Additionally, I've put some serious hours into this machine without the CRT Terminator, and every other thing is functioning as expected.

I have however ordered more testing hardware so will be able to do a deeper dive here in a couple weeks.

Thanks, great data. That got me on the right track to look for issues.

I found one problem in the test program itself. On my 16MHz 286 PC (which I didn't originally see on my 80 MHz 486 PC), right after issuing an OUT I/O write command, I need to wait for a few NOPs, before issuing a IN I/O write command to read data back.

Otherwise without pausing between writes and reads, I got exactly the same problem as you were seeing - the reads would come out incorrect.

Uploaded a fixed test program now that adds 5 NOP commands after an I/O write, before issuing the next I/O read: https://github.com/juj/crt_terminator/commit/ … 2cfc9ae5R75-R79 . That fixes the test on my 286.

However, that is possibly not the root problem in the equation - but hopefully will help clear the smoke to zoom in to the remaining problems.

The hypothesis here is that there is an ISA I/O conflict with other hardware. And after removing the peripherals and the conflict, this test program problem unsurfaced.

So please give the above listed updated version a try. Hopefully it will start to report passes for the tests, and we can see what failures remain.

For the next steps, I am working on building a new firmware that has a battery of built-in diagnostics in it that can detect ISA bus conflicts, and allows disabling CRT Terminator's 8bpp palette path to rule out any conflict there. I'll post it soon once it is ready for testing.

clb wrote on 2025-02-06, 19:17:

Uploaded a fixed test program now that adds 5 NOP commands after an I/O write, before issuing the next I/O read: https://github.com/juj/crt_terminator/commit/ … 2cfc9ae5R75-R79 . That fixes the test on my 286.

Nope, still lots of "232" in every single returned value.

Oh, bummer. 😒

No trouble though, we do have a couple of leads on the root cause. I am working on a new firmware that should be done over the weekend. It will help diagnose these issues on the ISA bus from several different angles. I'll reply once that is ready (instructions for flashing are at https://oummg.com/manual/#firmware_update )

That should be able to help us differentiate whether there might be something incompatible with the motherboard or the integrated adapter, or whether to take the suspect to be a problem with the CRT Terminator card instead.

CircuitRewind wrote on 2025-02-07, 05:00:

clb wrote on 2025-02-06, 19:17:

Uploaded a fixed test program now that adds 5 NOP commands after an I/O write, before issuing the next I/O read: https://github.com/juj/crt_terminator/commit/ … 2cfc9ae5R75-R79 . That fixes the test on my 286.

Nope, still lots of "232" in every single returned value.

Hey CircuitRewind,

we now spent the weekend triaging the issue on a new series of motherboards (two XTs, one 286, one 386 with integrated graphics similar to the AST Bravo that you have). After stress testing, we did find some very interesting things, and uploaded a new firmware DV1000-2025.2.9 now, which is available here: https://github.com/juj/crt_terminator/tree/ma … n/firmware/dist

Firmware update instructions are available here: https://oummg.com/manual/#firmware_update

Important: With the new firmware DV1000-2025.2.9, the jumper J1 should be set to 1-2 for normal operation. (The jumper J1 now affects the ISA I/O base address for PALTEST.EXE diagnostics run, and 2-3 is recommended to only be used if issues with 1-2 mode occur - you can give both a test run in PALTEST.EXE)

Here is a more detailed report of our findings, for the curious:

1. Uncovered and fixed a timing issue where CRT Terminator might fail to observe an ISA bus write, if the ISA AEN signal would go high within a single bus clock cycle from the ISA bus IOW signal resetting high.

After a number of logic trace captures, we identified a programming error in CRT Terminator firmware, where the IOW and AEN signals were buffered incorrectly. If the motherboard would produce one clock cycle or less time between the two signals changing, CRT Terminator might incorrectly discard the ISA bus write request altogether. This issue was reproduced on a 16MHz 386SX machine with an integrated graphics card, similar to the integrated graphics setup on your system.

This issue was fixed in the DV1000-2025.2.9 firmware, and stress tested on six different motherboards to make sure that CRT Terminator will now correctly buffer the IOW and AEN signals without this issue. We hold hope that this might have been the very bug that your system was experiencing.

2. Added support for detecting ISA I/O bus conflicts.

In a previous comment, a root cause of ISA I/O bus conflicts was hypothesized. A new feature was added to CRT Terminator firmware to allow the card to detect if bus conflicts might occur during the PALTEST.EXE program runtime. New tests were added to the program to report if any other device might attempt to communicate in I/O address area 120h - 12Fh during the test run. Please check out the latest PALTEST.zip build at https://github.com/juj/crt_terminator/tree/main/DOS/bin

If rerunning PALTEST.EXE reports failures during any of the "read/write conflict" tests, try flipping jumper J1 (IOADDR) to state 2-3 (to relocate CRT Terminator from ISA I/O 120h-12Fh to 160h-16Fh), and rerun PALTEST.EXE to see if it helps. If flipping the jumper fixes the test runs to pass, then the root cause strongly looks like an ISA I/O conflict with another device.

If there are inconclusive suspicions of the issue being an ISA I/O bus conflict, the CRTT.EXE config tool has gained two new features to make CRT Terminator disable its 8bpp palette support, and/or disable the ISA I/O address range altogether to make it run in fully "passive" mode, disabling any CRTT->PC communication. This can help troubleshoot the root cause of the original palette flickering, if that still persists in the new firmware. CRTT.EXE can be downloaded in the same repository where PALTEST.EXE resides: https://github.com/juj/crt_terminator/tree/main/DOS

3. Revised ISA DATA and ADDRESS sampling logic to not rely so closely on ISA IOW cycle bus hold times.

In the latest screenshot you sent, we observed that all ISA bus writes failed on the CRT Terminator. While the original failures (where the failures were periodically recurring) look very much like could be caused by the fixed issue 1. above, we were not able to reproduce this complete failure mode of all tests in PALTEST.EXE failing, except by unseating the CRT Terminator card altogether. If this error persists, double check if CRT Terminator might have gotten unseated in the ISA slot, and try other ISA slot. (I know you mention you did try this already, though I was wondering if that was before removing other ISA cards, and unseating other ISA cards might have bumped CRT Terminator loose as well)

Ignoring "unseated card" guess, one hypothesis we had here is with respect to ISA bus DATA and ADDRESS signal timings. The data sheets for ISA bus timing logic mentions that the hold time for DATA and ADDRESS should be long enough to allow these signals to be sampled during IOW low->high edge. In some of traces that we see, this timing is cutting quite close. So we hypothesized whether on your affected system the timings could be skewed just enough so that the hold times do not match.

To guard against this, we added a bit of paranoia handling and revised the DATA and ADDRESS line sampling logic on CRT Terminator to not rely so closely to the specified hold times, but rather the signals are sampled a bit closer to the middle/center of the IOW cycle. If skew or jitter might be the culprit, then this change should help the issue on the new firmware.

Additionally, a self-diagnostics mechanism was added to CRT Terminator HUD to be able to time and report information about the ISA DATA and ADDRESS lines setup and hold with respect to the IOW bus.

If errors persist, if you would be able to make a screenshot or a video while running the command "PALTEST.EXE 15" (i.e. with cmdline argument number 15) while the Developer HUD is open. That will make CRT Terminator self-diagnose the bus timings on the card to see if something uncommon is happening there. A good spot to capture a screenshot will be at the following point:

with three distinct debug numbers showing on the first line of the HUD (in this case 5, 8 and -0). Those can give a clue for whether there might be something uniquely different occurring on this specific PC.

In summary, we hope that the fixes we did in the new firmware should help things along. I know the description above is a bit much, though hopefully CRT Terminator will start to work just by flashing the new firmware and doing nothing else. In case it doesn't, it would be helpful if you can give another PC a go, and see if it is any different there.

Apologies for all the troubleshooting cycles. Naturally if the card doesn't cooperate even after all these changes, the next steps can be to return the card for our physical inspection to see if there is something wrong in the assembly, and in that case, shipping a new one, or refunding are of course possibilities as well. In such an event, please shoot an email directly at oummgr@gmail.com so we can figure out the next steps.

Nelson68k wrote on 2025-01-22, 20:26:

Hello,
I received my CRT Terminator yesterday. Thank you very much. It works and provides a nice picture. Unfortunately the colors are wrong.
I have tested several ISA graphics cards and DVI monitors. On 286, 386 and 486 ISA systems. I have also tested different resolutions. On the 486 some colors are correct. But not all.

Hey Nelson68k,

if I understood your comment correctly, I got an impression that there may still have been some systems where CRT Terminator was not quite working out for you?

If so, check out the above comment for an updated firmware. I would love to hear how that firmware behaves on any of the affected systems you might still have.

clb wrote on 2025-02-09, 23:39:

Hey CircuitRewind,

we now spent the weekend triaging the issue on a new series of motherboards (two XTs, one 286, one 386 with integrated graphics similar to the AST Bravo that you have). After stress testing, we did find some very interesting things, and uploaded a new firmware DV1000-2025.2.9 now, which is available here: https://github.com/juj/crt_terminator/tree/ma … n/firmware/dist

I can let the pics speak for themselves 😉

So, one thing I've noticed, and this happened on the earlier firmware too: there is some subtle video corruption on the screen in various parts. It has always been very minor, but part of that corruption is up in the HUD itself, so I don't think it has anything to do with the video signals coming in from ISA/VGA. Thus far, I've been running in "pass-through" mode, and depending on the palette on the screen, the video corruption gets worse. Specifically, with my "Mario 64" desktop wallpaper on Win95 it gets noticeably very bad in the HUD, but still very similar on the actual desktop (I'd estimate less than 10px total?)

However, I just swapped over to forced 1280x960 output just as a test, and this issue appears to have gone away.

I've seen very similar video corruption issues on the RetroTINK 4K when pushing the FPGA's RAM access beyond its rated bandwidth limits. But that's what I find odd about this, its when running in a lower res, 640x480 w/o scaling, I get the corruption, but pushing the scaler harder, the corruption seemingly goes away.

And like I said, simply changing what palette is loaded (eg: opening a program that changes the Windows palette dynamically), the corruption gets better/worse depending on the palette, and it is very consistent between what palette is loaded and what the corruption looks like.

But otherwise, I'm super freaggin happy and excited to see this thing working! Don't worry one bit about the troubleshootings back n forth, I'm a hard-core hardware tinkerer. If this didn't resolve things, I've got a 250MHz Oscilloscope in the mail right now and had planned on checking the ISA clock timings as one of the very first tests with the thing 😀 While I may be new to this particular forum as a poster, I've been tinkering with these systems since back when they were still new! The handle "Circuit Rewind" was specifically chosen to reflect the hybrid between new and old tech, especially like your CRT Terminator, and I look forward to using it quite a bit for video capture going forward.

One more thing I'd like to mention, and this holds true with the older and new firmware (unchanged between the two)

24-bit RGB mode also works great with the CRT Terminator.

16-bit "High Color" mode however has colors that are super wonky.

And I do believe it was mentioned in the docs that these modes may not work, but I thought I'd share some light on why I think this is the case.

There are multiple "16-bit" color modes out there, with the 3 I'm most familiar with and have programmed in the past being: 555, 565, and 4444.

555 = 5-bit Red, 5-bit Green, 5-bit Blue, and 1 bit either unused, or used for alpha/processing effects.

565 = 5-bit Red, 6-bit Green, 5-bit Blue.

4444 = 4-bit Red, 4-bit Green, 4-bit Blue, 4-bit either unused, or used for alpha/processing effects.

I honestly have no idea how feasible it would be using the methods you're using to read the video RAM and palette data to also read the other DAC registers to acquire the exact video mode the card is operating in, as these Cirrus Logic cards appear to support both 555 and 565 according to their technical docs. These cards also support a 555/palette "mixed" mode that I've personally never encountered before until reading this data sheet, that looks overly complex and was probably never used.

Linked from https://www.vgamuseum.info/index.php/cpu/item … logic-cl-gd5422 there is the "Technical Reference Manual", and section Appendix B6 contains all the details of this information, and I've attached the first part of it here with an overview of the main high/true color modes.

clb wrote on 2025-02-09, 23:42:

I got an impression that there may still have been some systems where CRT Terminator was not quite working out for you?

Correct. I will be happy to do more tests at the weekend. I haven't updated the firmware yet.

CircuitRewind wrote on 2025-02-10, 01:06:

I can let the pics speak for themselves 😉

That is absolutely fantastic! So happy to see that we nailed this issue. Thank you so much for help on troubleshooting this, it could have taken very long otherwise for us to find out about the issue.

Let me try to ponder on your follow-up notes below.

CircuitRewind wrote on 2025-02-10, 01:06:

So, one thing I've noticed, and this happened on the earlier firmware too: there is some subtle video corruption on the screen in various parts. It has always been very minor, but part of that corruption is up in the HUD itself, so I don't think it has anything to do with the video signals coming in from ISA/VGA. Thus far, I've been running in "pass-through" mode, and depending on the palette on the screen, the video corruption gets worse. Specifically, with my "Mario 64" desktop wallpaper on Win95 it gets noticeably very bad in the HUD, but still very similar on the actual desktop (I'd estimate less than 10px total?)

However, I just swapped over to forced 1280x960 output just as a test, and this issue appears to have gone away.

I've seen very similar video corruption issues on the RetroTINK 4K when pushing the FPGA's RAM access beyond its rated bandwidth limits. But that's what I find odd about this, its when running in a lower res, 640x480 w/o scaling, I get the corruption, but pushing the scaler harder, the corruption seemingly goes away.

On CRT Terminator, the Passthrough mode and other upscaled video modes go through very distinct paths internally. With Passthrough mode, CRT Terminator operates on the pixel clock signal from the VGA adapter Feature Connector unchanged. In upscaled video modes, it synthesizes its own pixel clock for the upscaled video mode. In particular this affects the pixel clock that will be fed to the HUD rendering module.

If there are artifacts that only happen in Passthrough mode, it is possible that there is something about the pixel clock that does not quite fit the timing parameters that CRT Terminator expects. The HUD is a bit special that it has logic that blends 25%-75% in a dither pattern the background pixels against the HUD, so it is one of the "more involved" parts of the Passthrough pipeline. If the shape of the pixel clock signal, e.g. duty cycle or setup/hold timings of the clock are not quite as expected, then that might cause this kind of an issue.

Then when switching to an upscaled mode, the use of the Feature Connector pixel clock is limited to sampling the video into a framebuffer, and the HUD rendering will use its own synthesized pixel clock, which has predetermined timings.

Examining the Pixel Clock line of the Feature Connector output from the VGA adapter might give clues on what the signal quality there is like. Pinout of the Feature Connector can be found at https://oummg.com/manual/#appendix_a_ibm_vga_ … ature_connector

CircuitRewind wrote on 2025-02-10, 01:06:

And like I said, simply changing what palette is loaded (eg: opening a program that changes the Windows palette dynamically), the corruption gets better/worse depending on the palette, and it is very consistent between what palette is loaded and what the corruption looks like.

This kind of behavior can happen if the Feature Connector pixel data lines are not getting sampled just right with respect to the pixel clock. (that is, either the pixel clock is skewed, or pixel data is skewed with respect to pixel clock). In the 8-bit digital color line, if the timings are off on one of the bits, then an 8-bit palettized color, say, EEh, if it is sampled incorrectly, might flip just one bit, to EFh, which might represent a completely different color altogether. So if pixel sampling artifacts occur, the artifacts can be dependent on the colors of two adjacent horizontal pixel pairs, and what the transition byte values between those are, and what corrupt palette entry one might get to by mixing some bits from the old and new palettized pixel color.

One thing to play with here is to try adjusting the signal sampling phase settings (jumpers J2-J6) on the card. E.g. try disabling the automatic sampling phase setting (J2), which then enables manually toggling the Pixel Data sampling phase jumper (J3). Some adapters want their pixel data sampled on low->high edges, other adapters expect to be sampled at high->low transitions. CRT Terminator tries to autodetect which one works better (by sampling the pixel data at > Nyquist x2 rate and detecting at which edge the pixel colors are more stable), but this might not be 100% precise in all scenarios.

Also it will be interesting to try out another VGA adapter to see how that behaves.

CircuitRewind wrote on 2025-02-10, 01:06:

But otherwise, I'm super freaggin happy and excited to see this thing working! Don't worry one bit about the troubleshootings back n forth, I'm a hard-core hardware tinkerer. If this didn't resolve things, I've got a 250MHz Oscilloscope in the mail right now and had planned on checking the ISA clock timings as one of the very first tests with the thing 😀 While I may be new to this particular forum as a poster, I've been tinkering with these systems since back when they were still new! The handle "Circuit Rewind" was specifically chosen to reflect the hybrid between new and old tech, especially like your CRT Terminator, and I look forward to using it quite a bit for video capture going forward.

Rock on, no doubt that gear will be useful soon 😀

CircuitRewind wrote on 2025-02-10, 05:25:

One more thing I'd like to mention, and this holds true with the older and new firmware (unchanged between the two)

24-bit RGB mode also works great with the CRT Terminator.

This is great to hear. I spent several months implementing hi-color and true-color support, but the reason we kept this low-key is that the VGA adapter support is quite spotty: Feature Connector was never officially intended to do hi-color or true-color, so it requires a very particular adapter that happens to have implemented those modes in a compatible way, for it to work.

Though now with CRT Terminator (S)VGA Adapter Conformance Suite being published, maybe it can paint a more complete picture of which adapters can work in practice.

CircuitRewind wrote on 2025-02-10, 05:25:

16-bit "High Color" mode however has colors that are super wonky. […]
Show full quote

16-bit "High Color" mode however has colors that are super wonky.

And I do believe it was mentioned in the docs that these modes may not work, but I thought I'd share some light on why I think this is the case.

There are multiple "16-bit" color modes out there, with the 3 I'm most familiar with and have programmed in the past being: 555, 565, and 4444.

555 = 5-bit Red, 5-bit Green, 5-bit Blue, and 1 bit either unused, or used for alpha/processing effects.

565 = 5-bit Red, 6-bit Green, 5-bit Blue.

4444 = 4-bit Red, 4-bit Green, 4-bit Blue, 4-bit either unused, or used for alpha/processing effects.

CRT Terminator implements support for 555 and 565 modes, although this is indeed a bit off to the experimental/no-guarantees realm . While going through the different adapters, I did not see any card outputting a 4444 mode, so that is not available.

The distinction between 555 and 565 is currently done by video signal analysis: If the input video signal is two bytes per pixel, and has bit 15 always 0, then the mode is interpreted to be a 555 mode. Otherwise if there is entropy in bit 15, then it is detected as a 565 mode.

One cause for colors being off could be that 555 vs 565 is misdetected. The Developer HUD will show which mode CRT Terminator thinks the current video mode is in, by showing either "15b" or "16b" in the colors section: 15b for 555, and 16b for 565. So in the screenshot you post, CRT Terminator is seeing the mode to be a 565 mode.

Although here I am a bit puzzled by the image, since the color artifacts do not look like a typical 555 vs 565 mismatch (or maybe the bits just happen to fall out in a way that the grayscale dialog looks still similarly grayscaleish). I wonder if this might instead be some kind of a gamma or ICC color curve setting that Windows 95 has.

Nevertheless, try testing different Windows/DOS software/games that run in 15bpp or 16bpp mode, or VESA video mode test utilities. The SEA image viewer on the conformance suite page is a good DOS test program to use, hopefully it'll also work from Windows 95 cmd prompt.

CircuitRewind wrote on 2025-02-10, 05:25:

I honestly have no idea how feasible it would be using the methods you're using to read the video RAM and palette data to also read the other DAC registers to acquire the exact video mode the card is operating in, as these Cirrus Logic cards appear to support both 555 and 565 according to their technical docs. These cards also support a 555/palette "mixed" mode that I've personally never encountered before until reading this data sheet, that looks overly complex and was probably never used.

Linked from https://www.vgamuseum.info/index.php/cpu/item … logic-cl-gd5422 there is the "Technical Reference Manual", and section Appendix B6 contains all the details of this information, and I've attached the first part of it here with an overview of the main high/true color modes.

The 555/palette mixed mode was used to allow overlaying hi-color MPEG video onto a palettized 256-color desktop (or vice versa). That enabled MPEG video in different video pixel formats to always be able to play back, even when the color depth of the desktop wouldn't match with the video. I don't think any games or software directly ever used this mode, but it was just a mechanism to feed both hi-color and palettized data simultaneously to the RAMDAC.

Many moons ago I tried to implement support to CRT Terminator to snoop the programming of the Cirrus Logic GD5422 RAMDAC register from the ISA bus, though there were problems that those bus writes would not always occur when changing a video mode. That is, there was something else that took place on video mode change that didn't seemingly go through the hidden RAMDAC register mechanism, so it wasn't 100% complete.