Defining Disk Image Dump Standard

From: Dwight Elvey <elvey_at_hal.com>
Date: Tue May 30 18:48:22 2000

Hi
 It was not specifically mentioned but I also think
we should archive a method to boot strap the machine
from ground zero, were this can be done with things
like front panels or ROM monitors. I realize that this
may not always be provided by the original manufacture
but I am currently in the process of doing just that
to the second machine. This may even need the inclussion
of special hardware or blowing of custom ROM's but
it is also needed.
 As was stated by others, the
media for archiving needs to be in a currently common
format that is supported by todays machines. It has
also been generally recognized that it should be occasionally
brought up to date by moving to newer media. It is my
opinion that this should be done on an overlapping basis,
such as today, we might use both floppies and CD ROM's.
Multiple copies stored in multiple locations is also
needed as well as some form of scheduled refreshing,
with overlapping copies on the same media.
 I don't think that we should even try to save data in the
original format as long as there is a method such as I
mentions above to restore data to the original media.
Saving the data in DOS files is a proper method and
meets the needs of archiving. One also has to consider
that some software is composed of a number of elements.
As was mentioned, even in CPM, part of the OS might
be in a file. This means that the method of saving
must include the ability to link a number of pieces
that were not necessarily tied together as a single
data stream.
 Another thing that wasn't talked about was CRC's. Even
though most media has built in CRC's, there is no way
to detect a failure in the communications between the
new and old media. I suggest that this be at least a
two level CRC. The first level would be on small blocks
of data that the CRC could do error correction on with
a reasonable burst size compared to the block size.
The next level would have a larger CRC with a burst correction
size that would be greater than two times the lower
levels CRC. This last level of CRC would have several
copies of the CRC value scattered through the data stream.
As an example, CRC-32 can fix a burst of 12 bad bits.
I would limit the block size for this CRC to about
512 bytes. A larger CRC would be needed for the top
level CRC.
 I also doubt, that most people realize that there are
other types of data encoding than MFM and FM. Intels
M2FM comes to mind, as well as the Apple format. It was
stated that people felt that it would not be practical
to make a piece of hardware that could read any arbitrary
format. I contend that as long as that format could
have been read or written through that drive that a
simple DSP chip could be used to make a universal controller
chip. Vary little hardware, other than a simple development
board, would be needed. I find it hard to believe that
one couldn't cover 99% of what is out there. At least,
as long as we where talking about floppies or some of
the raw media hard drives.
 To show the variety of things, the machine I'm working on
has two sectors per track of 20480 bits. This is on
32 hard sectored media. It is regular FM, though.
Just my thoughts
Dwight
Received on Tue May 30 2000 - 18:48:22 BST