ST-506 hard drive emulation

[Tony Duell]

> >> You'd need to encode the bits correctly so the data/clock seperator
> >
> >That's just what I'd not want to do. You can't make any asumptions about 
> >the clock/data encoding scheme if you want this emulator to be universal 
> >(after all, a real ST506 doesn't do anything to the pulse stream other than 
> >record it on the disk, unchanged [1]). 
> >
> >That was the reason for the high (10*, 8* would probably be OK as well) 
> >sampling rate. Just record the pulses to memory, then play them back. 
> 
> Ah, sorry.  I didn't get it.  You want it to be universal.

Of course.

Otherwise you're likely to end up with a design that works on 
standard-ish controllers (like the PC ones, the DEC RQDX's, etc) where 
you could probably stick a different controller into a backplane slot 
anyway, but doesn't work on machines like the classic PERQ, where the 
disk cotnroller is (a) strange and (b) on a large board with the rest of 
the I/O sysstem, so it can't easily be replaced by soemthing else.
 
> I was thinking you could act like most common controllers and encode
> data that was actually on a server, a sort of "nfs server with an st-506
> interface".

That's a secondary issue. Once you have something that looks like an 
ST506 drive to any controller you care to name, and which stores the 
bitstream in semicondcutor memory, you can then consider a server that 
loads images from, say, a SCSI drive into that memory.

-tony