[vishnu]

Vector (a maker of prototype and extender cards)?

There was also some discussion that insertion of VME cards should become easier if the connectors are treated with DeOxit G100.

We do all our prototyping using vector boards, ordinarily the ones with backplanes, busses and solder pads, but also on plain vectorboard that just has the through holes and nothing else, vectorelect dot com - highly recommended. 

The venerable VME bus - man, that's a still-relevant blast from the past!

[jan-jaap]

Another day, another challenge.

I managed to load IRIX 4.0.1 on the system. Remember: this system does not have an ethernet adapter, no external SCSI port and the tapedrive is unusable. So, basically I did:

* dd an IRIX 4.0.1 CDROM to a SCSI harddisk (ID: #4), and attach this disk to the port of the tapedrive.
* boot dksc(0,4,8)sash.IP4 from the disk and load fx.
* 'fx' the disk with default layout
* reboot
* boot dksc(0,4,8)sash.IP4 from the disk and copy the miniroot (mr) to the swap partition, dksc(0,1,1)
* boot dksc(0,1,1)unix.IP4
* when the miniroot loads, enter admin>sh and mount the sw distribution from disk4.
* perform installation
* umount sw distribution
* it hangs shutting down. I finally reset the system.

I can boot this system in single user mode: boot -f dksc(0,1,0)unix initstate=s
I can then fsck and mount the /usr partition.

But any attempt to switch runlevels hangs the system. This includes shutdown, reboot, init 2, regular boot (hangs after mounting filesystems), shutting down in the miniroot etc.

I pulled the graphics: this makes no difference.

I think it has to do with one unique aspect of this system: it has no network interface at all. And that's the original config: the ribbon cable of the ethernet bulkhead is still wrapped up with a zip tie.

Regardless of having no network interface, it has an /etc/sys_id file (value: IRIS), and 'IRIS' exists in /etc/hosts (value: 192.0.2.1). But any attempt to run '/usr/etc/ping IRIS' hangs the system.

I used chkconfig to disable everything related to TCP/IP networking.

I wonder if I need a special kernel command line, or a special kernel config to run without ethernet. Some kernel commandline arguments exist, e.g. initstate and showconfig, but I can't find anything network related. /usr/sysgen/master.d has quite a new network related variables but I couldn't find anything that looked like it was a "disable the network" toggle.

Anybody got any clues? Other than IP4, an SGI without any network doesn't really exist.

[weblacky]

I realize I'm totally out of my league here but I'm going to ask a very stupid question, is there a reason you're loading Irix 4.0.1...when there was a disk of Irix 4.0.5 for this system...donated by you...here: https://jrra.zone/sgi/cds/IRIX%204.0.5.iso

http://www.sgistuff.net/hardware/systems...ional.html

Claims you would use 4D1-4.0.5 that has clover 1 support as the last OS for this system.

Wouldn't you hope that the above version would have all the answers for this system, being that it should be the last official version for it?

Cheers!

Another day, another challenge.

I managed to load IRIX 4.0.1 on the system. Remember: this system does not have an ethernet adapter, no external SCSI port and the tapedrive is unusable. So, basically I did:

* dd an IRIX 4.0.1 CDROM to a SCSI harddisk (ID: #4), and attach this disk to the port of the tapedrive.
* boot dksc(0,4,8)sash.IP4 from the disk and load fx.
* 'fx' the disk with default layout
* reboot
* boot dksc(0,4,8)sash.IP4 from the disk and copy the miniroot (mr) to the swap partition, dksc(0,1,1)
* boot dksc(0,1,1)unix.IP4
* when the miniroot loads, enter admin>sh and mount the sw distribution from disk4.
* perform installation
* umount sw distribution
* it hangs shutting down. I finally reset the system.

I can boot this system in single user mode: boot -f dksc(0,1,0)unix initstate=s
I can then fsck and mount the /usr partition.

But any attempt to switch runlevels hangs the system. This includes shutdown, reboot, init 2, regular boot (hangs after mounting filesystems), shutting down in the miniroot etc.

I pulled the graphics: this makes no difference.

I think it has to do with one unique aspect of this system: it has no network interface at all. And that's the original config: the ribbon cable of the ethernet bulkhead is still wrapped up with a zip tie.

Regardless of having no network interface, it has an /etc/sys_id file (value: IRIS), and 'IRIS' exists in /etc/hosts (value: 192.0.2.1). But any attempt to run '/usr/etc/ping IRIS' hangs the system.

I used chkconfig to disable everything related to TCP/IP networking.

I wonder if I need a special kernel command line, or a special kernel config to run without ethernet. Some kernel commandline arguments exist, e.g. initstate and showconfig, but I can't find anything network related. /usr/sysgen/master.d has quite a new network related variables but I couldn't find anything that looked like it was a "disable the network" toggle.

Anybody got any clues? Other than IP4, an SGI without any network doesn't really exist.

[robespierre]

I suppose you tried building a kernel with lboot? Is the IDO installed? (This depends on the assumption that the master.d file tests a VME register to detect if the CMC Ethernet card is present to decide whether to link in the driver)
It shouldn't be the case that a driver for a missing peripheral hangs the system, but I suppose it was just never tested without ethernet.

[jan-jaap]

I’m using 4.0.1 because I’ve got the matching “big iron” Diagnostics for the graphics.

Otherwise it occurred to me that the miniroot is probably not single user so it’s got to be possible. I may simply need to change the IP address to 127.0.0.1.

And yes, I have the dev tools installed and did try to rebuild the kernel

[jan-jaap]

I have come to the conclusion that IRIX 4 doesn't work without a network interface.

'autoconfig -fv' will clearly tell you it can't probe enp0, enp1, ... and also none of the ipg or et interfaces, but then "ifconfig ipg0" will hang the system. This means the network part of the init scripts will always hang the system if you attempt to switch runlevels. Perhaps an older version or IRIX, without X11 but with NeWS can run without network, but my goal here is to run the Diagnostics on the (graphics) hardware and the oldest Diagnostics I have is version 4.0.1

So I caved and installed a VME ENP10 card. And then the system started behaving:



It does wild color map flashing because it doesn't have enough bitplanes. Had not seen that since the 8-bit Indy I had at $WORK back in the nineties



Unfortunately, most of the demos don't work because 'powerflip' wants a Z-buffer which this systems sadly doesn't have. If anybody has a lead on a ZB2 board, or a 24bit color DE3 board I want to buy it from you. Actually, any other DE3 board probably has enough of the special SIMMs installed to fill all banks on mine and make it full color. To be honest: I'm interested in any (spare) part for the Professional IRIS.

[jan-jaap]

NB: of course I have all the panels for this system. I will put them back on when I'm sure I don't need to reconfigure the backplane anymore. There's a second SCSI disk attached to the port of the tape drive right now -- that's what I used for installation.

The toothbrush is to override the chassis intrusion detection that would otherwise trip the circuit breaker

[jan-jaap]

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).

[vishnu]

On the MB81461-12 chip the "8708" is probably a date stamp, the eighth week of 1987.

[jan-jaap]

Yeah the whole machine is full of stamps like that. The VRAM SIMMs have a stamp 87-52 and 88-11, so perhaps the PCB was wk52 '87 and they were assembled or tested wk11 '88.



Same for the ASICs on the DE3, wk11 '88 for the XBARs and wk06 '88 for the PMAPs:



According to the original user, the machine was bought in 1988 which makes sense. The GT graphics were announced late '87 and in October '88 the PowerSeries and Personal IRIS were introduced. The Personal IRIS had the same CPU and probably at least comparable graphics for a fifth of the price of a Professional IRIS, and the PowerSeries were so much faster, instantly obsoleting the Professional IRIS series.