I never understood why the double density CP/M diskettes were not bootable,
and why "distribution-standard" diskettes had to be bootable. These are two
different features, and what's important about the "standard" is not that
it's bootable but that it's defined so as to be universally readable.
The thing that made 5-1/4" "standard" diskettes unachievable back in the
CP/M days was that people couldn't let go of the notion that every diskette
had to be bootable. Frankly, I got fine mileage out of diskettes which
couldn't be booted, yet I never had a problem booting up.
It's silly to mix these two desirables. They're not bound together. Let's
not require something that's counterproductive as this is. If you make a
distribution standard for media, then use it for distribution. Let the OS
determine what's suitable for booting.
Dick
----- Original Message -----
From: Sellam Ismail <foo_at_siconic.com>
To: <classiccmp_at_classiccmp.org>
Sent: Tuesday, May 30, 2000 12:50 AM
Subject: Re: Defining Disk Image Dump Standard
>
> 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?
>
> I will be the first to say that this is may not be very logically
> structured. What I am attempting to do is give a suggestion for a high
> level header that identifies what each chunk of data in the archive can
> represent. In this way, disks that are formatted with several different
> formats can be described.
>
> I think what this may evolve into is a Data Definition Language. The DDL
> will be encoded along with the disk data and will describe the format of
> the data on the disk as it is being read.
>
> This comes back to the fact that utilities will have to be written for
> each computer we decide to support (I assume it will be all of them) to
> both read and write native diskettes. I also assume the data will be
> passed between the archive host and the target machine via serial link?
>
> In case my mostly random thoughts above don't make sense, here is what I
> would have in mind for the Apple ][:
>
> The disk can be read in either standard, logical format (13 or 16 sectors
> per track, 256 bytes per sector) or "raw" format (raw disk bytes are read
> from the track). There would also have to be format descriptions for
> specially formatted tracks such as the 18-sector type I mentioned.
>
> As for reading the raw bytes, the Apple ][ had what were called
> "synchronization" bytes, which were 10 bits long, the two extra bits being
> used to synchronize the head with the start of the track. I could go into
> a technical discussion of this but would have to pull out some reference
> material to refresh my memory of how it all worked. Anyway, these bytes
> would have to be specially encoded in the archive.
>
> 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 - 09:56:47 BST