On Tue, 30 May 2000, Dwight Elvey wrote:
> 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
This is useful, however I think it is a totally different endeavor.
> 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
It was always my assumption (and I thought it was a fairly obvious one)
that the archives would be stored on either hard drives or CD ROM or
whatever modern day media makes sense. I would not store the archives on
floppies, although that is entirely up to whomever wants to create an
archive. Where the archive gets stored is not of concern to the standard.
The standard is simply there to provide a common, DOCUMENTED format by
which we store archived floppy diskettes.
> 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.
Which is why one would archive the diskette as a whole, as opposed to
getting into high levels and attempting to interpret the data on the
diskette. We don't want to do that. We just want to look at the disk as
a bunch of bytes and archive the whole thing.
> 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
Good point. I hadn't considered error checking. That can be added to the
header.
> 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
That would certainly be one way to do it, but I think it's more feasible
to attempt to do this by a combination of using the actual hardware and
the software that does the archiving. The usefulness of archiving old
diskettes is to make them available in perpetuity. Whether we are
archiving them so that we can always create a physical disk from the
archive to run on the original machine or use the archive as a "virtual
diskette" for an emulator, having an actual disk image archived on a long
term storage medium is my goal.
> 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.
And the standard we are trying to define would be able to accomodate such
a funky format!
Sellam International Man of Intrigue and Danger
-------------------------------------------------------------------------------
Looking for a six in a pile of nines...
Coming soon: VCF 4.0!
VCF East: Planning in Progress
See
http://www.vintage.org for details!
Received on Tue May 30 2000 - 23:07:14 BST