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

From: Peter C. Wallace <pcw_at_mesanet.com>
Date: Tue Dec 9 20:46:37 2003

On Wed, 10 Dec 2003, Tony Duell wrote:

> I have been thinking about this a lot...)
>
> > But you really dont need 2G bytes of RAM... suitably encoded (instead of using
> > a wasteful bit stream, record and play back the delta-time between transitions
>
> Alas it's not as simple as that!
>
> There were 2 suggestions -- firstly to record the time of each
> transisition as a 20 bit number (i.e. would would be the RAM address in
> the simple scheme). The other is to record the time since the last
> transisiton, presumably as fewer bits.
>
> The second uses less memory _but_ suppose we use 8 bits for each time
> value. What happens if there's no transition for 256 sample times? I
> think that could happn at the end of a track if you're unlucky.

A simple RLL scheme could be used to encode longer times perhaps intersector
gaps or what not (say if we use a count of 4 bits, count value 15 means
continue the transition delay with the next nibble)

>
> But both schemes have another, more serious, problem. It's hard to change
> part of the data. You need to be able to re-write part of the track -- in
> particular a single sector. This is trivial on the 'record-the-bitstream'
> method. It's a lot harder if you're recording time values. It's not clear
> just which time values you're replacing (remember this has to be worked
> out in real time at abou 50-80MHz). What do you do if you replace a
> sector with one with more transitions? You have to shuffle all the data
> in the emulaotr's RAM down to make space for the extra transition time
> codes -- again in real time.

Yes thats an issue with _any_ compression scheme, a linked list might do it
though. Remember the the delta T values are not at your 50-80 MHz, only 10 MHz
max. This means that 32 bit memory data rates would be in the 2 Mhz region...

>
> Now, it may well be possible to compress the data in the emulator's main
> memory, or on the modern hard disk, and decompress it before writing it
> to the bitstream buffer. However, it's not clear how much compression
> will be possible (it's obvious that, in general, not all data can be
> compressed -- there are 2^n possible blocks of n bits, and you can't
> replace each one with a different block of m bits (there are 2^m such
> blocks) if m<n). And of course you need a sufficiently fast processor in
> the emulator box to do compression and decompression 'on the fly' during
> cylinder changes. Probably possible...

If you just compress your bitstream, a high compression rate is possible, at
least downto close to the original data content of the controllers data
stream (~8.5 kbytes per track?)

>
> > a $15 FPGA and a $15 Sync SRAM is just about all thats needed + the hardware
>
> If I had a pound for each time I've been told 'it can be done with an
> FPGA' then I wouldn't be worring about designing a disk emulator. Simply
> because I'd have a complete hard disk _factory_ of my own.
>
> Of course it can be done with an FPGA, but now is not the time to say
> that. Rather, you should be thinking about how to actually design the
> thing (which, BTW, I am doing), and only later worry about building it.

An FPGA implementation would be cheaper, easier to do, more flexible, easier
to debug (either with simulation or building debugging hardware into the
FPGA), buildable into the future, have higher performance and be more reliable
than a design made with bits-and pieces...


>
> I would not use an FPGA, though. There are several reasons for this, not
> the least of which is that debugging the design is hard. I don't trust
> simulators, and won't until I find one that gets all of my 'test cases'
> right (most get them all wrong!. Anyway, the FPGA simuation software I
> battled with couldn't even handle memory devices linked up to the FPGA,
> let alone simulating a hard disk controller's bitstream as well... No,
> I'd rather buiild the darn thing using standard ICs and debug it with the
> logic analyser. When the design is solid, then you can consider turning
> it into nn FPGA.

I have not had that much trouble with simulators, plus if there are free I/O
bits, its easy enough to built some temporary test scafolding into the FPGA. I
dont think I would like to try getting a 50-80 MHz wire wrapped system working
these days (even finding the DIP parts would be hard)


>
> Even then, it may not be a good idea. I've learnt the hard way that if
> you want a hobbyist to copy your design, you avoid programmed parts, no
> matter how simple they are to program (even PICs...) And you certainly
> don't get involved in providing ready-programmed parts unless you like
> providing free replacements to idiots who connect the power lines
> backwards...

But the FPGA is not a programmed part... only the downloaded bitsream contains
the "program" I dont worry too much about the inexpensive serial EEPROM
that stores the bitstream - they are easy to program (with nothing more than a
parallel port) and cost less than $1.50...


>
> Then there's the issue that FPGA chips change -- all too often. The new
> ones are claimed to be compatible (but 'better than the old ones'), but
> I've been bitten. Admittedly I was trying to push the device to its
> limits, but IIRC we had to hunt around for the old devices to have a
> hope of the final design working in time....

I guess I would rather port a design to a new FPGA than have to do a complete
re-design because some particular chip becomes unavailable

>
> -tony
>




Peter Wallace
Received on Tue Dec 09 2003 - 20:46:37 GMT

This archive was generated by hypermail 2.3.0 : Fri Oct 10 2014 - 23:35:50 BST