[jan-jaap]

I got a bit further with the system, and it's giving me problems everywhere.

Initially, things looked like a quick restoration. There was very little dirt and grim in the system. This corresponds with the story of the original owner, that it had been used for 3 years between '88 and '91 and then sat untouched in a basement for nearly 35 years.

I removed and refurbished the power supply. Again, very clean inside, no leaking capacitors anywhere, just a cracked RIFA safety cap. I replaced it and several output capacitors and it should be good for years to come. Tested under load, voltages good, regulation good. Reinstalled PSU, powered up chassis without any cards in the card cage and verified that fans etc all worked.

I then put the IP4 CPU board back in the system, hooked up a console on the first port and was greeted by:

Code:

Starting power-on tests:
Console DUART                  PASSED.
Memory walking bit             PASSED.
MemorStarting power-on tests:
Console DUART                  PASSED.
Memory walking bit             PASSED.
Memory address uniqueness      PASSED.

Exception at: A0017BD8, Cause: 0000280C, Status: 00480000, BadVaddr: 00007BD8
ParityErr: 00000000, LIOstatus: 000000EF, ErrorAddr: 3000FFFF

This seemed like a good moment to clean the memory SIMMs and sockets. But that didn't improve things.

I put in the IP4 board from my existing 4D/70 GT and it booted up without any issue. Both IP4 boards are part# 030-0011-001 rev J, even though one is 8MHz and the other 12.5MHz.

The "new" (misbehaving) IP4 has really old PROM firmware, version 4D1-2.1 from November '87. My existing IP4 had version 4D1-3.1 and I had the feeling it's a little more verbose at startup so I switched PROM chips between the IP4 boards. I verified that my old IP4 boots fine with this firmware. It's quite primitive: there familiar [1] ... [5] menu is missing, it drops you straight into a prompt. And it doesn't know 'hinv':

Code:

Starting power-on tests:
Console DUART                   PASSED.
Memory walking bit              PASSED.
Memory address uniqueness       PASSED.

Monitor Version 4D1-2.1 PROM IP4 OPT Tue Nov 10 04:06:24 PST 1987 SGI
Memory size: 16777216 (0x1000000) bytes
Icache size: 65536 (0x10000) bytes
Dcache size: 32768 (0x8000) bytes
>>

The new IP4 with the 4D1-3.1 firmware now gives me:

Code:

Version 4D1-3.1 PROM IP4 OPT Thu Dec  8 16:12:10 PST 1988 SGI

Memory address pattern test from A0000000 to A02FFFFF
FAILED.
Address: A0000000, Expected: FFFFFFFE, Received: 00000000

Exception at: BFC01ED8, Cause: 0000281C, Status: 00480000, BadVaddr: FFFFFFFF
ParityErr: 00000075, LIOstatus: 000000EF, ErrorAddr: 00000000

Now, I'm somewhat familiar with early boot code on the MIPS. The real thing on the IP4 is very much like "See MIPS Run" explains, and what it says in the console output:

• It starts executing from the start address with cache disabled and hard coded boot exception handlers in place
  
• Initially it executes in registers only, it initializes some CPU config registers and opens a console UART
  
• It then performs a walking zeros bit test on address A0000000, followed by a walking ones test
  
• Much later, after main memory has been sized and initialized, caches are configured and enabled
  

This thing literally fails the first write access to memory: it writes 0xFFFFFFFE to 0xA0000000 as part of the first walking zero test, and reads back 0. 

The address 0xBFC01ED8 is in the walking bit code. CAUSE register 0x281C decodes as exception code 7, data bus error. The STATUS register value 0x00480000 means BEV (boot exceptions) and CM (would have hit cache if only it has been enabled) so no clue there either.

At thing point I hit the IP4 board with pure alcohol and Deoxit to make really sure the SIMM sockets are clean (visually everything looks good), and replaced the SIMMs with known good ones. No change.

Now, between both Professional IRISes I have three IP4 boards, one 12.5MHz and two 8MHz. I can deal with a dead IP4 later and I put the known-good 12.5MHz IP4 in, and the Clover1 graphics boards. But my misery isn't over just yet:

Code:

Starting power-on tests:
Console DUART                   PASSED.
Memory walking bit              PASSED.
Memory address uniqueness       PASSED.
gfx: no working graphics hardware
can't open gfx(0)
Monitor Version 4D1-2.1 PROM IP4 OPT Tue Nov 10 04:06:24 PST 1987 SGI
Memory size: 16777216 (0x1000000) bytes
Icache size: 65536 (0x10000) bytes
Dcache size: 32768 (0x8000) bytes
>>

There's nothing on the attached monitor. A good keyboard and mouse were attached.

Where do I even begin to debug Clover1 graphics? One the GT / GTX / VGX you've got a diagnostics UART on the GM board. No such thing here. No UART chips on the GF3 board. There may be something on the blue IDC connector but then't it's TTL and AFAIK entirely undocumented. I know schematics for IRIS 3130 graphics exist on Bitsavers, but I don't see how they could help me.

   
The LEDs are solid red, unlike the heartbeat pattern on the IP4

Summarizing, it looks like the entire contents of the card cage is fried. Visually it all looks good, clean, no burnt parts, it smells like it's been sitting for 30 years when you power it on, but nothing is smoking or smelling like fire. And the PSU is certainly capable of starting a fire if something shorts. The GE chips on the GF3 get warm to the touch if you let it run for a bit.

There's one thing that worries me a bit and that's the story of the original user about how the entire system had been degaussed when it was decommisioned. Normally you degauss magnetic media like disks and tapes, not an entire 60x70x70cm computer system with a metal chassis. Commercially available degaussers can handle maybe 20x30x30cm volume -- what you need for disks and tapes, but you can't exactly put a deskside computer in one. I wonder if this system was perhaps hit with something else, like an EMP. But then again, if you willingly destroy it, why not trash it afterwards?

Anybody have any good ideas how to proceed, especially with the graphics? I can try to attach a disk and load IRIX 4.0.1 for which I have a matching Diagnostics tape that probably includes diagnostics for the Clover boards. But I have the feeling it's just going to tell me it's dead.

I'm not completely out of ideas with the dead IP4 even if to my knowledge no schematics exist. Its got to be the CPU itself or some of the TTL logic between it and the SIMM sockets. First of all, I have a known-good 8MHz IP4. I can try to swap CPU chips, attach a logic analyzer or scope etc. But it's not my most urgent problem and if this thing was zapped that's not going to be the end of it.