[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Apple II <-> Commodore 64/128 disks?



William McBrine <wmcbrine@clark.net> wrote:

> The Apple II FAQ states that Apple disks are incompatible with IBM PC
> drives, and vice versa, because Apple drives use GCR encoding, where PC
> drives use MFM. This got my attention, because the Commodore 64's 1541
> drive also uses GCR -- and the 128's 1571 drive is a dual mode drive, so
> it can exchange data with PC drives. (The MFM mode was originally meant
> for use with CP/M, but can work with MSDOS disks, too.)
> 
> Is there any software for the Apple II OR C64/C128 to enable one system to
> read and/or write the others' disks?

GCR is a general technique, not a specific encoding method (unlike MFM,
which defines the bit-level and sector-level encoding).

The key point with GCR is that a table lookup is used to map between
data bytes and valid "disk bytes", in conjunction with some method of
splitting up the data bytes.

For example, on 5.25" disks, Apple has used three different techniques,
all which can be called "GCR".

The addressing information is encoded using "4-and-4" (two disk bytes
per data byte), since this is easy to decode quickly (shift and AND).
This is effectively how "FM" encoding works - a clock bit is written
before each data bit, so half the bits on the disk are available for
data (ignoring sector overheads).

DOS 3.2.1 and earlier (13-sector) used "5-and-3", where each data byte
was split into 5-bit and 3-bit fields, and there are 32 possible disk
byte values.  Eight disk bytes are written for every five data bytes.
This allows the disk to hold 25% more data than 4-and-4.

DOS 3.3, Apple II Pascal, ProDOS and CP/M (also Apple III SOS, and
Macintosh/Apple II 400K/800K 3.5" disks) use "6-and-2" encoding, where
each data byte is split into 6-bit and 2-bit fields, 64 disk byte values
are available, and four disk bytes are written for every three data
bytes.  This allows the disk to hold 20% more data than 5-and-3, or 50%
more than 4-and-4.

On top of this is the specification of what mapping is required between
disk and data bytes, where the leftover bits are stored, and the general
track organisation into sectors.

There is also the issue of the design of the disk controllers.  One
feature of the Apple II disk controller is that every disk byte must
have bit 7 set, which may not be true for other computers.


In summary: provided the C64 and Apple II use fundamentally compatible
disk drives and recording speed (the Apple II is single density, 35
tracks, single sided, 4 microseconds per bit cell) and there are no
encoding methods used on either machine which are unreadable by the
other machine's controller (e.g. the Commodore also requires bit 7 set
in each disk byte), then it should be possible to read the disks in
software.

I'm not aware of any software that does this.

-- 
David Empson
dempson@actrix.gen.nz
Snail mail: P.O. Box 27-103, Wellington, New Zealand