Disk hardware emulation, was Re: Grandfather system RTE6/VM?

From: Peter C. Wallace <pcw_at_mesanet.com>
Date: Sat Dec 6 11:24:12 2003

On Sat, 6 Dec 2003, Tony Duell wrote:

> >
> > On Fri, 2003-12-05 at 15:46, Tony Duell wrote:
> > > > 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...
> >
> > 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....
>
> > > 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.


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...



>
> 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
Received on Sat Dec 06 2003 - 11:24:12 GMT