SCSI Troubleshooting

[Thomas Niccum]

Hi all, I'm looking for some assistance troubleshooting an issue with SCSI...

This is with a 1980s computer (Alpha Micro is the brand, AM1200 is the model) - 68000 processor, with a single motherboard that contains everything including the SCSI controller.

The computer runs fine, completes all self-tests other than the disk stuff.  I can boot from an alternate device, but any attempt to access a SCSI device hangs the computer and apparently the SCSI device.

I've tried physical hard drives (known working), as well as (known working) SCSI2SD type SCSI emulator boards, with the same result.

The drive is getting accessed - with SCSI2SD emulator in place, the drive access light comes on upon access, but locks on at the same time the computer hangs.

So I'm pretty sure the issue is the SCSI circuitry on the main board which is almost entirely 74LSxxx chips.

I've popped a logic analyser into the mix looking at the signals going out on the SCSI cable and they look pretty normal (to me - not an expert).

In the self-test, the Alpha Micro reports that it's sending a SCSI Command of "1D" (Diagnostic) and getting an "FF" in return, which is unrecognized, then it sends an "08" (Read) which also returns an "FF".  Self-test doesn't hang... but booting from the tape device then running any type of disk access does.

I'm assuming it's hung waiting for some sort of response which isn't coming.

Just wondering if there are any SCSI experts out there who could help me think through where the problem might be.

I have a schematic of the SCSI controller portion of the motherboard - actually it's from the previous model of this motherboard, but it's pretty close and maps well to what I see on my board... I'm looking for some tips and thoughts on where to look and what to look for.

Failing that... I've ordered a BLUESCSI device which has good open source software thinking I could hack a bit of SCSI analyzer in the Arduino software and maybe get a hint of what is being seen by the drive, what is being responded, and maybe get some better clues as to where to look.  

I'm guessing there's a blown chip in the chain, but I haven't found it yet.

Any thoughts (or even prayers!) would be most appreciated.  I've been working on this for a few weeks and haven't made too much progress narrowing things down.

Thanks!

[SiFish]

Might it be possible that the system is old enough for this to predate SCSI-1 and be expecting SASI devices  ?

[Thomas Niccum]

Yes, that is possible.  I went to the trouble to borrow an older drive for this system - the oldest versions came with a MFM drive and a XEBEC controller.

That has exactly the same symptoms, unfortunately.

I also borrowed an older motherboard that originally shipped with the MFM/XEBEC - it works fine with the SCSI2SD emulator board.  So I feel like I've looked at both sides of the issue, and have come up with the same results.

[Douglas Miller]

There may be a clue in the "FF" responses. I'm not sure if you are getting some sort of dump (like for SCSI SENSE data), or if it is just a single-byte code being displayed. But, if the system was designed with a deterministic bus behavior, there may be pullups such that the CPU sees "FF" when no device asserts data during read. This could indicate a failure to select - either the adapter chips from the CPU bus or the SCSI drive on the SCSI bus. It all depends on whether that "FF" is supposed to be some piece of data returned by the drive (SCSI command response, SENSE, ...), or it is something directly read off the CPU bus like the SCSI/SASI status bits.

Just to try and settle the SCSI vs. SASI question, is this machine from the early 1980's or the late 1980's? From what I can see, AM1200 was later (1987) and so is more likely to be SCSI. As far as I recall, XEBEC produced both SCSI and SASI controllers so we'd need to see the model number to know which you tried. I'm also not sure when the interface connector changed w.r.t. SASI and SCSI, in which case it would not be likely to accidentally connect SASI to SCSI or vice versa. The SASI adapters I used on 8-bit machines had a 40-pin connector, and I seem to recall SCSI having 50-pin at some point.

[Thomas Niccum]

Thanks!

>>There may be a clue in the "FF" responses. I'm not sure if you are getting some sort of dump (like for SCSI SENSE data), or if it is just a single-byte code being displayed. But, if the system was designed with a deterministic bus behavior, there may be pullups such that the CPU sees "FF" when no device asserts data during read. This could indicate a failure to select - either the adapter chips from the CPU bus or the SCSI drive on the SCSI bus. It all  depends on whether that "FF" is supposed to be some piece of data returned by the drive (SCSI command response, SENSE, ...), or it is something directly read off the CPU bus like the SCSI/SASI status bits.

The self-test documentation indicates that I should get 5 numbers back:

Command, Status, HI-Blkadr, MID-Blkadr, LOW-Blkadr 

So what I'm seeing is 

1D FF 00 00 00 (1D is the SCSI Diagnostic command)

and

08 FF 00 00 00 (08 is the SCSI Read command)

Feeling like the FF idea you have seems on track.  I think SELECT is on track for the following reason...

IF I set the drive ID as 0 then when it tries to boot  (or I access it via another method) it looks selects for drive 0 and i get a drive light indication that the drive was accessed, and I'm hung.

If I set the drive ID as 1 then when it tries to boot and looks for drive 0, I get no drive light indication - and no hang...  But if I access it via another method that will select for drive 1 (like listing SCSI Devices on the bus) it will hang when it attempts to access drive ID 1.

>> Just to try and settle the SCSI vs. SASI question, is this machine from the early 1980's or the late 1980's? From what I can see, AM1200 was later (1987) and so is more likely to be SCSI. As far as I recall, XEBEC produced both SCSI and SASI controllers so we'd need to see the model number to know which you tried. I'm also not sure when the interface connector changed w.r.t. SASI and SCSI, in which case it would not be likely to accidentally connect SASI to SCSI or vice versa. The SASI adapters I used on 8-bit machines had a 40-pin connector, and I seem to recall SCSI having 50-pin at some point.

Computer mother board was made around '86 or '87

It is a low Serial number, and there may have been a transition over time, but I've been told it was SCSI-1 backward compatible with SASI.  The cable is 50 pin, and has the old Centronics 50 pin interface on the back for adding external drives.

The XEBEC I have in hand, which works with an AM1000 (prior version of the computer)  is an S1410, I believe.

Just for further data - I purchased this AM1200 from a seller on ebay,, it had no hard drive.  My guess is that the disk controller hardware was kaput, and they moved the drive to another box and put this one on the shelf... for about 30 years (LOL).

I'm fairly experienced with Alpha Micro software, I worked with their stuff for over a decade in the 80s/90s... I'm less certain around the SCSI stuff... 

Thanks for your help.

[Douglas Miller]

I see I was wrong about the "standard" SASI interface vs. SCSI. Both used 50-pin connectors with nearly identical pinouts (there might even be a modicum of compatibility, depending on the specifics of the protocols). The adapters I was familiar with simply spliced-out the middle 10 (unused) conductors on the host end, so the adapter cards could save on PCB real estate.

[Douglas Miller]

So, the XEBEC S1410 is, at least according to my documentation, a SASI controller. However, given that SCSI is an extension to SASI, it may be possible for a XEBEC S1410 to function - at least partially - on a SCSI system.

For SASI, the "response" to commands is two bytes, the first being an error indicator and the second being zero. I'm not sure what SCSI does in that regard, and how any of that relates to the bytes you see printed. But, it seems possible that the "FF" could be a floating bus (nothing selected). SASI only defines one bit in the status "error" byte (plus the LUN), and states all the rest would be zero. If that holds for SCSI, then "FF" would not be a valid value for that byte - if it is indeed the status bytes being shown there.

[Thomas Niccum]

Thanks, The FF is NOT in my list of "acceptable" responses or error codes, so I'm pretty sure this is indicating the "pull-up" type issue you described.  I suppose it could be a bad control signal that isn't getting asserted properly, thus letting the data lines of the return data float meaninglessly.

I've thrown a logic analyzer on the SCSI bus and it seems like a lot of the lines are working correctly - I can see the select lines working, etc. anyway.  I've looked at a few of the 74LS chips as well and they seem to be operating per data sheet.

I guess my next step is get more detailed -to see the actual data on the bus, rather than the control lines.  Then maybe I can hunt down which chip is failing me...  

There really aren't too many involved, luckily.

On Mon, Aug 1, 2022 at 5:00 PM Douglas Miller <durga...@gmail.com> wrote:

So, the XEBEC S1410 is, at least according to my documentation, a SASI controller. However, given that SCSI is an extension to SASI, it may be possible for a XEBEC S1410 to function - at least partially - on a SCSI system.

For SASI, the "response" to commands is two bytes, the first being an error indicator and the second being zero. I'm not sure what SCSI does in that regard, and how any of that relates to the bytes you see printed. But, it seems possible that the "FF" could be a floating bus (nothing selected). SASI only defines one bit in the status "error" byte (plus the LUN), and states all the rest would be zero. If that holds for SCSI, then "FF" would not be a valid value for that byte - if it is indeed the status bytes being shown there.

--
You received this message because you are subscribed to a topic in the Google Groups "retro-comp" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/retro-comp/2CSN2AGLAj8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to retro-comp+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/retro-comp/a72cf750-df5e-40b6-aaaf-630f7e0e5848n%40googlegroups.com.