15 Feb
2014
15 Feb
'14
4:12 p.m.
Just curious as to what the expert opinion is on this - I've got a
ST412-type drive here (it's a Miniscribe with 615/4/17 ~20MB geometry)
which refuses to read from cylinders 128-255 or cylinders 384-511 - giving
address mark not found errors - although cylinders outside those two ranges
are fine.
The way the faults lie exactly within a couple of specific bit patterns
(01xxxxxxx and 11xxxxxxx) for the cylinder number makes it seem more like a
controller problem to me - but I don't know how much logic there is on a
ST412-type drive, what with the buffered seek ability.
Controller passes internal/RAM diagnostics OK (but how exhaustive those
are, I don't know). Issuing a drive recalibration and/or controller reset
prior to attempting access to the problem areas makes no difference.
Maybe the drive was simply never formatted on those cylinder groups for
some reason - but that seems rather unlikely (and the filesystem on the
drive is definitely unwell, suggesting that it's trying to access data
that's no longer there, although I've not gone to the extent of picking the
FAT apart to verify this)
I think all the errors I've seen before on these kinds of drives have been
totally dead, seemingly random, or confined to all/parts of a surface - not
in cylinders.
cheers
Jules
15 Feb
15 Feb
5:10 p.m.
On 02/15/2014 04:12 PM, Jules Richardson wrote:
Just curious as to what the expert opinion is on this - I've got a
ST412-type drive here (it's a Miniscribe with 615/4/17 ~20MB geometry)
which refuses to read from cylinders 128-255 or cylinders 384-511 -
giving address mark not found errors - although cylinders outside those
two ranges are fine.
ST506/412 controllers typically don't have a lot of smarts. Have you
tried low-level formatting the drive?
--Chuck
16 Feb
16 Feb
12:57 p.m.
On 02/15/2014 07:10 PM, Chuck Guzis wrote:
On 02/15/2014 04:12 PM, Jules Richardson wrote:
I have days like that, too...
Just curious as to what the expert opinion is on this - I've got a
ST412-type drive here (it's a Miniscribe with 615/4/17 ~20MB geometry)
which refuses to read from cylinders 128-255 or cylinders 384-511 -
giving address mark not found errors - although cylinders outside those
two ranges are fine.
ST506/412 controllers typically don't have a lot of smarts. Have you tried low-level formatting the drive?
No, not yet - I'm trying to salvage what I can off it first. The
controller's a Xebec ISA board which is almost identical to the 'variation
#3' board here: http://www.minuszerodegrees.net/ibm_xebec/ibm_xebec.htm
with the exception that mine has solder pads for selecting DMA / IRQ and
jumpers for I/O and ROM address, but otherwise appears to be the same. As
there's a link to the board schematics and programming information there,
it's possible that I might be able to do some further diagnosis on the
controller side.
Unfortunately I don't have a spare drive which I can attempt a format on,
but if one ever falls into my lap I can give that a go, too.
I wonder if all Xebec boards use the same track format? I do have some
SCSI<->STxxx bridge boards in storage overseas, so maybe I can try one of
those when they eventually join me on this side of the pond. (I think a few
years ago someone was attempting to document compatibilities between
different STxxx controller boards, but I don't know if anything ever came
of it)
cheers
Jules
3:09 p.m.
On 02/16/2014 12:57 PM, Jules Richardson wrote:
On 02/15/2014 07:10 PM, Chuck Guzis wrote:
No, not yet - I'm trying to salvage what I can off it first. The
controller's a Xebec ISA board which is almost identical to the
'variation #3' board here:
i've had several of those over the years and the IBM and Xebec
variations do use the same track format as far as I've been able to
tell. I'm not so sure about the Xebec bridge boards, however.
--Chuck
12:50 p.m.
Just curious as to what the expert opinion is on this - I've got a
ST412-type drive here (it's a Miniscribe with 615/4/17 ~20MB geometry)
which refuses to read from cylinders 128-255 or cylinders 384-511 - giving
address mark not found errors - although cylinders outside those two ranges
are fine.
The way the faults lie exactly within a couple of specific bit patterns
(01xxxxxxx and 11xxxxxxx) for the cylinder number makes it seem more like a
controller problem to me - but I don't know how much logic there is on a
ST412-type drive, what with the buffered seek ability.
My first guessis that for some reason the controller is losing the 128's
bit from the cylidner register and is, in fact, goign to the wrong cylinder.
A couple of ideas :
Is there a command that will read the sector headers fro mthe currnet
cylinder? If so, seek to cylinder 128, say, and red the headers to see
wht cylinder iut is acutally on.
Seocndly, is any part of the positioner mechanism visible outside the HDA
(some drives had a 'flag' and optoswitch on the stepper spindle for the
track 0 posiiton sensor, this 'flag' moves as the heads seek. If so, then
seek to cylinder 127, then seek to cylinder 128. If the positioner moves
a fair distance -- and in the wrong driection -- you will know something
is up.
This sounds much more like a controller than a drive problem to me.
-tony
5:27 p.m.
On 02/16/2014 02:50 PM, Tony Duell wrote:
Right... although as Tom suggests, my understanding (possibly erroneous) is
that the address marks are a little more low-level than the sector address
information - and if it was finding data, but confused about what cylinder
it was on, I'd perhaps expect a higher-level "sector not found" or read
error.
I'll have a look at the firmware listing for the IBM boards; although this
particular card has Mitsubishi firmware, I expect that behaviour upon error
is probably similar, so maybe I can deduce what might be causing it from there.
Just curious as to what the expert opinion is on this - I've got a
ST412-type drive here (it's a Miniscribe with 615/4/17 ~20MB geometry)
which refuses to read from cylinders 128-255 or cylinders 384-511 - giving
address mark not found errors - although cylinders outside those two ranges
are fine.
The way the faults lie exactly within a couple of specific bit patterns
(01xxxxxxx and 11xxxxxxx) for the cylinder number makes it seem more like a
controller problem to me - but I don't know how much logic there is on a
ST412-type drive, what with the buffered seek ability.
My first guessis that for some reason the controller is losing the 128's
bit from the cylidner register and is, in fact, goign to the wrong cylinder. A couple of ideas :
Is there a command that will read the sector headers fro mthe currnet
cylinder? If so, seek to cylinder 128, say, and red the headers to see
wht cylinder iut is acutally on.
Not that I know of - at least at the BIOS level - there's an explicit seek,
and then a read which takes cylinder information as part of the parameters.
I'll look at the controller docs though, as perhaps they provide a little
more flexibility.
Seocndly, is any part of the positioner mechanism
visible outside the HDA
(some drives had a 'flag' and optoswitch on the stepper spindle for the
track 0 posiiton sensor, this 'flag' moves as the heads seek. If so, then
seek to cylinder 127, then seek to cylinder 128. If the positioner moves
a fair distance -- and in the wrong driection -- you will know something
is up.
Oh, that's a great idea - thanks. Yes, the drive has a horizontal stepper
for the positioner, with an external interrupter for track 0 detection, so
it'll be easy to see if it does anything unusual around the problem cylinders.
This sounds much more like a controller than a drive
problem to me.
Yes, it did to me too - but I wasn't certain about how much intelligence
the drives contained regarding keeping tabs of what cylinder they were on.
cheers
Jules
17 Feb
17 Feb
12:54 p.m.
On 02/16/2014 02:50 PM, Tony Duell wrote:
Right... although as Tom suggests, my understanding (possibly erroneous) is
that the address marks are a little more low-level than the sector address
information - and if it was finding data, but confused about what cylinder
it was on, I'd perhaps expect a higher-level "sector not found" or read
error.
Ture, but I am not sure how 'correct' the errors reported by your
controller are. I've had erros that the docuemtnion explains as one thing
and which actually were due to somethign totally differnet.
One thing you might try if you have the appropraite test gear : Monitor
the step and driection lines on the ST412 interface conenctor. Seek to
cylkinder 127, start monitoring and then seek to cylidner 128. If the
signals say it's stepped one cylinder inwards, then the controller is
probably doing the rigth thing. If signals indicate it's doen a lot of
steps outwards, then I would certainy suspect that 128's bit is not
gettign through in the controller.
-tony
Just curious as to what the expert opinion is on this - I've got a
ST412-type drive here (it's a Miniscribe with 615/4/17 ~20MB geometry)
which refuses to read from cylinders 128-255 or cylinders 384-511 - giving
address mark not found errors - although cylinders outside those two ranges
are fine.
The way the faults lie exactly within a couple of specific bit patterns
(01xxxxxxx and 11xxxxxxx) for the cylinder number makes it seem more like a
controller problem to me - but I don't know how much logic there is on a
ST412-type drive, what with the buffered seek ability.
My first guess is that for some reason the controller is losing the 128's
bit from the cylidner register and is, in fact, goign to the wrong cylinder.
19 Feb
19 Feb
6:51 p.m.
On 02/16/2014 07:27 PM, Jules Richardson wrote:
On 02/16/2014 02:50 PM, Tony Duell wrote:
Well, I got some time just now to hack some code for testing this. The
controller doesn't seem to support seek operations, but doing a read (which
takes c/h/s parameters) and ignoring the returned data seemed like a fair
substitute. And... wow, is this thing ever confused...
So, at power-on (and after the drive's up to speed), the stepper goes
through more than one revolution before settling at what I'm assuming is
cylinder 0 (the interrupter on the end of the shaft is in line with the
detector) - in other words, available head travel doesn't limit it to < 1
revolution.
If I attempt successive reads from cylinders 0-614, I can see the head
positioner advance as expected from cylinders 0-63. At cylinder 64, the
stepper jumps to a completely new part of the arc, but then advances
"linearly" (if you see what I mean) from there in the range 64-127 - I
don't know why this range wouldn't simply follow on from where cylinder 63
was! At the sector level there's obviously valid data there, although
whether it's the data that DOS is expecting to be in that physical spot on
the disk is another matter.
Now, in the cylinder range 128-255, the stepper doesn't move at all, it
just stays stuck where it left off at cylinder 127. At cylinder 256, it
appears to reset to the cylinder 0 position (but it's hard to tell for sure
where the heads physically are on the disk; remember that that stepper is
capable of > 1 revolution, so I'm just going by the interrupter position).
The stepper then advances "normally" for reads in the range 256-319, but at
320 it mimics the behaviour of cylinder 64, suddenly jumping to a different
part of the arc, before once again advancing "normally" for the 320-383 range.
Between 384-511, we see a repeat of 128-255, with the stepper not advancing
(staying where the read from cylinder 383 left it). At cylinder 512, it
suddenly jumps to - apparently - cylinder 0 position, and then the stepper
advances "normally" up until the last cylinder on the drive (611)
I'm not sure what my next move is - possibly hooking some magic up to the
step/direction lines so I can monitor exactly what they're doing, which
would at least enable me to determine if it's the drive or the controller
at fault. I'm particularly curious whether there really is a sudden burst
of step pulses between read attempts from cylinder 63 and 64, for instance.
cheers
Jules
Seocndly, is any part of the positioner mechanism
visible outside the HDA
(some drives had a 'flag' and optoswitch on the stepper spindle for the
track 0 posiiton sensor, this 'flag' moves as the heads seek. If so, then
seek to cylinder 127, then seek to cylinder 128. If the positioner moves
a fair distance -- and in the wrong driection -- you will know something
is up.
Oh, that's a great idea - thanks. Yes, the drive has a horizontal stepper
for the positioner, with an external interrupter for track 0 detection, so
it'll be easy to see if it does anything unusual around the problem cylinders.
16 Feb
16 Feb
2:04 p.m.
Interesting
The fact that u are getting solid AMNF errors in two 128 cylinder bands also
suggests to me some sort of controller problem
The drive doesn't know about AMs; that's handled by the controller. The
large amount of AM errors suggests to me the tracks were not written (or
overwritten with a different controller). If the tracks were formatted u
should be seeing seek errors or data errors. The drive interface is step and
direction; during a low level format it single steps so it's internal
buffering of the step pulses shouldn't be invoked. But even if u wound up
at a wrong track there should be count fields that tell the controller what
track the drive is actually at and then the recovery becomes controller
firmware dependent (I think some controllers just re-seek and continue)
Have u done a low level (BIOS) format?
Tom
-----Original Message-----
From: Jules Richardson [mailto:jules.richardson99 at gmail.com]
Sent: Saturday, February 15, 2014 4:13 PM
To: xx Classiccmp mailing list
Subject: ST412 drive or controller fault?
Just curious as to what the expert opinion is on this - I've got a
ST412-type drive here (it's a Miniscribe with 615/4/17 ~20MB geometry) which
refuses to read from cylinders 128-255 or cylinders 384-511 - giving address
mark not found errors - although cylinders outside those two ranges are
fine.
The way the faults lie exactly within a couple of specific bit patterns
(01xxxxxxx and 11xxxxxxx) for the cylinder number makes it seem more like a
controller problem to me - but I don't know how much logic there is on a
ST412-type drive, what with the buffered seek ability.
Controller passes internal/RAM diagnostics OK (but how exhaustive those are,
I don't know). Issuing a drive recalibration and/or controller reset prior
to attempting access to the problem areas makes no difference.
Maybe the drive was simply never formatted on those cylinder groups for some
reason - but that seems rather unlikely (and the filesystem on the drive is
definitely unwell, suggesting that it's trying to access data that's no
longer there, although I've not gone to the extent of picking the FAT apart
to verify this)
I think all the errors I've seen before on these kinds of drives have been
totally dead, seemingly random, or confined to all/parts of a surface - not
in cylinders.
cheers
Jules
3740
days inactive
3744
days old
8 comments
4 participants
participants (4)
-
ard＠p850ug1.demon.co.uk -
cclist＠sydex.com -
jules.richardson99＠gmail.com -
t.gardner＠computer.org