idea for a universal disk interface

[Mike Katz]

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 
>>>> <cctalk at 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
>>>
>>>
>