[Geoman]

I bought a variant of 030-0049-00x EBA Extended Board Adapter VME 6U / 9U - thanks to B&B Solutions II Inc.. Then I installed a new-old-stock Vigra MMI-210 Board into it. 

Two things were the result: First an error reappeared, which I saw back then when I started Crimson for the first time with the help of a new PSU:

Code:

VME32 word write failed, addr 0xa0400000: expected 0x400000, read 0xaaaaaaaa

Back then this error disappeared until now after a successful IRIX 5.3 installation.

Then this weird SCSI-timeout-problem appeared, and because of this Crimson wasn't even able to boot any more:

Code:

WARNING: wd93 SCSI Bus=0 ID=1 LUN=1 SCSI cmd=0x12 timeout after 10 sec. Resetting SCSI bus

Re-Partitioning and reinstalling IRIX from an external SCSI-CD-ROM-Drive got rid of this error. The VME-Bus error persists, even with the Vigra-Board removed.

I researched the web concerning these two errors: SCSI Timeout Problem and VME error. They both yielded not much information:

SCSI:

Once Dave Olson said:
Some (disks) have firmware bugs, some have different ideas of what the SCSI spec says, etc.  If you stick with the major manufacturers, you are *probably* OK, but no  promises.  We usually go through a number of firmware revs when qualifying drives, to be sure that it works with our system.  I don't think we have ever asked for anything contrary to the SCSI standards, but we do have requirements that go beyond the spec, due to the way our DMA works (devices must disconnect on a multiple of 4 bytes from start of transfer  if they have more data to transfer, for example).  Other vendors have similar requirements, so this is almost universally done anyway. As a side note: if disconnection is not allowed, tag-queueing must be turned off. If tag-queuing is on, the device must be allowed to disconnect.

VME:

| What does this mean?
That the VME bus is hosed.  Perhaps a bent pin, or a board that's not seated.
--
Dave Olson, Silicon Graphics

Well I got rid of the SCSI-Error anyways. The next step was to install the drivers for the Audio module. This resulted in the following error during boot:

Code:

No Audio hardware, or kdsp audio support not configured into kernel

Although I knew that MMI-110 does not work in Crimson:

Question:
Will the VigraSound package work in a Crimson?
Answer:
No. There are some data sheets created early on that stated the VigraSound package would work with the Crimson. Technical difficulties arose which prevented VigraSound support on the Crimson.
Vigra has other audio products that will work in a Crimson. Please call Vigra technical support department for an assessment of your needs. 1-800-66VIGRA e-mail: tech_support@vigra.com

There is evidence that the MMI-210-Bord does indeed work with Crimson:

Our facial synthesis and perceptual experimentation is carried out on a Silicon Graphics, Inc. (SGI) 4D/CRIMSON-VGX workstation under the IRIX (SGI SYS V UNIX) operating system. This machine has a speed of roughly 85 MIPS, 16 MFLOPS, and 1,000,000 polygons displayed per second.

The stimuli were recorded on a SGI Crimson VGX workstation with a Vigra MMI-210 sound card.

Source: Perceiving affect from the voice and the face and Development and experimentation with synthetic visible speech (Cohen/Massaro)

Current state is a stable running Crimson with a remaining VME error on boot and a not working sound card. Everything else, especially the VGX-graphics is running fine.

So what's next on this journey of computer archeology?
1. Reseating and checking every board and every connection to solve this VME error
2. Upgrading the Crimson to 256 MB memory
3. Installing IRIX 6.2 to be able to install the newest Vigra sound drivers

PS: The VIGRA-Board is showing a solid orange and green LED during power-on. The green light stands for 5 V power, the orange LED indicates an error I presume (?)

[robespierre]

Since both problems started when you installed a VME card, they are probably related and simply the result of a bus grant/termination issue.
VME requires resistor packs to be moved when installing or removing cards to provide what is called "bus grant continuity". This should be documented in the VME section of the manual.

[Geoman]

Yes, the "Field Service Handbook for SGI Crimson" states on page 2-9:

4. As a general guideline, populate the VME slots from slot 1 to slot 4.
5. Jumpers located between VME slots (1-4) are bus grant (BG) and interrupt acknowledge (IACK) jumpers. Use the following rules when jumpering the
VME slots:
o If any VME slot is empty, BG and IACK jumpers located to the left of the empty slot must be installed
o If a board is installed in a VME slot, the jumpers for that slot must be removed
6. If the GENLOCK board is installed in a VME slot, it must reside in slot 4 and the GENLOCK jumpers (located to the left of bottom connector for slot 4) must be removed

and on page 2-14:

3. Configure VME controller boards in slots 1-4
o install VME boards beginning with Slot 1.
o there must be either a board installed in a slot or jumpers installed between the beginning of the VME backplane and the last VME board (see page 2-8
for jumper locations).
o Slot 4 may contain either a VME board or a CG2 genlock video board.

So since Vigra has to be installed in Slot 1, I did not set any jumpers (ie the Backplane is 'jumper free'), because it is the only VME-Board installed. Did I got that right?

On the other hand, if I read the excellent sgistuff.net :

General rules regarding VME setup:

o populate slots from slot #1 to slot #4
o remove BG/IACK jumper for every slot that cards are installed in
o if one slot is empty the BG/IACK jumpers must be set

The exception to this rule is the Genlock board which always goes in slot #4. If that is installed the genlock jumpers located to left of bottom connector of slot #4 must be in place.

I would have to install jumpers on BG/IACK-Positions on VME-Slots #2-3 and leave #1 (Vigra) and #4 (empty Genlock-Position) both open.
That's a bit contradictory to the field service handbook.

[chulofiasco]

Yes, the "Field Service Handbook for SGI Crimson" states on page 2-9:

4. As a general guideline, populate the VME slots from slot 1 to slot 4.
5. Jumpers located between VME slots (1-4) are bus grant (BG) and interrupt acknowledge (IACK) jumpers. Use the following rules when jumpering the
VME slots:
o If any VME slot is empty, BG and IACK jumpers located to the left of the empty slot must be installed
o If a board is installed in a VME slot, the jumpers for that slot must be removed
6. If the GENLOCK board is installed in a VME slot, it must reside in slot 4 and the GENLOCK jumpers (located to the left of bottom connector for slot 4) must be removed

and on page 2-14:

3. Configure VME controller boards in slots 1-4
o install VME boards beginning with Slot 1.
o there must be either a board installed in a slot or jumpers installed between the beginning of the VME backplane and the last VME board (see page 2-8
for jumper locations).
o Slot 4 may contain either a VME board or a CG2 genlock video board.

So since Vigra has to be installed in Slot 1, I did not set any jumpers (ie the Backplane is 'jumper free'), because it is the only VME-Board installed. Did I got that right?

On the other hand, if I read the excellent sgistuff.net :

General rules regarding VME setup:

o populate slots from slot #1 to slot #4
o remove BG/IACK jumper for every slot that cards are installed in
o if one slot is empty the BG/IACK jumpers must be set

The exception to this rule is the Genlock board which always goes in slot #4. If that is installed the genlock jumpers located to left of bottom connector of slot #4 must be in place.

I would have to install jumpers on BG/IACK-Positions on VME-Slots #2-3 and leave #1 (Vigra) and #4 (empty Genlock-Position) both open.
That's a bit contradictory to the field service handbook.

If you don't have a board installed in slot four, wouldn't it need jumpers?

Isn't the exception to the rule that the Genlock board is always in slot 4?

[Geoman]

Yes, that is how I read it: Genlock always in #4 (which I don’t have anyway), and therefore no jumpers.

I also have to try to configure it as CB_HK with success:

UPDATE:

kshuff came to the rescue and hooked me up with another Vigra board. I can now report that I have functioning sound on my Onyx! I’m running IRIX 6.2 with VigraSound 2.2 and the system is stable and snappy! The only odd experience I had was having to install the board in slot 1, instead of 0, and then jumper it on the backplane. For whatever reason the board would not initialize in slot 0. A minor issue that’s easy enough to work around.

Video of it in action:
https://youtu.be/BNy0FuwMRo0

[Geoman]

So a continued websearch brought me to this reddit-thread: My latest 68K System: 50MHz 68060 with 32MB of RAM

I asked the OP to share the documentation about his Vigra MMI-210-Board, and he just did:

Been a while since I last looked at this, but I put what I could find before here: https://www.retrodev.com/files/vigra_mmi/

• hwmanual.pdf is the hardware manual for the MMI-4310 which is similar to the 210, but has 4 DSPs and 4 in/out audio channels
  
• dispatch.pdf is the manual for the DiSPATCH firmware package that runs on the cart. Mostly it's about interacting with that firmware, but it has useful information about initializing the card for user
  
• host-doc.pdf is about the software package that runs on the host system. It wasn't terribly helpful for me, but since it sounds like you've got the software this maybe what you're most interested in.
  
• tonedoc.pdf is about using the audio synthesis features of the DiSPATCH firmware
  
• mmi-210_tips.shtml basically amounts to a couple of minor addendums to the MMI-210 manual (which I couldn't find)
  
  

[Geoman]

After having the VME-sound card removed for some time

Code:

VME32 word write failed, addr 0xa0400000: expected 0x400000, read 0xaaaaaaaa

this error disappeared again, and the system boots up w/o errors now.

Is there a IO3-board-test suite or another possibility to test the VME bus on the Crimson?

[sunray]

After having the VME-sound card removed for some time

Code:

VME32 word write failed, addr 0xa0400000: expected 0x400000, read 0xaaaaaaaa

this error disappeared again, and the system boots up w/o errors now.

Is there a IO3-board-test suite or another possibility to test the VME bus on the Crimson?

Just a note. If you have some instruments such as oscilloscope or even a logic analyzer, the VME bus is a very straight forward bus so debug on.


A little bit odd that they seems to wrote the same data as the address itself and they expect 0xaaaaaaaa,. Usually when running test you try 0x5 and 0xa as one pattern but 0x40000 odd

A instrument like this is perfect for the job there is also a G version without the crappy oscilloskop, i would for the G version.

https://www.ebay.com/p/1104045214

https://www.ebay.com/itm/394592839253?ep...R5KhxJH7YQ

[Geoman]

Just a note. If you have some instruments such as oscilloscope or even a logic analyzer, the VME bus is a very straight forward bus so debug on.


A little bit odd that they seems to wrote the same data as the address itself and they expect 0xaaaaaaaa,. Usually when running test you try 0x5 and 0xa as one pattern but 0x40000 odd

A instrument like this is perfect for the job there is also a G version without the crappy oscilloskop, i would for the G version.

https://www.ebay.com/p/1104045214

https://www.ebay.com/itm/394592839253?ep...R5KhxJH7YQ

Yes that notion is looming in the back of my head - that I will have to resort to more sophisticated diagnostic modalities in the future... which requires a lot of studying and training.

At the moment I consider myself a fool concerning this complex level of electronics, and a fool with a tool....

[Geoman]

Code:

WARNING: wd93 SCSI Bus=0 ID=1 LUN=1 SCSI cmd=0x12 timeout after 10 sec. Resetting SCSI bus

Booting or reinstalling the OS wasn't possible anymore, this error persisted.
I removed both of the AM33C93A-chips with a desoldering gun, soldered in 2 sockets and inserted 2 new old stock AM33C93A-16PC. Now Crimson is happy again. Perhaps this also was the root of the VME-Bus-Errors...

If you want to retry this, be advised: the traces on the IO3B-board are extremely fragile, I nudged one slighly aside just by touching it with the soldering iron since they run in parallel to the pin arrays of the chips.