Which is more generic.
ESDI, SMD or SCSI.
In my opinion, SCSI is as close are you are going to get to a universal
interface.
As for reading raw data from a drive. The newer the drive, the higher
the bit density and lower the strength of the magnetic fields and hence
the lower the flying height. You have to deal with linear (or
horizontal) recording, perpendicular recording, Heat assisted magnetic
recording, microwave assisted magnetic recording. The latest
technologies are approaching 1TB (yes that's TB) per square inch.
If you spin the platters too slowly you will not be able to distinguish
individual magnetic fluctuations from noise. What do you propose as
your maximum data density (in BPI) and what is the minimum speed you
will need to accurately decode it.
Also once you get into newer drives the sectoring information may be
stored in EEPROM or ROM and not on the disk at all, that would make
decoding the data even more complicated as you don't know where a given
sector starts.
In addition to handling any number of encoding techniques (FM, MFM, GCR,
RLL, MAMR, HAMR, PMR, etc.) news drives also do bad sector mapping so
you would need to be able to handle that as well.
Some kind of programmable data separator (possibly and external DSP)
might be able to handle the high aerial densities.
The GreaseWeazle does this for floppies. That architecture might be a
good starting point to ramp up for hard drives.
Well, that's my 2 cents.
On 4/18/2022 5:09 PM, Douglas Taylor via cctech wrote:
Because of this I'm holding on to my DEC Qbus ESDI controllers!!! You
never know....
Doug
On 4/17/2022 4:35 PM, Guy Sotomayor via cctech wrote:
I chose ESDI and SMD fundamentally because the interface is 100%
digital (e.g. the data/clock separator is in the drive itself). So I
don't need to do any oversampling.
TTFN - Guy
On 4/17/22 11:12, Paul Koning via cctalk wrote:
On Apr 17, 2022, at 1:28 PM, shadoooo via cctalk
<cct...@classiccmp.org> wrote:
hello,
there's much discussion about the right method to transfer data in
and out.
Of course there are several methods, the right one must be
carefully chosen after some review of all the disk interfaces that
must be supported. The idea of having a copy of the whole disk in
RAM is OK, assuming that a maximum size of around 512MB is
required, as the RAM is also needed for the OS, and for Zynq
maximum is 1GB.
For reading a disk, an attractive approach is to do a high speed
analog capture of the waveforms. That way you don't need a priori
knowledge of the encoding, and it also allows you to use
sophisticated algorithms (DSP, digital filtering, etc.) to recover
marginal media. A number of old tape recovery projects have used
this approach. For disk you have to go faster if you use an
existing drive, but the numbers are perfectly manageable with modern
hardware.
If you use this technique, you do generate a whole lot more data
than the formatted capacity of the drive; 10x to 100x or so. Throw
in another order of magnitude if you step across the surface in
small increments to avoid having to identify the track centerline in
advance -- again, somewhat like the tape recovery machines that use
a 36 track head to read 7 or 9 or 10 track tapes.
Fred mentioned how life gets hard if you don't have a drive. I'm
wondering how difficult it would be to build a useable "spin table",
basically an accurate spindle that will accept the pack to be
recovered and that will rotate at a modest speed, with a head
positioner that can accurately position a read head along the
surface. One head would suffice, RAMAC fashion. For slow rotation
you'd want an MR head, and perhaps supplied air to float the head
off the surface. Perhaps a scheme like this with slow rotation
could allow for recovery much of the data on a platter that suffered
a head crash, because you could spin it slowly enough that either
the head doesn't touch the scratched areas, or touches it slowly
enough that no further damage results.
paul
