Apple IIc (not IIC+) details

From: Eric Smith <eric_at_brouhaha.com>
Date: Mon Aug 7 18:28:37 2000

> 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
> IIc use when communicating via its external drive connector?" Judging from
> what I got from the U of IOWA site, it has several supplies, four stepper
> driver phases, probably controlled by software, and a couple of control
> signals that are probably also controlled by software. If there were a
> reasonable way to seize control of the individual bits that control these
> babies, this thing becomes a potential powerhouse.

The //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 //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.
Received on Mon Aug 07 2000 - 18:28:37 BST