Hi Tony,
Based on my experiences with Pentina, I don't
believe a cat makes a
unique sound...
You're speaking of the individuality of a DOG! A cat makes
miau! :-)
I am sure Pentina is a cat. And he certainly males many different noises...
Anyway, I assume you know it's not headcrashing (which can make a noise
like a very angry cat). I think you'd know if that was the case...
No crash.
But I have to admit that I got the drive crashed a few years
ago. After cleaning and using another pack it worked. I had 3 packs for it.
I assuem it has worked since the crash. Could the heads have been damaged
by the crash?
At some point in history I got a bunch of packs. They
were used with a
somewhat dubious Nova clone system (DDC or DCC). They never really
worked fine.
A few months ago now the drive completely broke down: After having
successfully used the machine for several hours and pausing for another
few weeks, I ran into disaster: A mechanical buffer at the back of the
head slide had changed to a sticky liquid and blocked the whole
mechanism. That resulted in the heads staying on disk while the drive
did an urgency spindown.
Hang on.. Are you saing the heads landed on the disk? And that the drive
hasn't worked properly since that? I really wonder if the heads have been
damaged.
I disassembled the whole thing and cleaned away the
mess as good as
possible. I did not touch the head alignment. The heads stayed bolted to
their slide and were taken aside as a whole block. I also took care for
the heads not getting in contact.
This week I reassembled the drive and tried it out. The cartridge that
was in the drive during the disaster was far gone and runs with
"pre-crash" noise.
I realized that I had only the dubious packs. Some of them as I found
out yesterday can be formatted by the Emulex SC02 controller's low level
format routine, some stop shortly before the end (as I explained
before). When I then try to use them, I can run "INIT/BADBLOCKS" under
RT11 which says no bad blocks. Then when copying data in, I get write
errors and bad blocks. Number increases. They stay and are in the system
area most of the time. So I cannot use the packs :-(
The whole procedure can be repeated using the low-level formatting
routine and then RT11 INIT.
OK... The formatting routine must move the heads across the disk surface,
and it will read (but not write) the servo surface. Can you 'scope the
output of the srrvo preamplifier while it's doing this? See if the signal
changes in amplitude or whatever.
That leads to the idea that there's something wrong about the data as well.
This sounds somewhat similar in concept to the
CDC 'Phoenix' drive.
There's a separate servo surface for the remvoable pack (one servo, one
data), and the 3 fixed disks (1 servo, 5 data surfaces).
Exactly.
But there are differences. I don't think there's any oil-filled damper on
the Phoenix.
What do you mean by 'outer' tracks? Normally, I would take that to mean
ones closest to the edge of the disk, but it appears you mean ones neares
the spindle.
Sorry, meant "inner", of course! I was tiredly writing in
foreign English...
OK. I was just making sureI knew where the problem area was.
Do you have schematics and a 'scope?
Yes. But... Sorry for saying that: That machine has a very very low
priority in my project queue as it's something from the 80s. I currently
OK... Alas I suspect this is not going to be a quick fix.
have enough older stuff to repair (RK05s, TU56s,
PDP8/I, PDP8/Ls,
Honeywell DDP-516 and H316 reconfiguration and testing, etc.). I just
wanted to get it either working and back in the rack or out of the
window (i.e. give it to someone else, NOT trashing it!).
What about any velocity
feedback signal?
Speed might be worth a thought:
- If running too slow, servo and data head read levels might be low. I
doubt that it's that but this could serve as an explanation for servo
AND data problems.
No, I was thinking of the positiuoner velocity signal. Most hard disk
positioner servoos use a signal that depends on the speed of head
movement (nothing to do with the rotating disk). It helps to stabilise
the servo loop.
That would
have been an early guess of mine (lost of
this can make the servo unstable), but why would it only affect the
removeable pack?
I'm not 100% sure but I think to remember that the fixed and
the
removable disk use separate motors. At least I remember a power plug
labelled "motor 2"!
That is certainly not a Phoenis. The Phoenics has ome spindle motor for
all the disks and one positioner that moves all the heads.
Can you look at the output of the servo head
preamplifer when using the
fixed disk (which works correctly) and the remveable disk?
I'll try to.
Step one
cylinder at a time going towards the 'bad' part and see if you can notice
any changes in the signal.
I have nothing to single step the drive. No exerciser
and no pdp11
You could use the formatter routine for this.
programming experience (yet, will come when I get to
resurrect the
11/20). And there's that Emulex controller between the pdp and the
I don't know the controller you are using. Is is an MSCP one? If not,
then moving the heads should just be a matter of puttign the right
numbers inthe controller registers, something that you can do with the
frontpanel or Console ODT.
drive. That remaps the disk afaik.
I do have a CDC Phoenix service manual, if you
think the drives are
related I can take a look...
I have the complete manual with schematics sitting
here.
BTW would it be good to scan it for Bitsavers? I could easily do that as
it's a ring binder and my newly acquired scanner is hungry for paper...
Well, it would have the advantage that I could (somehow) get to look at
it and might have more suggestions :-)
-tony