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

["Bryan Parkoff" <BParkoff@satx.rr.com>]

    I am working on the parallel port that it connects to floppy drive.  I
write Parallel Port Device Driver that allows to be manipulated by SOFTWARE
that will be able to read/write both GCR and MFM encoding without a need of
hardware controller card.  It can be very tough while it is easy to
understand GCR structure that is written binary WHILE I have to learn to
read MFM structure without using MFM hardware controller card.
    It is only a project, but it is not available for public.  Please feel
free to provide some ideas.  Also, I am considering to develop USB port that
will require to have hardware circuit.

--
Yours Truly,

Bryan Parkoff
BParkoff@satx.rr.com
"Matthew Montchalin" <mmontcha@OregonVOS.net> wrote in message
Pine.LNX.4.44.0303061709040.1899-100000@lab.oregonvos.net">news:Pine.LNX.4.44.0303061709040.1899-100000@lab.oregonvos.net...
> On 6 Mar 2003, Eric Smith wrote:
> |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.
>
> Ah, so that's how Apple does it!  It doesn't use sync marks like
> the Commodore 1541?
>
> |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).
>
> Getting rid of that pesky '1' bit after every nybble, must be the
> secret to getting the right bytes written on the medium, 8 at a
> time?  But no doubt it is more complicated than that.  Can you
> suggest a place to read up on the Disk II controller?  What third
> party solutions have been offered to the Apple II world, in years
> past?  I mean, even at software incompatibility, there must have
> been a handful of developers that desired to implement their own
> custom formats to restrict software to in-house use only, with
> custom in-house hardware?
>
> |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.
>
> hmmm
>
> |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.
>
> Can you suggest a good website that will describe the low level
> format of a disk using Disk II?
>