7 Aug
2000
7 Aug
'00
11:28 a.m.
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.