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

[mjmahon@aol.com (Michael J. Mahon)]

In article <qhel5kauat.fsf@ruckus.brouhaha.com>, Eric Smith
<eric-no-spam-for-me@brouhaha.com> writes:

>"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).

Since it takes 32 microseconds (approximately 32 cycles) for a byte
to "go by" in the shift register, it is possible to use a loop like:

loop:
 LDA $C08C,X
 STA buf1,Y
 LDA $C08C,X
 STA buf2,Y
 LDA $C08C,X
 STA buf3,Y
 INY
 BNE loop

To capture intermediate states of the shift register.  I realize that the read
state machine does not shift at a constant rate (particularly after the high
bit becomes 1), but three samples may be enough to "put Humpty Dumpty
back together again."  This would permit software decoding of any pattern
which was composed only of bits written in 4 microsecond cells, so it ought
to work for FM and 3740 data.

Of course, it still requires three (simultaneous) track buffers, with the loop
above repeated about 25 times, to get all the data.

I think I'll give this a try to see if I can watch the data shifting through...
 ;-)

<snip>

>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.

I see your point, and I agree that it should work.  An interesting
"bit alignment" problem!  ;-)

>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.

Well put.

-michael

Check out amazing quality 8-bit Apple sound on my
Home page:  http://members.aol.com/MJMahon/