Apple IIc (not IIC+) details

From: Richard Erlacher <richard_at_idcomm.com>
Date: Mon Aug 7 22:48:54 2000

Please see embedded comments below.

Dick

----- Original Message -----
From: Eric Smith <eric_at_brouhaha.com>
To: <classiccmp_at_classiccmp.org>
Sent: Monday, August 07, 2000 5:28 PM
Subject: Re: Apple IIc (not IIC+) details


> > 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
the
<snip>
> > babies, this thing becomes a potential powerhouse.
>
> The file://c disk controller is for all reasonable intents and purposes
the same
> 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.
>
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 . . .
>
> 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.
>
Received on Mon Aug 07 2000 - 22:48:54 BST