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_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 - 14:01:30 BST