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

I'd considered this too... With the real drives, there were 3 types : 1) Drives that did no prcompensation internally, it had to be done by the controller 2) Drives that did procompensation when the RWC/ signal was asserted (normally asserted by the controller on the inner cylinders) 3) Drives that did precompensation automatically based on where the drive knew the heads were. Most of the later ST506 drives ware (3), BTW. In cases (2) and (3) we don't need to worry. The bitstream from the controller is unmangled, so we can record it and play it back unchangged. In the case of (1), the original drive modifies the bitstream (that's what precompensation is for, it modifies the bitstream so the the drive changes it back again, and on reading, the cotnroller sees an unmangled bitstream). I don't know if most controllers would accept a precompenstated-but-not-changed-by-the-drive bitstream. Some controller have links to enable/disable precompensation. The Adaptec ACB4000 (I mention that one, since I have an ACW on the bench at the moment, so the details are stuck in my brain) has a link with 3 positions -- never precompensate, alwaus precompensate, and precompensate on inner cylinders (when RWC/ is also asseted, BTW). Similarly, on some machines you can disable precompensation in software (often by setting the start-precompensation cylinder to a higher value than the number of cylinders on the drive). So in those cases you can disable precompensation by a fairly simple, reversable, modification. Which just leaves machines where you can't. I suspect some of the HP controllers, like the one in the 9133, are going to be like this. Maybe you can get away with not doing anything. Maybe you have to add a little cirucit (a delay line, mux (to select the delay) and a state machine (to work out whether the bit has been made 'early' or 'late', and then tell the mux to give the opposite delay) between the write data output of the controller and the input of the emulator. I suspect that circuit could be pretty generic since precompensation should depend only on the actual bitpattern sent to the drive, and not on what user data that bitpattern encodes. So the precompensation (and thus the un-precompensator) should be the same for MFM, RLL, etc controllers. A few more random thoughts.... 1) It may help to have wider RAM and shift registers (say 2 16 bit banks, rather than 2 8 bit ones) to increase the time available for RAM accesses. It's not going to increase the hardware complexity very much. 2) Sine the RAM is addressed by a counter anyway (so the locations can be read/written sequentially over the ST506 interface), it would seem to be fairly simple to use that as part of a DMA controller to trnasfer data to the modern hard disk as fast as the latter can accept it. If you don't worry about compression of the data, that is. In which case, you need almost no processor power in the emulator (just enough to set up the DMA transfer, seleect the block on the modern drive, etc). I'll ahve to see how DMA works on IDE interfaces, though. 3) The index pulse could be obtained by decoding the RAM address counter outputs. However, this would mean that the index pulse would be missing during DMA -- that is, during 'seeks'. Does this matter? Does any controller actually need an index pulse when seek complete is deasserted? 4) With a few slight hardware changes (specifically related to the 'head' selection and index pulse), the emulator could be connected to the original ST506 _drive_ and make an image copy of it onto the modern disk. This would be useful for machines that can't do a low-level format (again, the HP9133 springs to mind) since such an image copy would copy the low-level format too. The modern hard disk could then be connected to a normal emulator and used to replace the ST506 drive in the classic computer. -tony