Re: MFM drive gone nuts

From: Julian Perry <>
Date: Sun, 20 Jul 2014 23:38:31 +1000
Message-ID: <>
Hello Michał,

Sunday, July 20, 2014, 8:57:17 PM, you wrote:

> Hello!

>> That's a Miniscribe 3650, I presume. (Or it's RLL brother, 3675)
>> I sold many of them back in the 80's, and I'm quite familiar with
>> them. It's been left in burn-in test mode.

> The sticker in the front says it is a MiniScribe 3425, according to the
> information on the Internet it's a 20 MB model.

Ah! - I was close, but no cigar... :) The drive DID sound the same,
and the track 0 detent is very similar.

>> I THINK the first three jumpers have to be in place for normal
>> operation - if one's nicked, it goes into one of several test modes.
>> One is a "fanout" seek test, the other a random, another a sequential
>> step test. it's been a VERY long time between drinks.
>> Have a play with the first 3 jumper positions (the ones on the edge
>> over the narrow edge connector).

> Ah, I found them! They were well hidden under the platter and hardly
> accessible. They are DIP switches, not jumpers, and changing the second
> jumper disabled the seek test.

> However, the drive is still not recognized by the controller - still all
> operations result in a timeout. I played with switches 1-4 but none of
> the configurations worked. However, the drive access LED is ON when the
> computer tries to read from the drive, for what it's worth.

A quick googling found THIS URL :
It has the switch settings, including the various manufacturers
"Actuator Exerciser modes" for your drive.
Timeouts (as opposed to read errors) would normally be tied to "Drive
Ready (Pin 22), or Drive Select" problems?.
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.

>> But all is not lost - I could go through the whole process of checking
>> the drive but this guide from Miniscibe is pretty comprehensive and
>> though may not be specific to your drive model, it will be pretty close.
>> **

> Thank you, I have browsed through it. Unfortunately, all the procedures
> described in it are for DOS so they are no help in reading the drive
> from C900. As a last resort, I will try to dump the drive from a PC
> side, but I am reluctant as to reformatting it because that would mean
> destroying all Coherent data that may reside on it.

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.

>> On PC controllers, they should always be jumpered as DS1, and the cable
>> twist makes the drive on the end (which should be terminated) drive 0.
>> (only ONE DS jumper should be enabled at any one time.

> That got me thinking. The drive is jumpered as the drive 0, but the
> cable is NOT twisted. Does it mean that the drive should be jumpered as
> drive 1?

I THINK the "cable twist" phenomena was exclusively a PC requirement.
See my earlier suggestion re: jumpering ALL drive-select lines. It
would be disastrous if more than 1 drive was installed, or where the
controller OS was trying to write to more than one drive - but from at
least a testing perspective it's worth trying. Mind you, it's far from

Also - DO check that you don't simply have the connector on
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.

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.

> The cables are terminated properly on the drive from what I can see.

> Regards,
> Michau.


(Good God - quite a wall of text there!)

       Message was sent through the cbm-hackers mailing list
Received on 2014-07-20 14:00:02

Archive generated by hypermail 2.2.0.