8 Dec
2008
8 Dec
'08
1:39 p.m.
Philip Pemberton wrote:
Hmm, well you could potentially use several SRAM ICs and couple them to
different buses as/when needed, but at the end of the day perhaps it's just
not worth the complexity.
Hmm, true. I suppose anything's possible though, without knowing the internals
of every STxxx drive ever made :-)
OK.
Yep.
I think I've got some Tandon and Epson drive schematics kicking around and
they used separate stages. But tapping into the head signal on a floppy drive
is a darn sight easier than a hard disk...
Yeah, I got around to thinking about moving the motors elsewhere - but you're
right about the head gap. I suspect it just plain won't work, but
speculation's always interesting :-)
cheers
Jules
Jules Richardson wrote:
I suppose ultimately it's going to depend on the speed of the machine
that's analysing the data, and the efficiency of the algorithm...
Yep. But I'm not sure that it's really rocket science - assuming that you know
what encoding format the data's actually in, which is probably the more
difficult part. Coping with errors might be interesting in some cases.
It might
take a while to process the data, though.
I really don't know - maybe some of the resident Catweasel experts can
comment there. I suppose to 'understand' an image we wouldn't be doing
anything in software that the drive controller doesn't normally do in
hardware. Assuming no read retries, and a head switching time of
zero (and an
infinitely fast hard drive to store the image on), that's a theoretical
minimum of 142.4 seconds.
I wouldn't expect it to be that fast, but ~15 minutes is probably a
reasonable estimate.
Well that'd do, I guess. Heck, that's hardly enough time for the electronics
to get up to working temp :-) But yeah, in the order of 15 mins is probably
realistic - I think it normally used to take about that to 'clone' a drive.
Can you read
from the buffer and transfer to the PC at the same time
as you're populating the buffer by reading from the drive?
No, it's a single-ported RAM. Either the MCU can control it, or the FPGA
can.
One option would be to add a second SRAM chip, which could be rigged as
a ping-pong buffer (while track N is being downloaded, track N+1 is
being read). Uh huh. So I
do think that theoretically you could have a transition
time the length of the track. No likely, but possible. In the middle
of that extreme and 'normal data' there may well be transition times
that are quite high, so they do need to be recorded (so that you can
hopefully recover sectors of a damaged track beyond the bad spot)
Thing is, the AGC on the head amplifier will probably start boosting the
gain if it doesn't see any transitions in, say, 1/32 of a revolution. If
that happens, then you'll get a nice stream of garbage (more likely
spurious transitions inserted than transitions missed). The only way I can think of to get around that would
be to remove the
head-amp and bolt on an analogue amplifier
I'm not sure how easy it is to tap into that kind of thing on a lot of drives,
though. Possibly best left for real emergencies on a case-by-case basis...
Hmm, so
you're proposing that the reader actually tries to understand
the storage mechanism? I was thinking that it was a dumb device,
basically copying the transitions that it sees to the host PC - and it
was the software on the PC which actually does the decoding (and
potentially requests re-read attempts at a later date).
No, I'm not proposing that at all -- my goal is to create a generic
reader/writer and do all the decoding work in software. "It slices, it
dices, it makes coffee, it feeds the cat!* (* Subject to software
availability)" :)
We have four cats here, and they eat a phenomenal amount - I'm not sure that
your device could keep up. :-)
That's probably worth looking into, but I know
very little about PCI
device design...
Ditto. Back in the day I wanted to get away from the internal card approach -
but these days it's possible to get a tiny, cheap motherboard and should be
relatively easy to build a networkable "external device" that's a complete
compact PC in its own right.
Well for hard
disks they're all flying heads anyway...
Only while the disc platters are spinning, AIUI... My ultimate
would be something which recorded the signal at a more
analogue level I think, for potential cleaning up in software later
(rather than using a digital interface which can't perform an
intelligent analysis of the data stream). I think it's do-able for a
floppy drive, and probably without a lot of modification to a donor
drive itself.
True. If you can live with read-only, it would be a head amplifier and
an A/D converter. The Commodore 1541 schematics (and the older CBM drive
manuals.. 1540?) might be a good reference -- IIRC some of those used
discrete amplifier circuitry instead of an all-in-one head
amplifier/threshold detector IC. (I've
mused before on here about running the entire drive in a bath of
something which might reduce friction and the chances of damage due to
contamination - it'd be interesting purely from an experimentation
point of view, but I'm not sure if it'd ever be possible to prove that
it actually helped)
Sounds like a nice idea, but I'd be somewhat worried about the effects
of whatever chemical you're using on the motor, and its effect on the
head/disc distance.