[jan-jaap]

I did a fair bit of work on my Crimson this year, and one thing it still did was:
   
at cold boot. Entering PROM console and calling up 'hinv' would show no SCSI disk #1. If I pressed the reset button and let it POST again, all would be fine. (Yes the NVRAM battery is empty, but that's unrelated).

I decided to get to the bottom of this one.

1. First, I suspected the disk, a Seagate Barracuda 18, ST118273N. But my 4D/440 VGX has no issues at all with the disk. It sees it without issues, and the 'fx' exercise test finds no problems.
   
2. Next, I suspected the IO3B and/or the wiring or the termination. Moving the disk to secondary SCSI channel of the Crimson changed nothing. I replaced the IO3B with a spare and repeated the process. No joy.
   
3. Next, I attached an oscilloscope to monitor the power supply of the Crimson. Voltages are good, and there's no excessive noise or ripple.
   
4. Next, I installed an IP15, the IO3 and MC2 from the 4D/440 VGX in my Crimson chassis. This combination was able to probe and read the Crimson disk.
   
5. Next, I reassembled the Crimson, but installed the disks of the 4D/440. One of those full height 760MB "Wren" disks and a 50pin 4GB IBM DDRS. Crimson can access these disks. Yay!
   

I dug into my pile of old SCSI disks and pulled out some more old disks. These are mostly 18GB or less, none of those fancy Ultra320 disks. In short: Crimson sees the oldest 50 pin disks, has the cmd=0x12 (INQUIRY) timeout on others, and didn't see a 72GB LVD disk at all.

Summarizing: if we rule out the possibility that all 4 SCSI chips across 2 IO3Bs are half-broken in exactly the same way, then all of the individual bits appear to be good. The difference between the Crimson and the 4D/440 seems to be that the 4D/440 can use disks introduced 5 or 10 years after the system, but Crimson has issues there.

I had a closer look at the SCSI chips on various old SGI systems:

• IP4: WD33C93
  
• IP10: WD33C93A
  
• IO3: WD33C93A
  

   

• IO3B: AM33C93A
  

   

A pattern is starting to emerge ...

Now, as Geoman already mentioned, these chips are used in the Amiga 3000 also. And they seem to have issues there too. It seems to be a popular hack in the scene to replace the SCSI chip with a new AM33C93A. As I understand it, not because the original chip is fried, but because it's buggy. Can't read some optical disks, Jazz etc. The replacement chips are apparently faster also?

You can buy these chips on eBay, from dozens of sellers that seem to have endless quantities of them available for a couple of bucks. Almost all of them from Shenzhen, China. I actually got 5 of them. They look like I could wipe the label off with a bit of alcohol. I highly doubt these are genuine NOS parts.

As it is, I think it's best (for me, in this situation) to leave the IO3B as it is, and not mess with fake parts. I don't think it's broken, it's simply quirky.

This means I cannot use the Seagate Barracuda ST118273N disk. I will probably swap disks between the 4D/440 and the Crimson. I've been told the SD based SCSI emulators (ZuluSCSI etc) work too with the Crimson, so I ordered a SCSI knife to see if that works.

[robespierre]

What if we assume that the AM33C93A is not buggy, but that it conforms to the standards in place at the time it was designed? In 1989, the latest standard was SCSI-1 with the CCS (Common Command Set). After 1991, the SCSI-2 standard was in place, and the ST118273N is a SCSI-3 drive produced in 1998. That's a time span of a decade during which major changes were made to the SCSI protocol.

Some of the differences between SCSI-1/CCS and SCSI-2 are:

1. Several options were removed from SCSI-1:

a. Single initiator option was removed.
b. Non-arbitrating Systems option was removed.
c. Non-extended sense data option was removed.
d. Reservation queuing option was removed.

e. The read-only device command set was replaced by the CD-ROM command set.
f. The alternative 1 shielded connector was dropped.

2. There are several new low-level requirements in SCSI-2:
a. Parity must be implemented.
b. Initiators must provide TERMPWR — Targets may provide TERMPWR.
c. The arbitration delay was extended to 2.4 us from 2.2 us.
d. Message support is now required.

(source: Dal Allan in Computer Technology Review, Jan 1991)

In thinking about how any of these differences could cause a timeout, note that parity and arbitration are related (parity must be correctly asserted during the selection phase for the target to respond). A SCSI-3 drive may not have been designed and tested with HBAs more than a decade older and conforming to a standard 2 major versions older.

I installed the MMI-210 ("Vigra") board in VME-slot 1. Then in slot 2, whilst jumpering the IACK and BG jumpers of slot 1, leaving open the IACK/BG jumpers in slots 2-4. In both cases I get in HINV only:

That's backwards. The jumpers provide grant continuity across empty slots. When a slot is occupied, its corresponding jumpers must be removed. When a slot is empty, the jumpers are installed so that the Bus Grant and Interrupt Acknowledge lines can pass over the empty connector.

[jan-jaap]

Well, regardless whether it's a quirk, a bug or simply a different interpretation of the spec that didn't play nice going forward in time -- the pin compatible WD33C93A doesn't have it.

The IBM Ultrastar 9ES (DDRS-34560) I borrowed from my 4D/440 is also from '97 or '98 and a "SCSI-3 FAST-20 SE 50-pin" device and it worked, so the IO3B doesn't disapprove all of them.

The ST118273N has a jumper to disable parity, I can see if that makes a difference. I played with the 'Force SE' jumper on some disks, that didn't change anything. Neither did (Delayed) Motor Start.

---

Regarding the Vigra VME card:

The Release notes of the VigraSound software for IRIX 5.2 or 5.3 say:

      IRIS Audio Library (AL) Execution Environment for VigraSound
      VME audio provides an audio environment for Onyx/Challenge
      systems which is binary compatible with SGI Indigo2, Indy,
      Indigo, and 4D/3X Personal Iris workstations.

      Release 1.0 supports: SGI Onyx, Challenge L, and Challenge
      XL systems running IRIX 5.3.

(Emphasis mine)

The software may install on a Crimson running 5.3, but the kernel code, usr/cpu/sysgen/IP19boot/kdsp_vigra110.o, is limited to CPUBOARD=IP19 in the .idb file so that won't install and essentially there's no driver. The versions of VigraSound for IRIX 6.x have kernel code for IP19, IP21 and IP25.

Perhaps the people in Geoman's referenced articles wrote their own code. It wasn't uncommon in those days, and with VME hardware.

About the Vigra showing (or not) in 'hinv': anything that 'hinv' knows about was hardcoded in the IRIX kernel and the 'hinv' command. It's not a dynamic system. So a 3rd party option will never show, unless it masquerades as something that IRIX already knew about.