On Tue, 2005-07-26 at 19:01 +0100, Tony Duell 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
Correct. Don't uou have at least one ST506/ST412-interfaced drive schematic?
Nope, unfortunately not :-( I've got various manuals for bridge boards,
which of course have the connector pin-outs in (and give some of the
theory), but nothing for a complete hard drive (I suppose I'mactually
surprised such schematics ever escaped the drive manufactuers to be
honest, as presumably ST506/412 units were never supposed to be field
servicable?)
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.
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.
It's differentical digital. The line drivers are 26LS31s, the receivers
26LS32s (at least normally). It's much the same as the floppy read data /
write data line, just faster.
Aha, good.
The problem is that although the signal is digital in
amplitude (2
states), it's analogue in time. There are restrictions (both minimum and
maximum) on the time between data pulses, but apart from that you can
essentailly do what you like. The drive does not impose any restrictions
on the data format, the format of the sector header, etc. You could write
18 bit words if you wanted to.
I was googling for the proper spec earlier but so far haven't been able
to find it :-( (presumably because it's not something hobbyists ever
really messed with)
You need to sample and replay at about 10 times the
data rate. That's
50MHz. Do-able, but a bit harder than you imply.
If 8x is enough then that could make the logic easy I suppose, with 8
bit wide memory (some sort of shift register for writes, only clock data
into memory on every 8th clock pulse say).
Whether something like compact flash will handle that data rate
though... perhaps it requires buffering at the track level and only
writing to flash on track changes (which the controller presumably
expects to be quite slow). It gets a bit complicated at that point!
cheers
Jules