1 Sep
2011
1 Sep
'11
11:44 a.m.
On 01/09/2011 12:28, Rob Jarratt wrote:
> I used my digital multimeter to check the pins you mention
So that's OK.
I suspect I need a way to monitor the signals actually
passing across
the wires, I have a multimeter and an oscilloscope, but I am not
sure of the practicalities of how to get access to the signals, I
suppose I need some kind of "breakout" ribbon cable, but I don't want
to ruin the existing cables. Is there some standard technique for
doing this kind of work? For now I think I will just solder some
diagnostic wires directly to the M9058.
It used to be possible to get a little adapter that goes in-line with a
34-way (other sizes also available); it consisted of a rectangular block
with one female contacts on one side, male pins on the other, and a
second set of male pins on top, to which one would attach probes. They
were stupidly expensive, and I'm not parting with mine :-)
However, you can achieve exactly the same effect by mounting two male
IDC connectors and one female on a short piece of ribbon cable. Or add
a male IDC to a short female-to-female so you can use it as an extension
and make two or three probe cables with square wire-wrap pins -- those
are an exact fit in a female IDC connector. Or even just add one more
female IDC to the existing cable and probe that with wire-wrap pins.
The pins I used for mine are gold-plated single wire-wrap IC socket
pins, but anything similar will do.
Hmmm.... I used my multimeter to see if I could see
anything
happening. I could see that the controller selects the drive and that
the select acknowledgement is asserted (J12 pin 14), so it seems the
disk is responding to the controller and the controller is seeing
the ack. I then used my oscilloscope to check the INDEX signal to see
if, once selected, the drive told the controller it was seeing the
start of the track, I confirmed this was happening, so the disk is
rotating.
So why it thinks the disk is offline is a mystery.
Sounds like the software has a problem rather than the hardware. I
looked back at earlier posts; you said you tested the RD53 in a MicroVAX
2000, and the RQDX3 in a BA23 uVAX II. But did that test use the same
RQDX3 with the RD53 in the uVAX II? I /think/ the format put on an RDxx
by any revision of RQDX3 is the same, though new firmware might change
things like RCTs in ways not transparent to old firmware. But the
format used by RQDX1 and RQDX2 is quite different to RQDX3 and I wonder
if the drive is the "wrong" format? Isn't a uVAX 2000 the same format
as RQDX1/2?
The last possibility I can think of is that there are a few active
devices on an M9058. They're mostly Schmitt triggers and open-collector
inverters used to buffer signals from RQDX to drive (and v.v.), but some
are differential buffers for the MFM data. Maybe one of those has gone.
You could of course test the M9058 in the BA23. Just ignore the
BA23's normal drive cabling and connect the RQDX in the BA23 via the
50-pin cable to the M9058, and cable the drive to that as if it were in
a BA123. The M9058 has no connections to the backplane except for power
and won't interfere with anything else.
--
Pete Peter Turnbull
Network Manager
University of York