Thread by @TubeTimeUS

here's an interesting package that came in from Bulgaria! let's find out what's inside...

haha this box used to be a different box 😂

it's an IBM EGA graphics card!

it umm appears to have been banged around a bit. probably placed back to back with another card and scratched up

hmm it mostly works though! small problem with vertical lines. what could that be caused by?

weirdly, it works fine in graphics mode!

since the RAM seems to work, i think the problem is somewhere else. but first i need to figure out how characters are displayed in text mode.

the EGA has an internal 32-bit data path! the RAM is split into two sets of 16 bits each, and those are split further into 4 sets of 8 bits each. each set is a bit plane, called MAP0, MAP1, MAP2, and MAP3.

in graphics modes, each plane represents one bit of the 4 bits that make up a pixel. ignoring the palette, that means we have one plane for R, one for G, one for B, and one for intensity.

so if i only write to a single plane, then each byte represents the red bits of 8 consecutive pixels. another way to look at it is that each plane is a monochrome bitmap. layer 4 of them, and you get all the colors you need.

text mode uses only two of those planes, MAP0 and MAP1. MAP0 is the character code and MAP1 is the attribute byte.

but there's no separate character ROM, or RAM! so how does the EGA handle turning the character codes into pixel data?

the character codes are stored in a bit plane, MAP2! they let you do tricky things like storing multiple character tables, or reassigning an attribute bit so that you can have a character set with 512 possible characters.

ok, so how does that character pixel data get loaded? there's a set of latches that takes the data from MAP0 as well as RS, which is the current character row (14 total, but the EGA can do up to 32). the output of those latches becomes the address for MAP2!

so perhaps it is a stuck bit in the MAP2 plane. but graphics mode uses this plane too, and it works fine there. 🤔

looks like in graphics mode, the attribute LSI gets 4-bit data directly from the two graphics control LSIs (C0, C1, C2, and C3). only in text mode does the attribute LSI use the M2Dx path circled in red. seems like a logic step would be to ohm out those connections...

and it ohmed out just fine. the plot thickens!

time for the big guns.

i'm using an alternating pattern of a filled character block followed by an empty block. this is what i get.

shift/load# latches the data on m2dx on the falling edge. looks like valid data to me. so this is a problem in the custom chip. bummer. (pixel data is bottomost trace, you can see the "vertical line".)

must be an internal short. notice how the pixel glitch is a 20ns delayed+inverted version of the shift/load# signal?

so there you have it. a bad attribute LSI (custom chip). this is bad news...

...but also good news, because now i can tear this card apart without feeling bad about it.

well you see I have another EGA card, bit it actually works, and it has the RAM expansion!

chip removed.

socket installed

"new" chip installed. let's see if this fixed it

yup! so the chip went bad somehow.