ST-506 hard drive emulation

Peter C. Wallace pcw at mesanet.com
Tue Jul 26 18:40:56 CDT 2005


On Tue, 26 Jul 2005, Jules Richardson wrote:

> On Tue, 2005-07-26 at 15:54 -0700, Dwight K. Elvey wrote:
>>> From: ard at p850ug1.demon.co.uk
>>> [1] THat is a simplfication. IIRC, a rising (falling?) edge of the write
>>> data line causes a flux transition on the disk. The opposite edge is
>>> ignored. On read, a flux transition on the disk causes a pulse on the
>>> read data line, the width of this pulse is fixed (determined by a
>>> one-shot on the drive logic board). There are restrictions as to how fast
>>> and how slowly you can send pulses, due to the design of the read
>>> amplifier/filter.
>>>
>>
>> Hi
>>  This is my understanding as well. This means that you can't
>> just play back the signal written. The write signal
>> has compensation for the timing shift caused by signals
>> being close together on the disk surface.
>
> I was worried about the precomp too. However I think that for ST412
> drives at least, the precomp's done within the drive; the controller
> knows nothing about it.
>
> I *think* it's only relevant for ST506 drives (<= 8 heads), and even
> then not all drives used it.
>
> At least that's what I gathered from some googling earlier - haven't had
> a chance to look at the docs mentioned on here earlier yet.
>
> I wonder what the bit density of one of these drives is? I mean, is it
> possible to simulate a whole raw track in memory, so that it doesn't
> matter about timing as you're essentially digitising the disk surface at
> 1 bit / sample. Maybe that requres a *huge* amount of storage though,
> but I'm presuming the bit density figure is the smallest transition that
> the drive can handle, and no amount of messing around through external
> write precomp will change that?
>
> Again, it's wasteful - but it really would be a raw snapshop the drive.
>
> cheers
>
> Jules
>

Even at 16X sampling (80 MHz) a 1/60 second snapshot is only 1.33 million 
samples per track. You probably only need one track buffer so this is < 256k 
Bytes of RAM. With say 32 bit data storage thats only a 2.5 MW/sec data rate 
so the controller could be easily done with a FPGA or even CPLD and a 
dedicated fairly fast CPU.


Peter Wallace


More information about the cctalk mailing list