Apple IIc (not IIC+) details

From: Richard Erlacher <richard_at_idcomm.com>
Date: Mon Aug 7 16:58:07 2000

Please see embedded remarks below.

Dick

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


> > While there seems to be a fair amount of information about the older
apples,
<snip>
> > connector, though perhaps not using the same protocol.
>
> AFAIK, the IIc+ has the internal equivalent of a UniDisk 3.5, which was a
> "normal" Apple 800K mechanism with a microprocessor-based daughterboard
> added. It communicates with the IIc through a packet protocol, which is
> called SmartPort. However, the actual disk controller hardware of the
IIc+
> is just the IWM chip, which is a slightly fancier single-chip version of
> Woz's original disk controller.
>
This is exactly what I meant in my original remark. There's information
everywhere about what the IIc doesn't have. This reference to the external
FDC connector is essentially the same as what's on the Iowa U. site, in that
it refers to the IIc+, and the IIe, but says little about the IIc. I'm not
interested in the IIc+ (note the PLUS), but rather in what's in the normal
IIc (no PLUS!). The IIc+ is apparently an entirely different machine,
having twice the processor speed, twice the memory, additional features,
etc.

I have a IIc which was given to me as a token payment for something
potentially useful (which the IIc apparently wasn't) and recently took on a
challenge to get useful work out of a post ][+ Apple product. This arose
out of my argument that one can get useful work out of the $5 computers
available at the thrift stores, etc.

Now, I've little cause to believe that useful work from an apple product is
achievable, since useful work is limited for purposes of this challenge to
things that happen as a direct result of the actions inside and propagating
thence outward from the Apple box not to be accomplished by some other
device. If it will turn on/turn off a relay, that's potentially useful, so
it qualifies. It has to do this under program control, however, so knowing
it's possible to do that isn't enough.
>
> The only "intelligent hard drive" that Apple made for hooking up to floppy
...
<snip>
...
> of anyone doing it.
>
Yes, I've got one of the HD20's lying about somewhere, though I've taken the
drive out of the box, since the box is useful for packaging. The drive may
be of some use in a CP/M context some day.
>
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. This would presuppose that the data is not
manipulated in to its encoded format until it's at the peripheral, since
there are plural peripheral devices, not all the same. I've seen
discussions asserting that's the case, and others asserting not, so I'm no
better informed than previously.

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. 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.
>
> > There's also little definitive information about the memory usage for
I/O
> > and how (and how closely) they emulated the ][+ slot usage. They've
> > apparently memory mapped the keyboard, so I would also like to know
where in
> > the memory map the keyboard lives.
>
> AFAIK, the keyboard is encoded at $C000 and $C010, just like any other
> Apple II. The shift and option keys might be wired to the extra button
> inputs, just like the old "shift key mod" people did on earlier Apples.
>
> > I'm considering cutting a hole in the side of the box to accomodate some
> > sort of I/O channel. I understand that there was an expander available
from
> > a third party, but have little information about that. The slot I'd
make in
> > the box would accomodate a 40-pin, or perhaps 50-pin inline cable
connector.
> > Since I'd prefer to make an internally buffered I/O channel as opposed,
> > simply, to bringing out the CPU's signals, it would be useful to have
some
> > information.
> >
> > Any suggestions?
>
> Well, my main suggestion would be that if you're trying to accomplish
> something *practical*, you should just use a late-model laptop computer.
> But if you're just doing this for fun, more power to you!
>
Well, the fact is that "late-model" laptops don't have much power available,
while the IIc, with it's "brick" connecting to the mains, does have that
potential. That way you don't have to have yet another power supply to
accomplish the "useful work" that's being so evasive here.

Yes, I've used the EPP built into most notebooks to generate control
signals, but there's no power tap on the typical notebook. What's more,
this one (the one I'm using now) only runs for about 40 minutes on batteries
if the NIC and modem are plugged in. (the PC-cards are power-hungry!) That
in itself rules out trying to extract work by means of the PC-card slots,
though I've considered it.

As I often do, I've allowed my alligator mouth to overload my hummingbird
other end so I can't easily produce what I said I would. Now, given that
there's power on the floppy port, I'd only need one bit of control, but I'd
rather have the whole thing at my disposal, given it's not being used for
anything helpful.

Is the necessary information around somewhere that you know of? Is is
sufficiently complete and detailed that I can rely on it to drive those
stepper phases and unscramble the data that may have to be led to believe
it's on its way to a drive? Is there an alternate path to the data lines
to/from the external drive so it can be induced to contain unencoded data?
If the info is available, it's not inconceivable that one could packetize
communication with the outside world via an encoded disk interface. It's
just a lot of work and if it leads nowhere, it's not worth the effort. If
the data's all there, however, it would make a highly interesting project.
Received on Mon Aug 07 2000 - 16:58:07 BST