Defining Disk Image Dump Standard

From: Richard Erlacher <richard_at_idcomm.com>
Date: Tue May 30 10:17:33 2000

WARNING: There's evidence of "creeping featurism" here. That's what kills
most standards, or at least manages to make them useless.

Example: if your goal is to make the medium universally readable, why
bother to put a source identifier into it? Who cares what system wrote it,
so long as it can be read by any machine capable of dealing with the
physical medium. It seems MUCH more important to choose a medium that's
universally available and useable by a large number of systems.

This would rule out such things as tape, whether paper or mylar/magnetic,
diskettes, and most other magnetic media. The most important feature is
ready availablility, right? If you can't go down to the 7-11 and buy it,
it's not readily available, now, is it:?

If you're defining an exchange medium, it doesn't matter whether your 1970's
computer had that medium back when it was a pup. It doesn't matter that
they used the little dectapes then if you can't go to CompUSA and buy them
now and in the future.

If you consider genuine requirements, you'll probably not end up with
magnetic media, though portable hard disk might be worthy of consideration.
You'll probably end up with something that requires nearly everyone to build
an interface of some sort just to be able to use it. That's the problem
you're trying to solve, doncha know ... If the guys who designed the systems
had provided for this sort of interchange, you'd not have to solve the
problem now.

Dick.
----- Original Message -----
From: James Willing <jimw_at_agora.rdrop.com>
To: <classiccmp_at_classiccmp.org>
Sent: Tuesday, May 30, 2000 8:54 AM
Subject: Re: Defining Disk Image Dump Standard


> On Mon, 29 May 2000, Sellam Ismail wrote:
>
> > Let's start sort of from scratch here.
> >
> > So far we have the following (high level) criterion for a disk archive
> > standard:
> >
> > 1. Host computer type (2 bytes allowing up to 65536 models to be
> > specified)
> > 2. Track format (host computer specific)
> > 3. Sector format (single-density, double-density, etc)
> > 4. Sector data format - this will specify what format the archived
sector
> > is in (raw data? logical bytes?)
> > 5. Bytes per sector
> > 6. Bits per byte
> >
> > What else?
>
>
> Hmmm...
>
> Hard sector vs. SOft sector (for ctrlr emulations)
> Interleaving - yes/no/offset value
> Sectors per track
> # of Tracks
> Surfaces (heads) per cylinder
> ...?
>
> -jim
> ---
> jimw_at_computergarage.org || jimw_at_agora.rdrop.com
> The Computer Garage - http://www.computergarage.org
> Computer Garage Fax - (503) 646-0174
>
Received on Tue May 30 2000 - 10:17:33 BST

This archive was generated by hypermail 2.3.0 : Fri Oct 10 2014 - 23:33:10 BST