On Tue, 30 May 2000, Richard Erlacher wrote:
> 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?
No, sorry, not off the top of my head.
- don
> Dick
>
> ----- Original Message -----
> From: Don Maslin <donm_at_cts.com>
> To: <classiccmp_at_classiccmp.org>
> Sent: Tuesday, May 30, 2000 1:01 PM
> Subject: Re: Defining Disk Image Dump Standard
>
>
> >
> >
> > 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 - 15:29:21 BST