I loaded the Diagnostics 4.0.1. It looks like the diagnostics for the Professional IRIS "CLOVER1" graphics are a close relative or even exactly the manufacturing acceptance test.
In this initial run it was throwing an error on 2 of the 17 GE chips on the GF3 board but I think this was only because I ran the Diagnostics directly after killing the X11 server rather than rebooting the system first. It never did it again.
It wasn't happy about the DE3 board either:
Code:
twintower 35# bitplanes/bperrors
ERROR REPORT
total errors 0, read 0, write 0, weird 0
pixel errors: ....................
1111
0123456789abcdef0123
module errors: ....................
1111
0123456789abcdef0123
+----+----+----+----
BLUE GRN RED WINDOW
plane errors: ................................
1111111111111111
0123456789abcdef0123456789abcdef
+-------+-------+-------+-------
RED GREEN BLUE WINDOW
Bitplanes, read: 0 Errors
Bitplanes, write: 0 Errors
Bitplanes, weird: 0 Errors
Bitplanes, line: 0 Errors
Bitplanes, pattern: 0 Errors
Bitplanes, colorwe: 0 Errors
Bitplanes, scrmsk: 0 Errors
Bitplanes, stipple: 0 Errors
Bitplanes, dda: 0 Errors
Bitplanes, stripe: 10200 Errors
It also frowned on the TB2 ("display generator") board:
Code:
Manf-DIAGS> test.tb
1. (25 secs) auxtb Comprehensive TB test
Test 0
writing lo 8 address bits.......
reading...........
address= 0 got=80 expected=0 (got xor expected)=80 bank=1 DAC:blue
address= 1 got=81 expected=1 (got xor expected)=80 bank=1 DAC:blue
address= 2 got=82 expected=2 (got xor expected)=80 bank=1 DAC:blue
address= 3 got=83 expected=3 (got xor expected)=80 bank=1 DAC:blue
address= 4 got=84 expected=4 (got xor expected)=80 bank=1 DAC:blue
address= 5 got=85 expected=5 (got xor expected)=80 bank=1 DAC:blue
[...]
address= f7e got=fe expected=7e (got xor expected)=80 bank=1 DAC:blue
address= f7f got=ff expected=7f (got xor expected)=80 bank=1 DAC:blue
address= 0 got=1 expected=0 (got xor expected)=1 bank=3 DAC:blue
address= 2 got=3 expected=2 (got xor expected)=1 bank=3 DAC:blue
address= 4 got=5 expected=4 (got xor expected)=1 bank=3 DAC:blue
address= 6 got=7 expected=6 (got xor expected)=1 bank=3 DAC:blue
address= 8 got=9 expected=8 (got xor expected)=1 bank=3 DAC:blue
address= a got=b expected=a (got xor expected)=1 bank=3 DAC:blue
address= c got=d expected=c (got xor expected)=1 bank=3 DAC:blue
address= e got=f expected=e (got xor expected)=1 bank=3 DAC:blue
address= 10 got=11 expected=10 (got xor expected)=1 bank=3 DAC:blue
address= 12 got=13 expected=12 (got xor expected)=1 bank=3 DAC:blue
address= 14 got=15 expected=14 (got xor expected)=1 bank=3 DAC:blue
[...]
address= ffc got=fd expected=fc (got xor expected)=1 bank=3 DAC:blue
address= ffe got=ff expected=fe (got xor expected)=1 bank=3 DAC:blue
Test 1
writing hi 8 address bits.......
reading...........
address= 0 got=8 expected=0 (got xor expected)=8 bank=1 DAC:blue
address= 1 got=8 expected=0 (got xor expected)=8 bank=1 DAC:blue
address= 2 got=8 expected=0 (got xor expected)=8 bank=1 DAC:blue
[...]
address= f7e got=ff expected=f7 (got xor expected)=8 bank=1 DAC:blue
address= f7f got=ff expected=f7 (got xor expected)=8 bank=1 DAC:blue
Test 2
writing ff........
reading...........
Test 3
writing 0........
reading...........
Test 4
writing 55........
reading...........
TB test, Auxtb: 6144 errors
2. (20 secs) auxtest DE pmap test
reading...........
Auxtest: total 0 errors
TB test, Auxtb: 6144 Errors
Errors found on TB
Manf-DIAGS>
At first I didn't see anything obviously wrong with the display output, but once you run several GL applications at the same time and start cycling through the windows, it started to show blue lines on the screen depending on the window focus. It's not like a "pinstripe of death" which results in a repeating pattern of vertical lines or pixel patterns across the screen, it's restricted to a window:
If you look carefully you'll see that the vertical lines happen every fifth column of pixels:
This is probably not an accident. The "Display Subsystem" (which is on the TB board) is implemented 5-way parallel. Now, the "Display Subsystem" section in the Technical Report says:
Five multiplexed Multi-Mode Graphics processors (MGP) concurrently read the contents of the Image and Window planes [...] Made possible by massively parallel access, MGP allow simultaneous display of up to 64 different windows in various color modes
But the logical division in the diagram (geometry, rendering and display subsystem) doesn't map 1:1 on the GF3, DE3 and TB2 boards. For one thing, the 68020 (the Geometry Manager) and it's 1MB shared memory are clearly on the GF3, not on the DE3. But more relevantly, the DE3 contains 5 XBAR and 5 PMAP ASICS. I think the XBARs are the 5 fat dots between the Image Planes and the MGPs. And the PMAPs likely integrate MGP and color maps. The TB2 board on the other hand isn't very exciting, there's just a ton of TTL buffers and bus transceivers and the actual DAC chips.
I decided to focus on the DE3 board since it's the first in the pipeline to fail. I pulled all the VRAM SIMMs. These are not regular DRAM, they are completely custom. The chips are dual ported VRAM and they're 64 pins I think. Upon closer inspection, some of the gold contacts looked rather sad. I cleaned the sockets and SIMMs with pure alcohol and applied DeoxIt Gold to the contact edge of the SIMMs. A day later I wiped off the excess product and the contacts look good as new again. This stuff really works. I installed the VRAM SIMMs in reverse order I took them out; if the errors move to a different address I know it's related to the VRAM sticks. At the same time I also treated the pins of the front interconnect that bridges the DE3 and TB2 boards with DeoxIt Gold.
The outcome was initially disappointing. It still throws 10200 errors on the DE3 "stripetest". But I couldn't figure out what was causing them because every individual test seems to work.
The tests are shell scripts. The test.de script calls several programs to initialize the hardware, then runs the indiviual tests in batch mode, and finally prints a report. I decided to run all of it by hand, printing reports after each test in order to find out where the errors were introduced. Predictably, it was the stripetest that was causing stripe test errors ;-) The thing is, it doesn't fail at all:
Code:
8. (60 secs) stripetest bitplane stripetest
STRIPETEST - bitplane:24 duration:1 iterations:1
STRIPETEST - bitplane:25 duration:1 iterations:1
STRIPETEST - bitplane:26 duration:1 iterations:1
STRIPETEST - bitplane:27 duration:1 iterations:1
STRIPETEST - bitplane:28 duration:1 iterations:1
STRIPETEST - bitplane:29 duration:1 iterations:1
STRIPETEST - bitplane:30 duration:1 iterations:1
STRIPETEST - bitplane:31 duration:1 iterations:1
STRIPETEST - bitplane:32 duration:1 iterations:1
STRIPETEST - bitplane:33 duration:1 iterations:1
STRIPETEST - bitplane:34 duration:1 iterations:1
STRIPETEST - bitplane:35 duration:1 iterations:1
STRIPETEST - bitplane:36 duration:1 iterations:1
STRIPETEST - bitplane:37 duration:1 iterations:1
STRIPETEST - bitplane:38 duration:1 iterations:1
STRIPETEST - bitplane:39 duration:1 iterations:1
skipping bitplane 40: sigplanes
skipping bitplane 41: sigplanes
skipping bitplane 42: sigplanes
skipping bitplane 43: sigplanes
skipping bitplane 44: sigplanes
skipping bitplane 45: sigplanes
skipping bitplane 46: sigplanes
skipping bitplane 47: sigplanes
STRIPETEST - bitplane:48 duration:1 iterations:1
STRIPETEST - bitplane:49 duration:1 iterations:1
STRIPETEST - bitplane:50 duration:1 iterations:1
STRIPETEST - bitplane:51 duration:1 iterations:1
STRIPETEST - bitplane:52 duration:1 iterations:1
STRIPETEST - bitplane:53 duration:1 iterations:1
STRIPETEST - bitplane:54 duration:1 iterations:1
STRIPETEST - bitplane:55 duration:1 iterations:1
STRIPETEST .=Not tested, e=Error, ?=Software Error
RED............ GREEN.......... BLUE........... WINDOW.........
2 3 4 5
Bitplane 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
Chips
0 . . . . . . . .
1 . . . . . . . .
2 . . . . . . . .
3 . . . . . . . .
4 . . . . . . . .
Stripetest Total Errors = 0
But afterwards, this line is added to the error report nonetheless:
Code:
Bitplanes, stripe: 10200 Errors
However, the TB2 test now succeeds:
Code:
FE-DIAGS> test.tb
1. (25 secs) auxtb Comprehensive TB test
2. (20 secs) auxtest DE pmap test
No errors detected in tests that ran on TB
And lo and behold, no more stripes:
I'm not sure how worried I should be about a DE3 test that succeeds while adding 10000 failures to the report and not showing visible artifacts on screen. It's possible that the test doesn't fully deal with the fact that this system has only 15 of the 20 VRAM slots filled for example. I guess I won't know for sure unless I discover artifacts later or find another DE3 board.
There are very very few CLOVER1 systems remaining worldwide. The only one I know for sure is owned by Gerhard Lenerz and has been
dead for 15 years.
MIMMS
has a 4D/50 but it's graphics configuration and operational status is unknown.
The Computer History Museum in Mountain View has a 4D/50 but it has the newer
GT graphics ("CLOVER2").
I guess that makes this a truly unique system.
I'm not aware of a single surviving MIPS R2300 (4D/60) board set. If anybody ever reads this and knows where to find one, please let me know. The same if you know of any CLOVER1 boards anywhere, especially a DE3 or a ZB2 (the Z-buffer board which this system doesn't have).