So as we saw in the previous blog, we have an image being drawn in the framebuffer, and the colors set. 

The problem though, I noticed that some of the colors either not being set, or kept flipping to different colors after they were set. I started doubting my framebuffer command that I was sending, or my setup and started to get frustrated. 

But then it suddenly dawned on me. Maybe this was the degradation that started happening to alot of these machines later in their lives. This was acting very similarly. 

Here are some well-known cases of it going on in the field: 

Here is a picture of one in my files that also had problems: 

Here is another one a friend of mine owns which is running my software:

So my mind quickly shifted from being a problem on my end with my experiments, to the potential of hardware failure. 

Now giving my troubleshooting skills are very sharp, and I have repaired electronics for years and years prior to this point, I had a pretty good idea right where to go to. 

the RAMDAC. So, on an indexed-color system, most graphics cards from this era have whats called a RAMDAC. the RAMDAC means Random Access Memory Digital to Analog Converter. 

Without forcing you all to go to wikipedia, the nutshell is basically this. the RAM of RAMDAC means there is a small section of SRAM inside the chip which holds the R, G, B values for each color index starting from 0, up to 255. DAC is the analog converter. it takes the digital R,G,B values that are stored in the SRAM lookup table, and then applies those as a voltage or current. the higher the number for each R,G,B value, the higher the voltage/current level is on the output. and 0 being no output. Each value from 0 to 255 is applied from the bus through an 8-bit port. This is known as the index. this index will pick which slot to apply to the DAC output with that slot's programmed color values. There are also mask registers, etc but i don't want to get into that, and the 4000 doesn't use them anyway. 

Pretty straight forward. 

With the colors suddenly and spontaneously changing from their set values, or unable to be changed, points me to believe the SRAM inside the RAMDAC has failed in some rather unique way. So it is unable to retain its set RGB values. so bits will flip. when bits flip states, its going to change the color for that index value.

So the next step at this point is to just basically replace the BT471. 

However there is a catch. the BT471 is hard to find since it wasnt commonly used. Everyone used the BT478, as it supports full 8bit RGB. 

So, i bought a few of the BT478s on ebay. I figured why not, plus it can upgrade the possible number of colors to its mask! or so i thought. 

I put the new chip in, but the picture was very dark. I even sent full RGB888 values, and the picture was still very dark. 

So i took a peek at the ROM, and sure enough this little bit here stands in the way: 

If you look at that, you can see the anl 0x3F opcode. That basically clips off the byte value and keep it as 6 bits. So damn.... So much for full 8bit RGB. haha. Those operations are peppered everywhere in ROm so its not as simple as just patching that bit out. 

So i left it be. I figured i was going to need to replace the BT471 with another 471. 

Turns out, studying the datasheet there is a pin which you can connect to ground, and it forces the chip to run in backwards-compatible RGB666 mode! 

So, lets do that! 

Here is the new chip installed. 

Turns out, the pin I needed to ground was right next to a ground. So i didnt even need a bodge wire. the pin was unconnected on the original design as well, so all I did was lay down a solder blob to ground the pin. 

Time to see if it worked: 

BOOM fixed! that's exactly what it was. Although there is still some color noise, but that was due to the graphics card itself rather than the RAMDAC. 

So that was exactly the cause. the SRAM cells start failing in the BT471 chips over time. So any degraded unit you saw back in the day, this was the cause. 

Perfect. Now we can move on....