Re: GCR <--CP/M --> MS-DOS and vice versa?

[Eric Smith <eric-no-spam-for-me@brouhaha.com>]

"Michael Evenson" <mevenson@nospam.adelphia.net> writes:
> I think the point that is being missed here is this: The Apple II disk
> controller was really nothing more than a card to allow the software in the
> Apple II to turn the motor on/off, move the heads in/out and cause the
> read/write coils in the head to generate a magnetic field or detect a change
> in magnetic field. All of this work was done by turning bits on/off in the
> controllers address space and accessing routines in the cards's firmware.
> The software in the Apple II was in total control.

Not *quite* total control.  The Disk II controller requires that each
data pattern (nibble value) that can be read by the CPU have a leading
one bit.  This requirement is the fundamental reason why the 9-bit or
10-bit self-sync patterns are used, and why the Disk II controller can't
read industry-standard FM (single density) disk format (IBM 3740 format).

The Disk II controller is capable of dealing with FM encoding; that's
the "4+4" scheme used to encode the volume, track, and sector in the
address field of a sector.  But it can't sync to the IBM 3740-format
sync patterns.  It might be possible to write IBM 3740 format, but the
Apple wouldn't even be able to verify the data it had just written.
And in 3740 format a track is supposed to start after the index hole,
but the Disk II doesn't even have an index sensor, so there's no way
for the software to know where to start the track.

Actually, I have an idea for a way that it might just barely be possible
to read 3740 format data, though it would typically take multiple disk
revolutions to read a sector because it would have to count on random
chance for synchronization.

But there's *NO* way that the Disk II controller (or its variants) is
going to read and write MFM at 250 Kbps.  It was a clever design, but
that wasn't one of its objectives.