Re: MFM drive gone nuts

Hello!

Julian Perry wrote:

> A quick googling found THIS URL : http://stason.org/TULARC/pc/hard-drives-hdd/miniscribe/M3425-20MB-5-25-HH-MFM-ST506.html
> It has the switch settings, including the various manufacturers
> "Actuator Exerciser modes" for your drive.

Thank you! This is exactly what I needed.

So it appeared that the SW2 was "open", causing the "Random Seek" mode.
I closed this switch and the drive no longer performs the test.

The document does not describe what the SW1 does, but anyway changing it
open or close has no visible effect.

> Timeouts (as opposed to read errors) would normally be tied to "Drive
> Ready (Pin 22), or Drive Select" problems?.

That's what I thought, that the drive is not selected properly...

> As dodgy as it sounds, you might try switching 5/6/7/8 ALL CLOSED (making
> drive selects 0,1,2,3 ALL responsive). Unlike Head select (which is a
> binary word) - Drive select are actual individual select lines.

That seems to be a good idea, since there is only one drive in the
system it should do no harm.

The controller has two "data" connectors, currently the drive is
atatched to the first one so it seems logical to me that the drive
should be #1 but I will try all configurations.

> You are very unlikely to be able to read the format on a PC. Although
> the raw encoding method may be similar, each controller manufacturer
> (and even WITHIN the SAME controller manufacturer) used different sector
> & header layouts. OMTI, Western Digital, NDC, DPT - they all had different,
> mutually incompatible formats. The D9060/9090 used 256 byte Sectors,
> so it's possible the C900 did too. The IBM PC XT/AT controllers used 512Bytes
> per sector, so that's a likely showstopper right there.

The C900 uses 512 byte sectors on the floppy, and the documentation says
that it was done to match the hard disk. So I presume that the hard disk
uses 512-byte sectors too.

The controller itself is labeled WD1003-CMD. I wasn't able to find any
information on the Internet on it, but a Google search shows that there
were cards for PC labeled WD1003-xxx where xxx was some letter and
number combination. So it looks probable that this controller uses the
same format as these PC cards?

> Also - DO check that you don't simply have the connector on
> backwards/upside-down.
> Not only is that possible if the connector is not keyed, but if you've
> made your own cable, crimping an IDC header on the wrong side, or
> upside-down will result in the pins being reversed, or (almost worse!)
> the Earth return pins swapped with their signal neighbors: with the
> exception of the four differential DATA lines on the 20 pin cable
> every second pin is ground return.

Yes, that was the first thing I checked. I used my ohmometer for this to
ensure that GND lines on the controller and on the disk are connected
properly. The drive was connected when I got the computer and I tested
that the original connection was correct, so I left it as is.

> I've also seen weird Drive-select behaviour in the past, where the
> drive LED remains lit, even when the drive is not active - usually on
> 16bit AT controllers. I believe these are related pin1 activity on the
> data connector, but I am not really sure. It kinda manifested itself as
> indicating "Drive Last Accessed", but back then I treated it in the
> "interesting, but unremarkable" quirks. Perhaps it is of more
> significance here. I honestly don't know.

Can't tell from where it comes from either...

One other idea came to my mind: The controller has a 8749 CPU. It might
be possible that this CPU died? Then obviously the controller would
simply not respond to any commands from the computer in timely fashion,
so the computer would think it's a timeout?

Unfortunately my EPROM burner cannot read 8749 so I cannot check if the
ROM contents are intact. I am looking for an adapter to do that.

Regards,
Michau.

       Message was sent through the cbm-hackers mailing list