Date : Mon, 17 Oct 1983 22:57:41 EDT (Mon)
From : Mike Ciaraldi <ciaraldi@Rochester.ARPA>
Subject: Re: DSDD can it read SSSD disks
The question can be divided into several sub-questions,
with different answers:
1) The drives themselves--I have never encountered a
drive which works for DSDD than would not also work on SSSD.
The problem we used to have, before DD became so widespread,
is that some drives could not handle the DD,
but that was several years ago.
2) The controller. The way data is stored on the
disk, i.e. the pattern of data and clock pulses going
to the read/write head and ultimately onto the media,
is controlled by the circuitry of the controller and
the controller chip. The most common chips, e.g. Western
Digital 179x series, can handle both, and
most modern controllers handle both, under software
control. In short, older controllers could often
handle only SD, almost all modern contollers can
handle both DD and SD.
Concerning SS vs. DS., this is again a chip/board
question, and the controllers that have DS should be
able to run SS with no problem.
Aside--J. Pournelle's column in the new Byte asks
if you can use SS 8-inch drives on a Zenith Z-100.
I have certainly used SSSD diskettes on
such a system, but the drives themselves were DS.
3) Software. The IBM PC always uses DD, whether SS or DS.
In gneral, drivers can be written to handle both,
and, in fact, the newest versions of CP/M have explicit
places in the Disk Parameter Header and Disk
Parameter Block for recording number of tracks/sector,
etc. These data tables are within the operating system,
but the actual driver could ignore them, I suppose.
The most common way to hnadle the differing
densities and other formats is something
like this: the driver itself can handle several
types of disk formats, and uses the info in the DPH and DPB
to decide things like how many bytes to transfer
in each read or write operation.
How do the data tables get set up?
An older way was to make it an explicit command.
e.g. a keyboard command that made drive B: DSDD.
Woe unto you if you stuck a SS or SD disk in that
drive! Another way was to give alternate names to the
drives, e.g. A: and B: would be physical drives 1 and 2;
(assumed SSSD) referring to C: and D: gave you
the same physical drives, but formatted DSDD. Again,
if you stuck the wrong disk in you would be in trouble.
More modern software switches automatically
whenever you log in a diskette.
It works like this: the driver reads the first
track and sector of the new disk. (and possibly
other sectors, too). If it cannot read them SD, it
tries DD. If it cannot read the second side, it must
be SS, etc.
A more common way is to encode the format info
in the first sector of the first track, e.g. by
storing the data from the DPB and DPH, or
by just storing a code number. The problem there
is that different manufacturers' formats and
code numvbers are not the same.
Since the first sector usually contains the
boot loader, this format code starts several bytes in,
leaving room for a jump instruction.
Other wrinkles: for compatibility with older formats
which do not have encoding, e.g. CP/M standard
8-inch SSSD (same as IBM 3740), there has to be some
default. Also, on an 8-inch diskette, the
index hole is in a different place depending on
whether the diskette itself is SS or DS.
This is a little long-winded, I'm afraid, but I hope
it answers your questions. I just got done writing
drivers for the Z-100, that's why I know some of the
tricks they use. If anyone else has
more info, I'm sure the net would like
to hear about it.
Mike Ciaraldi
ciaraldi@rochester