7 Aug
2000
7 Aug
'00
3:48 p.m.
Please see embedded comments below.
Dick
----- Original Message -----
From: Eric Smith <eric(a)brouhaha.com
To: <classiccmp(a)classiccmp.org
Sent: Monday, August 07, 2000 5:28 PM
Subject: Re: Apple IIc (not IIC+) details
the
<snip the same
What? How does it generate FM? Is there a straightforward way to create FM
with the standard controller? FM is VERY easy to deal with, while GCR
requires one switch data rates, etc, all of which can be done, but it's an
unnecessary pain. How does it generate FM? is that a function it does
automatically or does it bit-bang it into a buffer and then ship it out ...
or what??? I was NOT aware the Apple-][ controller could put out FM. That
would have made it able to read/write TRS-80 diskettes, wouldn't it? Well .
. . maybe . . .
> My question would be whether the IIc (not the
IIc+) can talk to an
external
> device by way of the channel used to talk to its
external drive(s) in
the
same way a
IIc+ does it.
[...]
> One question, then, begging definitive answer is, "What protocol does
babies, this
thing becomes a potential powerhouse.
The file://c disk controller is for all reasonable intents and purposes as the Disk ][ controller used in the Apple ][ and
][+, simply with a
different connector pinout (D-subminature 19 pin instead of a 2x10
header).
It's reduced from seven chips to one, but
functions the same.
If you can build some external device that you can control with an
Apple ][+
and the Disk ][ controller, you'll be able to use
it with the file://c.
The Disk ][ controller schematics are in the DOS 3.2 and DOS 3.3 manuals.
> That's particularly true
> if there's some protocol in place that sends unmodulated data to the
outside
> world, say, in some
external-intelligence-dependent format that could be
> deciphered without having to unmodulate the Apple-style GCR code
normally
> found on their controllers. It seems as though
there are enough signals
to
> do the job if one could just get control of them.
That requires
information
> not commonly published on the web. If
there's an easy way to get that
info,
I'd like
to do that.
If you want to use the actual read data and write data signals, the data
*must* be in GCR (or FM) form.
That's all the
disk
controller is capable
of dealing with. Your external device may decode the
GCR on a write and
convert it to something else; that's what the UniDisk 3.5 and the HD20
do. (Note that the UniDisk ends up re-encoding data in GCR, but at a
higher bit rate.)
If you can talk to your device using only the signals other than the
actual read and write data (e.g., the stepper phase signals and the
write protect input), you don't need to mess with GCR.
I was afraid of that . . . it means I can't get away with anything simple .
. . of course I'm grateful you've cleared that up. It seems as though every
mention of the IIc in this context talked around this question rather than
dealing with it head-on as you 've done. Thanks.
The stepper phase signals are of interest because they can sink some
current, and particularly because the floppy port has the supplies on it as
well. Naturally the drive select (out) and write protect (in) signals ( I
haven't looked at this stuff in over a week, so I may have the signal count
wrong, but I think there were two out and two in, aside from data) and you
say this works precisely the same way the ][+ controller works? Since they
can run the same software the locations and bit definitions must be the
same. I'll have to contemplate that for a while. I seriously doubt the
current venture will require I use the data stream, but it would be
interesting to know how to use it.
Now, is the rest of the memory map pretty much the same as on the ][+, that
is, can one rely on finding the small 256-byte blocks associated with each
"slot"? That's way more than I'd need for a channel.