binder@dosadi.DEC (Wherever you go, there you are.) (04/08/85)
You can't read an Apple disk with any system whose controller was not
explicitly designed to read the Apple format. That includes Apple, various
third parties, and one IBM plug-in that emulates the Apple. The only way to
get data to or from an Apple is via serial communication lines and either a
terminal emulator like ASCII Express or Softerm, or a file transfer utility
like Kermit.
For anyone interested in the technicalities of the Apple recording scheme and
why it is so different, here's a brief explanation of it.
1. Apple uses soft sectoring, and even soft indexing - ALL format information
is written on the disk at INIT time. Any 5-1/4 floppy, hard-sectored, or
soft-sectored, or even without an index hole, works just fine.
2. Where all other controllers today use Modified Frequency Modulation (MFM)
recording, Apple's recording scheme is group-coded recording (GCR).
The sector headers are written in a 4+4 scheme, in which each two bytes of
header contain one usable byte of information. The data byte is broken
into two nibbles, and each nibble is translated into a byte in which the
two most significant bits are both ones. These translated bytes are then
written to the disk. The start of a header or data field is marked by a
specific pattern of bytes that include GCR violations such as a byte value
of AA hex.
DOS 3.3, 16 sectors:
Data fields are written in a 6+2 scheme, in which every disk byte contains
six meaningful bits - four disk bytes have three useful bytes of data.
Each set of 24 bits (3 bytes) is broken into four 6-bit groups, which
are translated into bytes in which one or the other of the upper two bits
may be a zero, but not both, and certain patterns, like the AA, are still
reserved. 342 disk bytes are required to record 256 data bytes.
DOS 3.2, 13 sectors:
Data fields are written in the same 4+4 scheme as headers. 512 disk bytes
are required to record 256 bytes of data.
3. In MFM, synchronisation is done by detecting MFM violations coupled with a
specific bit pattern. In the Apple, synchronisation is done by the use of
special 10-bit patterns called self-synch bytes, in which the two end bits
are zeroes, and the centre eight bits are ones. A preamble consists of
five self-synch bytes in a row, and the controller's state machine uses
them so that a start anywhere in the first 40 bits of the 50-bit field
will result in synchronisation before its end.
Cheers,
Dick Binder (The Stainless Steel Rat)
UUCP: { decvax, allegra, ucbvax... }!decwrl!dec-rhea!dec-dosadi!binder
ARPA: binder%dosadi.DEC@decwrl.ARPA
Mon 8-Apr-1985 10:51 Eastern Standard Timealford@ecsvax.UUCP (Ross Alford) (04/09/85)
In article <1535@decwrl.UUCP> binder@dosadi.DEC writes: >You can't read an Apple disk with any system whose controller was not >explicitly designed to read the Apple format. That includes Apple, various >third parties, and one IBM plug-in that emulates the Apple... Something I've been wondering about for a while-- I've seen a number of claims that one of the advantages of the odd disk controller scheme that Apple uses is that since it is essentially controlled entirely by software, it is more versatile than hardware controllers. If that's really so, why hasn't some clever hardware/software person figured out how to program the *Apple* to read others' disk formats? I've seen numbers of inquiries about reading Apple disks on other machines, but none on reading/writing other formats on Apples. I realize that the 35 track disks that are Apple standard might present a problem, but for simple information transfer, who cares if 5 tracks are unusable? (unless, of course, they happen to be the directory tracks) I for one would love to get a program that would run on an Apple and read/write disks in whatever MFM 5.25" format (perhaps Osborne SSSD, MSDOS 1.0, etc) was possible. Ross Alford ...{decvax, akgua, ihnp4}!mcnc!ecsvax!alford
john@hp-pcd.UUCP (john) (04/09/85)
<<< Normal MFM recording places a flux transition at 4,6 or 8 us spacing depending on the data byte. Much of the expense in a MFM system is in the Data sperator that has to decide whether a pulse that comes in at 5 us was really a 4 or a 6 us pulse. GCR recording eliminates the patterns that are difficult to decode so that a GCR decoder is simpler and doesn't need VCO's or Phase locked loops to do it right. GCR recording trades off hardware cost for disc capacity. You can use less expensive hardware but you only get 6 data bits in every disc byte. MFM gives you 8 data bits for every disc byte. If you store a lot of data then MFM is better. If not then GCR is better. GCR is also appealing to the home market where a lower initial cost is important. Today there are single chip MFM controllers that contain everthing needed to control a disc drive (including Phase locked loop) so the hardware cost difference is dropping. John Eaton !hplabs!hp-pcd!john
rick@cadtec.UUCP (Rick Auricchio) (04/10/85)
lds ~110Kb by using the 5/8 GCR encoding.
Sixteen-sector format, however, "stretched" the rules a bit. It allows a flux
change every 4, 8, or 12uSec. Though the laws of FM say you must not do that,
Woz did (and modified the state machine a bit). Now we get more GCR codewords
allowable (~64). [All the valid 10/13 sector ones plus new ones with two
consecutive zero bits]. Using a 6/8 GCR gives ~140Kb capacity.
Only about 10 engineers at Apple know/knew the real details of the disk
and how to write "core" routines to read/write/format etc. At least three of
us are no longer there, having been gone since the days of the Apple ///.
Matter of fact, I wrote the floppy driver/formatter for the ///. The disk ///
is *identical* to the disk ][, except for the disk-switch sensing which occurs
when the wrote-protect switch toggles (try removing a disk on either drive;
hear the wp switch click). Extra chips on the disk analog card latch-up the
read-data line (software detects the lockup) and free it on a seek. It is
possible, though I've forgotten how, to take a disk /// and hotwire it to run
on the ][/ or //e.
==============================================================================
Opinions expressed have been generated solely by line-noise.
{cbosgd,decwrl,hplabs,ihnp4,seismo}!nsc!cadtec!rick N1150G (408) 942-1535
"The sooner you fall behind, the more time you'll have to catch up!"barry@ames.UUCP (Kenn Barry) (04/10/85)
> DOS 3.2, 13 sectors: > > Data fields are written in the same 4+4 scheme as headers. 512 disk bytes > are required to record 256 bytes of data. Actually, the old 13-sector disks use a 5+3 scheme. Does anyone still *use* the 13-sector format? If not, never mind.
rick@cadtec.UUCP (Rick Auricchio) (04/11/85)
rms race" is keeping the pirate
confused. Thirteen sector helps in that regard. It's also a bit more
reliable because it doesn't have the 12uSec transitions, but I don't know if
copy-protection is "easier" or "better" when using 13-sector.
No flames about piracy, please.
==============================================================================
Opinions expressed have been generated solely by line-noise.
{cbosgd,decwrl,hplabs,ihnp4,seismo}!nsc!cadtec!rick N1150G (408) 942-1535
"The sooner you fall behind, the more time you'll have to catch up!"