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

From: Tony Duell <ard_at_p850ug1.demon.co.uk>
Date: Wed Dec 10 17:32:13 2003

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

This does, however increase the hardware complexity considerably....

I am not he sort of person who likes using excessive amounts of memory (I
have no problems writing micorocontroller programs in 256 bytes or
whatever). But I think in this case it makes sense to just buffer the
uncompressed data for each cylinder. You can compress it when storing it
on the modern hard disk if you like (it becomes a trade-off between data
transfer time and compression/decompression time. The actual space taken
up on the modern disk is irrelevant, as just about any modern hard disk
is large enough to store any ST506 image, even without compression.)

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

True. This is a good reason for not compressing the data in the sector
buffer.

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

Err, hang on... You now want to have a pointer associated with every data
word in the RAM (at least 16 bits long, presumably). The compression
looks a lot less atractive! You also have the problem of setting up the
pointers -- OK, when you start a write you can change the last pointer
before the changed block to point to some unused area of RAM, then start
storing the new values, but what do you do at the end. You have to point
back to the old values that correspond to transistions after the changed
region, but how do you find those quicky. And then you have to flag the
old area of memory as unused. And you may end up with fragmented gaps in
the memory after a number of writes, so you then have to search for
unused spavce, again in real time. Personally, I'll just use 2M of RAM
(which is not that many chips nowadays...)

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

Cheaper, maybe (but the cost of the development tools and the computer to
run them is not zero). Easier to do, not for me. More flexible, it
doesn't matter, since provided the emulator works with all ST506
controllers that's all that matters.

> to debug (either with simulation or building debugging hardware into the

Easier to debug, no way. I've designed with FPGAs, and I've designed with
simple logic chips. I know which is easier to debug. You have to be
_very_ careful modifying an FPGA design to include debugging pins, etc,
sinve re-routing the chip will change the propagation delays (this has
bitten me once, and the simulator didn't realise it either!!!)

> FPGA), buildable into the future, have higher performance and be more reliable

Buildable into the future, no. FPGAs seem to get replaced with new
versions far too frequently. On the other hand I have no problems getting
simple logic chips. You have to be careful which logic chips you use
(anyone desinging with a 7443, for example, is crazy), but simple gates,
D-tpyes, JKs, shift registers, etc are not hard to find.

Pereformace, it only has to be good enough to replace the ST506 drive.

More reliable, Hmmm... I've had a lot more LSI devices fail for no good
reason that TTL. I think my TTL-based minicomputers actuallly have the
fewest repairs of all the machines I own. I've never changed a TTL chip
in a PERQ (I have replaced RAM and the floppy disk data separator.

> I have not had that much trouble with simulators, plus if there are free I/O

You've been very lucky. THat's all I can say.... Either that, or you've
not seriously tested the simulator, you've just trusted it. I have a
number of circuits I throw at simulators to see what they make of them...

> bits, its easy enough to built some temporary test scafolding into the FPGA. I

As I said above, you have to be careful doing this..

> dont think I would like to try getting a 50-80 MHz wire wrapped system working

I've done that many times. It's not that hard if you know how to
terminate the signals, how to route them, etc. And use twised-pair
wire-wrap wire (hint : 3 twists per inch has a characteristic impedance
of 100 ohms, or thereabouts).

> these days (even finding the DIP parts would be hard)

The suppliers over here stock them. Anyway, what's so hard about SMD?

> But the FPGA is not a programmed part... only the downloaded bitsream contains

That depends o nthe FPGA family, I think. Some of them are programmed
internally.

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

As I mentioned above, that's not enough :-). A PIC (16C84, it was at the
time, now the 16F84) is trivial to program from a parallel port. But
hobbyists wouldn't try it...

> 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

Alas, often porting to a new FPGA _is_ a complete redesign...

Anyway, I've not had any problems finding 'classic' chips. Finding last
year's FPGAs, PLDs, or microcontrollers on the other hand....

-tony
Received on Wed Dec 10 2003 - 17:32:13 GMT