33C93 SCSI woes

Scott Quinn compoobah at valleyimplants.com
Sun Jan 21 19:09:03 CST 2007


> Two thoughts... SCSI IDs are send by a 1-of-N code on the data lines, 
> so
> the fact that devices show up at the correct IDs means that the host 
> can
> assert data lines.

That's similar to what I was thinking

>
> But 191 is 10111111 (hex BF) IIRC. Now that seems to be a significant 
> bit
> pattern, particularly as bit 6 is the '0' -- your host adapater 
> wouldn't
> happen to be device 6 on the SCIS bus, would it? (it's a common address
> for the host adapter). Do you have any idea what the 'Type' should be?

SGIs all have the SCSI host adaptor at SCSI ID 0. Generally, the PROM 
matches known types to user-identifiable strings (e.g. SCSI Disk: 
dksc(0,1); SCSI Tape: dksc(0,4))
I know that CD-ROM devices were not included in the PROM, and they 
appear as
"Unknown SCSI type 5 / removable: SCSI (0,6)" [or whatever the address 
is], which correlates to the decimal conversion of the "Perepheral 
Device Type" field returned in byte 0 by the inquiry command 
(CD-ROM=0x5).

I'm not sure where 0xBF is coming from- that doesn't look like a valid 
type. So there must either be a spurious signal (or excessive skew) or 
a bad host controller. It sounds like the 0xBF is being reported for 
all types, including a tape drive (should be 0x1), ZIP, and something 
else that I can't find in an email right now, but I think it was a MO.
bear made a suggestion that it might be a problem with the termpwr.
Hmm- he says he's already desoldered the 33C93A and put in a socket, so 
I might just go ahead and scavenge another 33C93A from a board in the 
garage and send it to him (the PI owner, not bear).




More information about the cctalk mailing list