Re: NadaNet for the //c - just an idea

[mdj <mdj.mdj@gmail.com>]

On Aug 25, 9:23 am, "Michael J. Mahon" <mjma...@aol.com> wrote:
> Ferdinan Meyer-hermann wrote:
> >   To: comp.sys.apple2
> > It is just an idea that came to my mind:
> > The //c does not have Annunciator outputs, so it doesn't allow for the usual
> > way to connect the NadaNet interface. But I think it might be possible to
> > do this over the disk port.
> > One could use pin 11(Stepper phase 0) as the data line and pin 16 as an
> > enable, like this:
>
> > pin 6 (VCC)
> > --------------------------------+
> >                               C /
> > pin 11(PH0)    2.2K           |/
> > --------------/\/\/\------+---|
> >                           |   |\       +---> to PB1
> >                           |   E \      |
> >                        C /      |      |
> > pin 16(/EN)            |/       +-|>|--+---> to NadaNet
> > -----------/\/\/\------|               |
> >              10K       |\              \
> >                        E \             /
> >                           |            \
> >                           |            /
> > pins 1-4(GND)             |            |
> > --------------------------+------------+---> to NadaNet
>
> > Now, to send some data, you would need to Initialize:
>
> > STA $C0E0       Phase 0 off
> > STA $C0EB       Select drive 2
> > STA $C0E9       Drive on
>
> > And then, the normal NadaNet send routine can be used, with the Address of
> > the PH0 softswitch($C0E0/$C0E1) instead of the AN1 switch.
> > After transmitting, you should turn the drive off, but do not select drive1,
> > or you will make the drive motor spin up and down:
>
> > STA $C0E0       Phase 0 off (if not done by send routine)
> > STA $C0E8       Drive off, DOS/ProDOS will select correct drive afterwards
>
> Cool, Ferdinand!
>
> I think this could work, provided that a special driver for PB1 was
> added (according to IIc docs, you can't drive a IIc PB input with an
> emitter follower).  Of course, all the needed power is available at
> the disk connector.

Should work OK, with a couple of caveats:

//c's don't have pin 16 connected, since that's routed to the internal
drive. Instead you'd have to use pin 17 (which is /DR2). It's still
important to include the
emitter follower off PH0 using /DR2 in a sortof tri-state
configuration (as ferdinand points out) otherwise disk access to the
internal drive would send useless noise onto the 'net.

As for the input signal, it's probably considerably simpler to add
another emitter follower to buffer input from WRPROT than use the
PB's. Firstly, this would negate the need to tap two different
connectors, and avoids the 'complexity' of dealing with the PB inputs
on the IIc.

Speaking of which, those PB inputs are taps that intercept the anode-
cathode junction of a pair of opto-isolators. Because of this,
attempting to drive it with a gate (or emitter follower) will not have
the desired effect, since in the logic-low state the first LED can
sink through the emitter ground of the source gate. Instead, you need
to drive it via a PNP transistor so you get a reverse-bias effect
during a logic-low.

It's a terrible design, which can be excused only by its ingenuity;
obviously management specified the need to support the mouse well into
the //c's hardware development.

> And the send routine always turns off the output, PH0 in this case.
>
> There is one coding issue--today there is no common "exit" for
> NadaNet, so disabling would require some rework.  (This same
> issue would have to be addressed to deal with IIgs speed control.)

A small amount of rework - perhaps a self-modifying load routine that
rewrites the soft-switch reads to avoid altering the code timing ?

Matt