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

From: Jules Richardson <julesrichardsonuk_at_yahoo.co.uk>
Date: Sun Dec 7 08:20:27 2003

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
Received on Sun Dec 07 2003 - 08:20:27 GMT