28 Nov
2008
28 Nov
'08
8:54 a.m.
What is the minimum satisfactory sampling rate if one
wanted to emulate an ST-412
interface and have it RLL (2,7)-capable?
2x, assuming you regenerate the clock. With a digital DLL, the incoming clock would
be on the order of 8x the maximum incoming frequency.
The bitstream is not variable frequency. You can think of what is needed as the inverse
of the read recovery circuit on the drive controller.
The tricky part is generating the recirculating bit stream that you send as read data
back from the simulated drive. It is expecting the data that it just wrote to be in
the data read back on the next revolution. And you need one of these bitstreams for each
head.
28 Nov
28 Nov
9:34 a.m.
On 28 Nov 2008 at 8:54, Al Kossow wrote:
The tricky part is generating the recirculating bit
stream that you
send as read data back from the simulated drive. It is expecting the
data that it just wrote to be in the data read back on the next
revolution. And you need one of these bitstreams for each head.
You only need to supply one track at a time--and you can hold off the
controller for any swapping you might need to do for a few msec. by
delaying the index pulse. An ST-412 track (surface) holds less than a
track on a 1.44MB floppy--it just spins 12x as fast.
I think it's probably quite doable if there's a market for it.
Cheers,
Chuck
11:39 a.m.
Al Kossow wrote:
The tricky part is generating the recirculating bit
stream that you send
as read data
back from the simulated drive. It is expecting the data that it just
wrote to be in
the data read back on the next revolution. And you need one of these
bitstreams for each
head.
An FPGA with a big shift register inside?
Or just use some on-chip RAM (e.g. BlockRAM), a counter and a pair of 8-bit
shift registers (two means you can load one while the other is shifting, and
eliminate any stream discontinuities caused by the shifter reloading). It's
not like SRs are particularly chip-intensive...
Or you could go with a board full of TTL....
Based on a quick look at the ST506/412 OEM manual (it's on bitsavers -- thanks
Al!) you're basically talking about a floppy disc data separator tweaked to
run at a higher clock rate... Store a "1" if there was a flux transition in a
given bit cell, or store a "0" if there wasn't.
Head-switching would be a total pig unless you buffered all 8 (or 16) heads at
once. 8us is not enough to ping an external IDE HDD (or say a CompactFlash or
SD card) and read off an entire track of data...
I don't even know how you'd be able to lock a PLL against the write data
stream quickly enough not to make a hash of it. Most data separators (or at
least the ones I've looked at) need a few bytes worth of encoded data to lock
onto before the data window signal is actually valid...
I suppose you could do what the Catweasel does and save the time between flux
transitions, but that opens up a whole other can of worms when you want to
write back to the disc...
--
Phil.
philpem at philpem.me.uk
http://www.philpem.me.uk/
29 Nov
29 Nov
4:34 a.m.
On 28 Nov 2008 at 19:39, Philip Pemberton wrote:
I suppose you could do what the Catweasel does and
save the time between flux
transitions, but that opens up a whole other can of worms when you want to
write back to the disc...
You could even do something like a Catweasel without incurring the
worms. Since there is a certain minimum time/distance between
transitions, you can sample adequately by storing a
byte/nibble/quantum of information at a rate only slightly faster
than this minimum time. The value reflects either no transition or
the time of the transition from the edge of the sampling frame.
Suppose this minimum distance between transitions is 200 nsec. You
need only read or store sample every 150 nsec or so. The only high-
speed part of the device is a counter that runs at whatever
oversample rate you're using. Start the counter at zero at the
beginning of every sample frame and store the value when a transition
occurs during writing; generate one using a comparator to generate a
pulse if a match is found between the value of this counter and the
stored sample value.
I feel awkward trying to explain this with words and no whiteboard,
but I hope you get the idea.
No need to bother with shift registers.
And no worms.
Cheers,
Chuck
3 Dec
3 Dec
5:50 a.m.
Head-switching would be a total pig unless you
buffered all 8 (or 16)
heads at
once. 8us is not enough to ping an external IDE HDD (or say a CompactFlash
or
SD card) and read off an entire track of data...
I don't even know how you'd be able to lock a PLL against the write data
stream quickly enough not to make a hash of it. Most data separators (or
at
least the ones I've looked at) need a few bytes worth of encoded data to
lock
onto before the data window signal is actually valid...
I suppose you could do what the Catweasel does and save the time between
flux
transitions, but that opens up a whole other can of worms when you want to
write back to the disc...
To emulate 10, 20, 30 MEGABYTES? It can be done with a few surplus RAM
chips or a good PC memory stick! 386's used 32 megabytes of simple DRAM, you
can get SRAM nowadays for next to nothing in surplus market. There are 2MB
ram chips from texas, and they are not that expensive. Why not have a SD for
backup and emulate ALL the drive in RAM? It will be **fast** and, when the
operation finish, you can press a button (or use some kind of sensing in the
computer) and backup the entire ram content to the SD card.
For the used computer market, it would sell like cake. And the cake
ISN'T a lie :o)
[],
Alexandre
(humming 'still alive')
(completely offtopic PS: Talkin'bout Portal, have you seen "A day in the
life of a turret"? No? So have a little laugh:
http://www.youtube.com/watch?v=Uz5cl131KTk - This is one of the stupidiest
and funniest thing I've ever saw :D)
5862
days inactive
5867
days old
4 comments
4 participants
participants (4)
-
aek＠bitsavers.org -
alexandre-listas＠e-secure.com.br -
cclist＠sydex.com -
philpem＠philpem.me.uk