Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!linus!decvax!tektronix!ogcvax!omsvax!icalqa!hplabs!sri-unix!ciaraldi@Rochester.ARPA From: ciaraldi@Rochester.ARPA Newsgroups: net.micro.cpm Subject: Re: DSDD can it read SSSD disks Message-ID: <12747@sri-arpa.UUCP> Date: Mon, 17-Oct-83 22:57:41 EDT Article-I.D.: sri-arpa.12747 Posted: Mon Oct 17 22:57:41 1983 Date-Received: Sun, 23-Oct-83 13:32:47 EDT Lines: 81 From: Mike Ciaraldi 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