30 May
2000
30 May
'00
7:01 a.m.
On Tue, 30 May 2000, Richard Erlacher wrote:
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.
But that is/was not always true! There were a number of 8" CP/M systems
that used bootable DD formats, and most all 5.25" CP/M systems were in a
bootable DSDD format.
8" SSDD:
Altos Avtek
Heurikon MLZ-90
Ithaca Intersystems
Octagon 8/16
Ohio Scientific Turbo
Tektronix 8
Vista A-800
8" DSDD:
Heath Magnolia
Heurikon MLZ-90
Ithaca Intersystems
MDS-80
Prolog APL-2
System Group 2800
W.J. Engineering
In the 5.25" bunch, the two obvious ones that immediately come to mind
as using the SD boot track are Osborne and Xerox.
- don
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(a)siconic.com>
To: <classiccmp(a)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!