MacOSMonkey
Well-known member
Weird. Lots of information!
A couple of issues:
1. The board has a default gamma table that is going to affect what you see on screen (but not the values in RAM). The default for all of these boards is usually the Apple Standard RGB Monitor Gamma. See Cards & Drivers. It derives from early trinitron monitors. If you want to change it, open the Monitors cdev and hold down the option key (you should see a smiley for the boot screen) -- then, double-click on the gray monitor region for the card. Then, choose "Uncorrected Gamma". You should also see any other gammas that the board (or system) has to offer. This topic is peripheral to the actual problem, but if you disable gamma correction, you should see pixel values on screen (via the board's DAC) that represent the uncorrected phosphor beam response. Gamma correction attempts to simulate a linear response -- or when using products like SuperMatch, helps to mimic certain lighting environments (D50, D55, 9500K, etc.) and harmonize the appearance of print color vs. screen/light/transmitted color (after calculating the phosphor response for a specific display).
2. After writing all 0's are you seeing the same values appear repeatedly, or do you see random results?
For example, if the first pixel is: 0x00008086 after writing all 0's and you then write 0x00224466 and see 0x00a2c4e6 (but also where you sometimes see an $80 is green and blue components -- but never red), you may be seeing stuck pixels that are OR'd into the response:
in : b0000 0000 0010 0010 0100 0100 0110 0110 (0x00224466)
out: b0000 0000 1010 0010 1100 0100 1110 0110 (0x00a2c4e6)
0's: b0000 0000 P000 0000 1000 0000 1000 0110 (0x00008086)
diff: b0000 0000 N000 0000 X000 0000 X000 0UU0
P = present in some of the corrupted 0 writes (green and blue, maybe it happens in red also and is just random), X = bit present in 0 write at the same address, U = Undetectable since the bit pattern is the same as the 0 corruption pattern
Some tests you could do here might be:
1. to continuously write 0's at a fixed location and read back the data to see if the bad pattern is always the same.
-- this test helps to confirm if the problem is random or fixed.
2. to check to see if you always see a certain failure, like x00008086 instead of 0x00000000 at the base address as in #1, then write 0x00007f79 and see if you consistently read back 0x0000ffff.
-- this test helps to confirm whether or not the problem is input data-dependent. If you read back 0x0000ffff, then you know the problem is likely data independent. If the bad bits change depending on source data, then that's another clue.
And to try to stay out of the rabbit hole -- just to make sure I understand what you have said -- have you checked that the RAM holds the correct data by looking at the RGB components on the scope directly at the VRAM device...and then looking at what is being read back on the scope at the VRAM device on a read? You can't filter the SMT02 out on the write, but you can filter it out for the read - it's just an initiator -- and you can immediately capture the read data (and verify that the transfer waveform is correct).
Some examples:
- If you see bad write data going into the VRAM device, then you know that there is a problem in the data path
- If the input data and wave form are correct and you read back corrupted data with a correct waveform, then the device may be bad
- If you saw bad data going in and you read the same bad data at the device coming out, then you know device reads are probably OK
- If you read back the same corrupted data at the device and across Nubus, then you know that Nubus reads are OK, etc.
- If you read back good data at the device and good data went in, then you know that the VRAM R/W is OK and that the read back across Nubus has a problem somewhere.
Try to bracket as much as possible to save time and pin down the problem.
I see that you verified the address lines. After you have definitely confirmed the data/data lines at the VRAM device, then, as you say, you should look at the same data on the write and read cycles on Nubus. See Cards and Drivers for the expected waveforms. There could be a timing or data bus issue. But, phenotypically, because you are seeing columns of bad data on the screen, it implies that there is a data write/translation problem (as you have already confirmed by the current read-back tests).
Hope this helps.
A couple of issues:
1. The board has a default gamma table that is going to affect what you see on screen (but not the values in RAM). The default for all of these boards is usually the Apple Standard RGB Monitor Gamma. See Cards & Drivers. It derives from early trinitron monitors. If you want to change it, open the Monitors cdev and hold down the option key (you should see a smiley for the boot screen) -- then, double-click on the gray monitor region for the card. Then, choose "Uncorrected Gamma". You should also see any other gammas that the board (or system) has to offer. This topic is peripheral to the actual problem, but if you disable gamma correction, you should see pixel values on screen (via the board's DAC) that represent the uncorrected phosphor beam response. Gamma correction attempts to simulate a linear response -- or when using products like SuperMatch, helps to mimic certain lighting environments (D50, D55, 9500K, etc.) and harmonize the appearance of print color vs. screen/light/transmitted color (after calculating the phosphor response for a specific display).
2. After writing all 0's are you seeing the same values appear repeatedly, or do you see random results?
For example, if the first pixel is: 0x00008086 after writing all 0's and you then write 0x00224466 and see 0x00a2c4e6 (but also where you sometimes see an $80 is green and blue components -- but never red), you may be seeing stuck pixels that are OR'd into the response:
in : b0000 0000 0010 0010 0100 0100 0110 0110 (0x00224466)
out: b0000 0000 1010 0010 1100 0100 1110 0110 (0x00a2c4e6)
0's: b0000 0000 P000 0000 1000 0000 1000 0110 (0x00008086)
diff: b0000 0000 N000 0000 X000 0000 X000 0UU0
P = present in some of the corrupted 0 writes (green and blue, maybe it happens in red also and is just random), X = bit present in 0 write at the same address, U = Undetectable since the bit pattern is the same as the 0 corruption pattern
Some tests you could do here might be:
1. to continuously write 0's at a fixed location and read back the data to see if the bad pattern is always the same.
-- this test helps to confirm if the problem is random or fixed.
2. to check to see if you always see a certain failure, like x00008086 instead of 0x00000000 at the base address as in #1, then write 0x00007f79 and see if you consistently read back 0x0000ffff.
-- this test helps to confirm whether or not the problem is input data-dependent. If you read back 0x0000ffff, then you know the problem is likely data independent. If the bad bits change depending on source data, then that's another clue.
And to try to stay out of the rabbit hole -- just to make sure I understand what you have said -- have you checked that the RAM holds the correct data by looking at the RGB components on the scope directly at the VRAM device...and then looking at what is being read back on the scope at the VRAM device on a read? You can't filter the SMT02 out on the write, but you can filter it out for the read - it's just an initiator -- and you can immediately capture the read data (and verify that the transfer waveform is correct).
Some examples:
- If you see bad write data going into the VRAM device, then you know that there is a problem in the data path
- If the input data and wave form are correct and you read back corrupted data with a correct waveform, then the device may be bad
- If you saw bad data going in and you read the same bad data at the device coming out, then you know device reads are probably OK
- If you read back the same corrupted data at the device and across Nubus, then you know that Nubus reads are OK, etc.
- If you read back good data at the device and good data went in, then you know that the VRAM R/W is OK and that the read back across Nubus has a problem somewhere.
Try to bracket as much as possible to save time and pin down the problem.
I see that you verified the address lines. After you have definitely confirmed the data/data lines at the VRAM device, then, as you say, you should look at the same data on the write and read cycles on Nubus. See Cards and Drivers for the expected waveforms. There could be a timing or data bus issue. But, phenotypically, because you are seeing columns of bad data on the screen, it implies that there is a data write/translation problem (as you have already confirmed by the current read-back tests).
Hope this helps.