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

Forgive me as I'm half asleep today (the top half I think, unfortunately containing my brain...) A few points on this... a) I'm only personally interested in ST506 type drives as that's all I have; others will be worrying about other technologies. Is there a case where the data stream coming off the drive on a read (or going to the drive on a write) might be something other "r/w a single sector"? I'm just wondering about this sampling idea - it sounds plausible if the only commands available are to read or write a single sector (plus the usual seek etc.) but are other commands available where the data stream to/from the drive might be different if say, multiple sectors can be read/written in one command? At that point the sampling idea falls on its ass if bolting together several emulated sectors doesn't give the same data as it would for a real drive. b) In the case of ST506, I'm taking it that the controller always provides the clock signal for reads and writes - otherwise, presumably, there'd be no need for this oversampling of the raw bit stream idea. It could be just sampled at the speed of the drive. c) Something that works "with most ST506 drives" is, IMHO, not good enough. If a drive works with the ST506 controller with which it was formatted, it should work with the emulator. Finding that it doesn't work emulating XYZ's drive 6 months down the line because said drive is within spec but our emulator doesn't quite like the drive spec doesn't seem good enough. I don't know about other classic drive technologies (all my old systems are ST506 or SCSI), so somebody can argue that case seperately :-) d) Tony's point about being able to understand all of the system duly noted - only problem I see there there being the various combinations of hardware options that would likely be useful to people. People would find emulation of drives other than ST506 types useful I'm sure. Then on the 'modern' side of the interface, there are various options - IDE, SCSI, Ethernet, Token Ring and who knows what else. Ultimately at least, it seems like using off the shelf components and software to drive the modern side of things - and provide flexibility of operation - will outweigh the desire to know intimately the entire system. I hate board replacement too; I hate relying on somebody else's code - but in this case it does make sense to me. I'm not going to lose any sleep over scavenging a dead PC-class motherboard for useful parts when it fails and replacing it with another free, commodity unit. Said boards are going to be around for beer money for years to come - at which point keeping running the other parts of the systems we're trying to preserve may well become impossible anyway. Thoroughly document the interface hardware (and any software) though of course - if the classic hardware (and us) are all still around in 2020 then it would not be a hard exercise to make said interface work with whatever hardware is then considered modern. cheers Jules