I consider the checkit raster bar picture to be the most insightful one. Let's start by looking at the CGA schematics in https://minuszerodegrees.net/oa/OA%20-% ... 0(CGA).pdf :
- Page 1, at the top: Generation of the "Alpha Dots" signal. That signal decides what pixels get the background color and what pixels get the foreground color in text mode. This is working perfectly.
- Page 1, CRTC: Video timings are stable, just the image content is broken. It seems the correct bytes are fetched. The CRTC is most likely not the culprit
- Page 1, Video RAM address latches: Video memory check passes, checkit passes text mode tests. Both the CPU address latch and the CRT address latch are fine.
- Page 1, Video RAM: Checkit passes. Fine.
- Page 1, Logic at the bottom: Graphics mode bank addressing generator. Works.
- So the fault is most likely on no component of page 1!
- Page 2: The fault might actually be here, but we can exclude text mode stuff.
- Page 2: U36/U37 are used to read/write memory. They are fine.
- Page 2: U34/U35 are used to latch character and attribute bytes in text mode. They are fine. They also latch byte pairs in graphics mode (8 lowres pixels or 16 highres pixels)
- Page 2: U32/U33 is the character generator, which works perfectly.
- Page 2: U24 provides the status register (3DAh), which is not related to the issue and likely works.
- Page 2: U39 is the color select register. The color select register contains a color that is displayed instead of black in the low-res graphics mode. We see weird colors instead of black in the checkit grid screen behind characters. While I suspect that the logic that evaluates the color select register is more likely to be broken, we are getting closer.
- Page 2: U7/U8: These chips are only used in graphics mode. They directly convert 16 bits of video memory into 8 bit pairs (8 low-res pixels or 16 high-res pixels). Add them to the suspect list as well.
- Page 2: U9/U10: These chips control the output color on a pixel-by-pixel basis. U9 is for R & G, U10 is for B & I. They multiplex four different inputs to the output. Input 1 is textmode background color, Input 2 is textmode foreground color, Input 3 is the CGA graphics mode pixel color on U9 and the CGA palette selection on U10, finally input 4 is the color from the color select register. The inputs are selected using MUX A and MUX B, which are generated by a lot of discrete TTL logic on page 4. Another set of chips to be added to the list of suspects.
- Page 2: U101: Video output buffer and reset generator. This chips works.
- Page 3: Timing generation and address decoding. Probably fine. While false selection of the color select register may cause funny colors in graphics mode, it would most likely also cause funny things with the border/overscan color in text mode.
- Page 4: This page is a beast. Let's look at generated signals (on the right) instead of the logic.
- Page 4: RAS/CAS enable signals: obviously fine.
- Page 4: CC latch: Works the same in graphics mode and text mode, should be fine.
- Page 4: AT latch: Is generated differently in text and graphics mode. Keep in mind.
- Page 4: WE..RD GATE: not related to scanout. Fine.
- Page 4: SEL BLUE: In low res graphics mode, it is the palette selection bit, which directly controls the blue channel (cyan/magenta/white has blue, red/green/yellow has no blue). As the issues are not isolated to the blue channel, unlikely to be wrong.
- Page 4: CCLK/DOT CLOCK/: General video timing. Works.
- Page 4: BW1/BW2: Black/White control signals. Mostly for the composite video generator. Irrelevant.
- Page 4: MUXA/MUXB: Might be interesting, as these signals control the choice of the pixel color multiplexers
- Page 4: STR: Might be interesting to think about. This signal is used to force black output, and as I understand it, it might be the way "black" is implemented in high-res gfx.
- Page 4: ENABLE_BLINK, GRPH, HRES, VIDEO_ENABLE: Mode control signals. Possibly messed up, but we will get to them if we look at the chips controlled by them.
- Page 5: Video output stage and some signal timing generator. Independent from text/graphics switch. Should work fine.
- Page 6: Connectors and minimal ISA interface stuff. Works fine.
So I am confident to have narrowed down the issue to the area around the color multiplexers and the graphics shift registers. Now take a deep look at the CheckIt grid screen. While the image uses the 4-color graphics mode, it is actually supposed to be black/white (which it obviously isn't). But note that every 8-pixel chunk (e.g. one scanline in one character) is always only two colors. This means the weirdness is related to something that gets updated every 8 pixels, i.e. at the "character clock" in which the shift registers get reloaded. The bad colors relate to pattern of pixels. Wherever you see vertical structures, the color doesn't change. The text is blue or pink. The background is is black, red, green or brown (red+green).
For background pixels, both multiplexers should be switched to "overscan color", by MUX A and MUX B being both high. MUX B is supposed to be high if either of these conditions apply: (a) The card is in graphics mode or (b) overscan duration in text mode. MUX A is high in low res graphics if color 0 is to be displayed and in text modes for "foreground pixels". If MUX A was low instead of high (color 0 recognition fails), blue/intensity would come from the palette select instead of the background color register, and red/green would be off anyway, as color 0 is to be displayed. We see false red/green in the pixel, so it can not be explained by a bad MUX A signal. Now, with MUX B being low instead of high, the graphics background color would be replaced with the text background color, which is generated from the top 4 bits of the second byte of an 8-pixel group (where the text-mode background color would be stored in an attribute byte). As only background and white pixels are used, this would limit bad background colors to cyan, bright red and white, which is not what we see. So MUX B is likely correct as well. But hold on a second! What if only the red/green multiplexer fails to get MUX B? In that case, red/green would be generated like in text mode, while blue/intensity would be generated correctly.
That's actually what we see: blue is correct: It's only present where gray pixels should be. Also intensity is correct: It's always absent. red/green for gray pixels would be generated from the foreground text color for gray pixels, yet we mostly see only red, but no green on the text forground. Looking deeper into it, the green bit for the text foreground color is generated from the eight (rightmost) pixels of an 8 pixel group, which is usually black if you are displaying text! In inverted text (like the "Y" after "corrext?") that pixel is gray, though. And see what? At that point, we do get white pixels as foreground! So this indeed looks very much as if the red/green multiplexer U9 selects between "text foreground" and "text background" instead of "pixel value" and "graphics background". As TTL inputs that are unconnected due to broken traces or bad contacts in sockets are seen as high, and the image looks like pin 2 of U9 is stuck low, this most likely means U9 is defective.
