Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!lll-lcc!mordor!styx!ames!ucbcad!ucbvax!fizbin.DEC.COM!binder From: binder@fizbin.DEC.COM (Sold - but we have others) Newsgroups: comp.sys.apple Subject: IBM/Apple disk interchange? Message-ID: <8701062155.AA02531@decwrl.dec.com> Date: Tue, 6-Jan-87 19:24:00 EST Article-I.D.: decwrl.8701062155.AA02531 Posted: Tue Jan 6 19:24:00 1987 Date-Received: Wed, 7-Jan-87 05:49:52 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 79 We've had several people saying different things about whether IBM hardware can read/write Apple disks or Apple hardware read/write IBM disks. From the viewpoint of a hardware engineer who spent 15 years with disks and disk controllers, I'd like to put in my two cents' worth. Some of this stuff is fairly heavy hardware terms! Some or all of it may be hot air, if you've seen something better. If anyone out there has hard information to contradict this, I'll be as happy as the next person to see it, but please don't shower either me or the net with suppositions or rumors. The IBM 5-1/4" disk subsystem has at its heart the 765 disk controller chip. This chip is able to read or write only two disk recording schemes: 1. FM (double frequency, also called single density), in which each bit is defined by a clock pulse at its beginning and by the next bit's clock pulse at its end. Each ONE bit has a pulse between the two clocks. Within the limits of disk speed tolerances, this recording scheme is self-clocking, in that every bit has its own clock pulse recorded on the disk. IBM systems use FM for the first track of their double-density disks so that the system will be able to read the first track without knowing the density at which the remainder of the disk is recorded. 2. MFM (Miller Code, also called double density), in which each ONE bit is defined by a pulse, and there is a pulse between every two adjacent ZEROs to enable the phase-locked-loop data recovery system to keep tracking. (This scheme is therefore not self-clocking.) MFM is used because it allows twice as much data to be recorded on a disk by eliminating half of the magnetic pulses. The 765 disk chip can be programmed for a very limited set of data formats, primarily the two used by IBM plus minor variations on those themes. It cannot be programmed to read the two GCR (Group Coded Recording) schemes used by the Apple 5-1/4" disk system. The Apple 5-1/4" disk subsystem uses a state machine, implemented either with a ROM and several MSI chips or as part of the Integrated Woz Machine(IWM) superchip. This state machine reads and writes Woz's own perverted form of GCR. GCR encodes X bits of information in X+Y data bits, in which there are certain patterns that are defined as being illegal and other patterns that are reserved for special meanings. Woz-style GCR, used by DOS 3.3 and ProDOS, uses a 4+4 GCR for the header (four useful bits plus four more bits in each byte recorded on the disk) and a 6+2 code for the data sector - to record 256 data bytes, there are 342 actual bytes on the disk. (The older DOS 3.2 GCR was a 5+3 scheme.) Among the "illegal" patterns is the all ONEs pattern, or FF (hex). The actual pattern to be recorded on the disk is constructed by 6502 software in a RAM buffer by translating the desired data against a table before the state machine is triggered. When reading, the 342-byte pattern is translated in RAM back to the desired data pattern. Among the oddities of this state machine is the way it writes and reads sector preambles, which consist of five self- synchronization bytes (10 ONEs in a row instead of 8). When reading, the state machine can find this 40-ONEs-in-a-row pattern, and it is so designed that it will shift its expected byte boundaries to be in proper synchronism at the end of the pattern even if it started reading somewhere other than at the beginning. The state machine would interpret the IBM all-zeroes preamble as an all-ONEs synchronization field and begin looking for a sector header, which also contains a series of reserved GCR patterns. If this series of patterns isn't found, the state machine restarts. It cannot be made to read FM or MFM. Now then, there are some tools out there that claim to be able to read anything. The ones I have seen are combinations of software and hardware - the hardware is implemented in a nonstandard way, and it is designed to gobble everything off the disk without regard to what it is. Then the software goes in and tries to decode it, much the same as do the common tools for copying protected disks. A tool like this can read either Apple or IBM, or virtually anything else for that matter. But it can't usually write all those different formats. Okay, troops, if I'm wrong, let me know. If I'm right, this should put an end to the question. Cheers, Dick Binder (The Stainless Steel Rat) DEC Enet: ASD::BINDER UUCP: { decvax, allegra, ucbvax... }!decwrl!asd.dec.com!binder ARPA: binder%asd.DEC@decwrl.ARPA