26 Jul
2005
26 Jul
'05
6:15 p.m.
On Jul 26 2005, 14:42, Jules Richardson wrote:
I'm not sure how complex such a box would be. I
*think* an ST506-
interface drive looks pretty much like a big floppy, just with more
heads. Far as I know, it doesn't do anything intelligent on the drive
itself, just responds to head select / step commands from the
controller
and reads or writes data.
Yes, except normally the step pulses are buffered, so you can send them
fast and the drive will handle them at the correct rate. At least, all
but the oldest drives do that. That's the main difference between
ST506 (not buffered) and ST412 interfaces.
The bit I don't know is the nature of the data
signal at the
interface -
it uses +/- signal lines for both read and write data.
I'm not sure
if
that's an analogue signal or a digital one.
Digital.
I don't think there's a need to handle
anything complex in the
virtual
drive. I believe an ST506 drive's purely a data
store/replay device
and
it knows nothing of the actual data stored on it -
most of the
circuirty
on board is presumably just motor control and head
amplifiers /
filters.
Correct.
--
Pete Peter Turnbull
Network Manager
University of York
26 Jul
26 Jul
6:45 p.m.
On Tue, 2005-07-26 at 19:15 +0100, Pete Turnbull wrote:
Well that bit's easy then :)
I did just get to puzzling about what sort of sampling rate would be
needed to properly record data from the controller. I suppose the device
just needs enough memory per "track" to match the bit density * platter
circumference of whatever drive's being simulated.
cheers
Jules
On Jul 26 2005, 14:42, Jules Richardson wrote:
I suppose that's possibly not relevant for a solid-state replacement
though, as the device's ability to virtually step tracks will be far
faster than any controller of the period would produce?
I'm not sure how complex such a box would be.
I *think* an ST506-
interface drive looks pretty much like a big floppy, just with more
heads. Far as I know, it doesn't do anything intelligent on the drive
itself, just responds to head select / step commands from the
controller
and reads or writes data.
Yes, except normally the step pulses are buffered, so you can send them
fast and the drive will handle them at the correct rate. At least, all
but the oldest drives do that. That's the main difference between
ST506 (not buffered) and ST412 interfaces. The bit I
don't know is the nature of the data signal at the interface -
it uses +/- signal lines for both read and write data. I'm not sure if
that's an analogue signal or a digital one.
Digital. I don't
think there's a need to handle anything complex in the virtual
drive. I believe an ST506 drive's purely a data store/replay device and
it knows nothing of the actual data stored on it - most of the circuirty
on board is presumably just motor control and head amplifiers / filters.
Correct. 
8:21 p.m.
On Jul 26 2005, 14:42, Jules Richardson wrote:
...
> I don't think there's a need to handle
anything complex in the virtual
> drive. I believe an ST506 drive's purely a data store/replay device and
> it knows nothing of the actual data stored on it - most of the circuirty
> on board is presumably just motor control and head amplifiers / filters.
You'd need to encode the bits correctly so the data/clock seperator
worked, and send the index pulse. But other than that it's just a bit
stream.
humm.... :-)
As I recall the interface is essentially 5V TTL. I'm sitting here
starting at an arm cpu with a cpld on it and about 34 gio pins, all 5v
compatible... hummm... :-) I wonder if this little SAM7S cpu could keep
up. hummm....
-brad
10:10 p.m.
On Jul 26 2005, 14:42, Jules Richardson wrote:
...
> I don't think there's a need to
handle anything complex in the virtual
> drive. I believe an ST506 drive's purely a data store/replay device and
> it knows nothing of the actual data stored on it - most of the circuirty
> on board is presumably just motor control and head amplifiers / filters.
You'd need to encode the bits correctly so the data/clock seperator
11:47 p.m.
Tony Duell wrote:
Ah, sorry. I didn't get it. You want it to be universal.
I was thinking you could act like most common controllers and encode
data that was actually on a server, a sort of "nfs server with an st-506
interface".
I never thought about it the way you are proposing... hummm... :-)
thanks!
-brad
(lately I've been making MSCP disk images with simh and then dd'ing them
onto zip drives and booting them on an pdp-11, so you can see why I'd
be in the 'server' mindset. I really want a SCSI server....)
You'd need to encode the bits correctly so the data/clock seperator
That's just what I'd not want to do. You can't make any asumptions about
the clock/data encoding scheme if you want this emulator to be universal
(after all, a real ST506 doesn't do anything to the pulse stream other than
record it on the disk, unchanged [1]).
That was the reason for the high (10*, 8* would probably be OK as well)
sampling rate. Just record the pulses to memory, then play them back.
27 Jul
27 Jul
1:05 a.m.
New subject: cctalk archive search?
is the cctalk archive search broken?
I searched for "tiff" and "scsi" and got no hits (using any or all).
is it just me ? :-)
-brad
1:50 a.m.
New subject: cctalk archive search?
Ethan Dicks wrote:
On 7/26/05, Brad Parker <brad at heeltoe.com>
wrote:
I tried cctech and it found things. cctalk did not.
-brad
is the cctalk archive search broken?
I searched for "tiff" and "scsi" and got no hits (using any or all).
is it just me ? :-)
Case sensitive?
10:08 p.m.
You'd need to encode the bits correctly so the
data/clock seperator
That's just what I'd not want to do. You can't make any asumptions about
the clock/data encoding scheme if you want this emulator to be universal
(after all, a real ST506 doesn't do anything to the pulse stream other than
record it on the disk, unchanged [1]).
That was the reason for the high (10*, 8* would probably be OK as well)
sampling rate. Just record the pulses to memory, then play them back. I was thinking you could act like most common
controllers and encode
data that was actually on a server, a sort of "nfs server with an st-506
interface".
That's a secondary issue. Once you have something that looks like an
ST506 drive to any controller you care to name, and which stores the
bitstream in semicondcutor memory, you can then consider a server that
loads images from, say, a SCSI drive into that memory.
-tony
29 Jul
29 Jul
8:43 p.m.
Tony Duell wrote:
That's a secondary issue. Once you have something that looks like an
ST506 drive to any controller you care to name, and which stores the
bitstream in semicondcutor memory, you can then consider a server that
loads images from, say, a SCSI drive into that memory.
I think you're overthinking this. I can't see it being that hard to
adapt the mechanical bits of a different drive to a given set of
electronics. Come to that, I don't really see how it could be that hard
to repair ST506 drives, assuming they had not suffered a catastrophic
head crash.
They were built in relatively dirty environments compared to today's
clean rooms, out of bits that were very high precision *then* but pretty
crappy now. If I can walk into my local SKF or Timken stockist and pick
up the incredibly obscure bearings for my gearbox off the shelf, why not
a hard disk?
Gordon.
9:56 p.m.
On Fri, 2005-07-29 at 21:43 +0100, Gordon JC Pearce wrote:
Tony Duell wrote:
Repairing the drive only buys you time though - there will come a point
where working ST506 drives are next to impossible to get hold of. Being
able to understand the data at the signal level's the first step toward
being able to interpret and archive it - which is invaluable for
preserving machines where no good backup process exists, or install
media doesn't exist, or the disk controller is totally proprietary.
That's a secondary issue. Once you have something that looks like an
ST506 drive to any controller you care to name, and which stores the
bitstream in semicondcutor memory, you can then consider a server that
loads images from, say, a SCSI drive into that memory.
I think you're overthinking this. I can't see it being that hard to
adapt the mechanical bits of a different drive to a given set of
electronics. Come to that, I don't really see how it could be that hard
to repair ST506 drives, assuming they had not suffered a catastrophic
head crash. They were built in relatively dirty environments
compared to today's
clean rooms, out of bits that were very high precision *then* but pretty
crappy now. If I can walk into my local SKF or Timken stockist and pick
up the incredibly obscure bearings for my gearbox off the shelf, why not
a hard disk?
Because they were never sold presumably, unlike gearbox bearings.
Presumably there are parts of a hard disk that never left the factory
except in a complete drive.
Swapping electronics boards / repairing them's a bit more viable - but
it does just put off the inevitable...
Any machine's going to eventually fail due to natural chip destruction
(50 - 100 years?), but anything with a mechanical nature's probably
going to fail long before that.
cheers
Jules
11:58 p.m.
Jules Richardson wrote:
Yes, and the spindle motor bearings in an ST506 are probably standard too
(although with considerably less run-out than any car gearbox bearing
I've seen!). The problems are :
1) Fittlng new beraings to the spindle motor (which was assembled with a
press, and which wasn't designed to ever come apart
2) Bearing failure is not a common problem in these drives. Other parts
are a lot more speciallised.
-tony
Because they were never sold presumably, unlike
gearbox bearings.
Presumably there are parts of a hard disk that never left the factory
except in a complete drive.
Nah, all bearings are standard.
11:50 p.m.
Tony Duell wrote:
Maybe you want to try interfacing the HDA from a modern drive, with
unknown embedded servo patterns, etc, to the electronics from an ST506. I
don't think that's totally trivial.
That's a secondary issue. Once you have something that looks like an
ST506 drive to any controller you care to name, and which stores the
bitstream in semicondcutor memory, you can then consider a server that
loads images from, say, a SCSI drive into that memory.
I think you're overthinking this. I can't see it being that hard to
adapt the mechanical bits of a different drive to a given set of
electronics. Come to that, I don't really see how it could be that hard to repair ST506 drives, assuming they had not suffered
a catastrophic
head crash.
OK, I have an ST412 (maybe an ST506, it's one of the early ones) where
the hall effect sensor in the spindle motor has failed. Now, it should be
possible given a moderate clean room to dismantle the heads and platters
(and that's the only way that spindle motor will come out), but then
what? It was put together with a press, there are probably ferrofluid
seals on the shaft, etc. It's not going to be easy to take apart and get
togerther again. I know I don't have the tools to do it.
-tony
30 Jul
30 Jul
12:25 a.m.
Tony Duell wrote:
OK, I have an ST412 (maybe an ST506, it's one of
the early ones) where
the hall effect sensor in the spindle motor has failed. Now, it should be
possible given a moderate clean room to dismantle the heads and platters
(and that's the only way that spindle motor will come out), but then
what? It was put together with a press, there are probably ferrofluid
seals on the shaft, etc. It's not going to be easy to take apart and get
togerther again. I know I don't have the tools to do it.
Can you get at any rotating part of the motor?
Simple enough to graft on your own hall-effect sensor...
Gordon.
6:15 p.m.
Tony Duell wrote:
Timing and pulse count needn't be that important. You'd feed the output
Can you get at
any rotating part of the motor?
Simple enough to graft on your own hall-effect sensor...
YEs, and kludge on magnets to give the right number of pulses per
revolution with the right timing.... from "your" sensor into a PLL to derive the
correct output frequency.
Of course at this stage, it's probably easier to build new hard drive
mechanicals from scratch. Seriously. Look at how cheap and attainable
CNC lathes are these days.
Gordon.
7105
days inactive
7109
days old
16 comments
6 participants
participants (6)
-
ard＠p850ug1.demon.co.uk -
brad＠heeltoe.com -
ethan.dicks＠gmail.com -
gordon＠gjcp.net -
julesrichardsonuk＠yahoo.co.uk -
pete＠dunnington.u-net.com