30 May
2000
30 May
'00
7:42 a.m.
Clearly, I was insufficiently clear about what I meant. Bootability is not
an issue when exchange of media is the goal. I know there are systems that
boot from EITHER density and will do so from either single-side or
double-sided media, since I have a couple of them running. There are even
systems that will boot from single-sided or double-side, either FM or MFM,
and either 5-1/4" or 8" diskettes, e.g. my CCS system, though it was not
equipped with a booter that did that when I got it.
More importantly, however, I remember that in the CP/M days, but prior to
the TRS-80, CP/M software was distributed on "standard" 8" SSSD media with
no trace of the OS on them, and that arrangement worked perfectly well. The
problem of media exchange was not a problem until the 5-1/4" diskettes
became popular enough to exclude 8" drives and media from a large share of
the systems on the market.
What puzzled me was why, given that many systems were quite capable of
handling various media, they didn't write their code so it would load a
booter from the first sector, and make that booter deal with the low-level
details of the medium. My old SMS controller would read nearly any type of
sector it could write with a "read-sector" command. It didn't matter
whether it was 128-bytes or 2048, nor did it matter whether it was FM or
MFM.
Just as an aside, I recently encountered a datasheet for the WD 1773 FDC
(similar to 1770/72). Do you know of any systems in which it was used?
Dick
----- Original Message -----
From: Don Maslin <donm(a)cts.com>
To: <classiccmp(a)classiccmp.org>
Sent: Tuesday, May 30, 2000 1:01 PM
Subject: Re: Defining Disk Image Dump Standard
diskette
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
> 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!