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

From: Peter C. Wallace <pcw_at_mesanet.com>
Date: Wed Dec 10 19:55:32 2003

On Wed, 10 Dec 2003, Tony Duell wrote:

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

No thats not bad, especially if you use SDRAM, which would be fast enough if a
small FIFO is used to smooth out the page crossing delays


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

Actually the Xilinx tools are free (Webpack)..

Its true you do need a Windows or Linux PC to do the design buts that a big
cost item

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


Unless you are running near the speed limits of the FPGA (we're not!) this
is very unlikely to be a problem.

Ive been doing hardware design for at least 30 years and FPGAs are a dream
compared to the bits-and-pieces way. No way would I ever want to go back...


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

But the design can be easily ported to new FPGAs I know, I've done it...

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

But the reduction in parts count alone would

1. Lower costs considerably
2. Improve reliability compared to a bits-and-pieces approach


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

Maybe you've been very unlucky...

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

Last time I did wire wrap was at least 28 years ago (making a 16K DRAMcard for
a TMS9900 system) I dont think I would like to start that again...


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

Not that I've seen and I've done it many a time...

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

Peter Wallace
Received on Wed Dec 10 2003 - 19:55:32 GMT