Looking for a ST419

Tony Duell ard at p850ug1.demon.co.uk
Sat Nov 1 14:40:49 CST 2008


> That's the path I've been on.  I envision over-sampling and then just
> playing and recording what was sent to the drive.  I'd make no attempt
> to go inside that datastream and try to interpret what was read or
> written.
> 
> If entire tracks were always written, then it seems rather straightforward
> to just store track images and play and record them as they are seeked
> to.
> 
> It may not be that much harder to do the same on a sector basis.  It's
> just more critical timing of when you play back stuff or decide which
> sector you are in when data comes at you with the write gate open.

It's not conceptually that complicated. The basic idea is to have 
an 'image' of a track stored in some kind of semiconductor memory. And 
you keep on replaying that a s bitstream into the read data input of the 
controller, generating an index pulse of course at the appropraite time.

When you get a write gate fro mthe controller you then start sampling the 
write data output from the controller and overwriting the stored 
bitstream. Yes, there might be glitches at the start/end of a write, but 
presumaly no wores than on a physical disk.

On a head swtich or head step (to a different cylinder) you replace the image
in memory with the correct one for the new track.

The problem is in the details. In particlur I don't think any normal 
flash memory will be fast enough to directly read out the track image and 
blast it to the controller, and I'm darn sure it's not fast enough for a 
direct write. Which means you need to have a buffer memory of high-speed 
SRAM to store the current track image This needs to be loaded from flash 
on a track change, and written back afterwards _iff it was updated by the 
controller_ 

Now, there are 2 types of track change, a head switch and a cylinder 
movement .The latter is easier, since it can take as long as you like 
(within reason), there's a seek-complete line back to the controller. But 
a head swithc has to be essentially instantaneous. Which probably means 
having enough SRAM to buffer the tracks for all heads on a given cylinder 
and then keeping an 'undated' flag for each track, writing back only 
those that have changeed. 

> 
> I have considered using the SPI (or similar) interface on a
> microcontroller to yield a parallel to serial/serial to parallel
> conversion but that is about as far as I have thought about this...

I didn't think SPI was anything like fast enough for this. 

I looked into using a _lot_ of F-series TTL chips, and rather gave up on 
the idea. Maybe I should have another go.

-tony



More information about the cctech mailing list