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