6 Dec
2003
6 Dec
'03
3:24 a.m.
On Sat, 6 Dec 2003, Tony Duell wrote:
But there are more efficient ways to store the data, imagine a large counter
(20 bits or so - our reference counter) That starts at 0 at Index time running
at your 60 MHz or so. If we just store the 4 LSBs of this counter in a RAM on
every input transistion, we can now play back the data from that RAM with our
60 MHz timing resolution. We play the data back by comparing the 4 LSBs from
our RAM buffer with the 4 LSBs from our reference counter, If they match we
output a transistion, and increment our RAM buffer pointer. The average data
rate of our (4 bit wide) RAM with is now no faster than the original
transistion rate from the drive) This puts an upper limit on the time between
transitions but thats probably ok for most (FM,MFM,RLL,GCR) encoding schemes.
another way of recording the "delta" times between transtions is a small
counter that is reset on every transistion. Then the saved data would just be
the delta times. This data is very easily compressable as (for FM) its
consists of a stream of alternate numbers something like 9 10 5 9 5 10 4 9 10.
This data can be easily stored with only a little more data than the original
track capacity...
All of this could be done in a $15 FPGA an a $15 sync SRAM...
On Fri, 2003-12-05 at 15:46, Tony Duell wrote:
Eh. It's unaesthetic, but computrons cost nothing. I agree with you, cpu
Hmmm.... I'd rather keep fast processors for the jobs that actually need
them. There's also the issue that everything I design is documented, and
PCs aren't....
My
suggestion (worth every cent you paid for it) is to use a whole damn
computer on the other side of the HD controller.
BLETCH!!! one reason I work with classic computers is to get away from
this rediculous modern notion that the way to solve a problem is to throw
CPU power at it without even thinking if there's an elegant solution... > Err, the interface is the tricky part
(I've got some sketched-out
> schematics of ideas I've had -- getting the darn thing to work at 50-80
> MHz and use easy-to-get components is the hard part...).
Thinking about it some more....
A hard disk rotates at 60rps (3600 rpm) (or at least the one I was
working on the other day had 60 index pulses per second). Suppose we
sample the data line at 60MHz (12 times the original data rate, this
should be about right), then we need about 1Mbit of data to store one
original track.
Or 128K bytes. We need to arrange some kind of shift register to turn the
bit serial data into 8 bit bytes and back again. To avoid timing problems
(and to allow the use of somewhat slower RAM), it's probably best to have
2 8-bot SRs and 16 bit wide RAM (with separate write enable lines for the
2 bytes). One SR is transferring data to/from the disk controlller while
the other one is transfering to/from RAM, etc.
Now, IIRC, the last ST506 drives had 16 heads. So that's 16*128K =
2Mbytes of data for one cylinder (and we need enough SRAM to buffer all
that, since we need to be able to switch heads fast (there's no 'seek
complete' line for head switching)). When the controller moves cylinders,
we need to possibly write that 2Mbytes to the modern hard disk (at least
those 128K 'tracks' that have been updated), and then re-load it with the
data corresponding to the new cylinder. That's a possibility of 4Mbytes
of data transfer total, in the time taken to move to a new cylinder.
Dunnon how long that would take (in theory it doesn't matter, since there
is a 'seek complete' line on the interface), but I do wonder if even a
modern hard disk and the circuitry to transfer the data between it and
the RAM is going to be slower than moving the heads on the old, original,
drive. In other words, will performance suffer?
I dont think thats a problem if the data is suitably compressed before saving
to SRAM...
Then there's the issue of writing out the last cylinder before
power-down. If there's no seek from said cylinder, then how will the
interfacee know it has time to write it?
Oh well, just some random thoughts.
-tony
Peter Wallace