TIP: Click on subject to list as thread! ANSI
echo: apple
to: comp.sys.apple2
from: mdj
date: 2008-08-24 22:22:24
subject: Re: NadaNet for the //c - just an idea

On Aug 25, 9:23=A0am, "Michael J. Mahon"  wrote:
> Ferdinan Meyer-hermann wrote:
> > =A0 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)
> > --------------------------------+
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 C /
> > pin 11(PH0) =A0 =A02.2K =A0 =A0 =A0 =A0 =A0 |/
> > --------------/\/\/\------+---|
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 |\ =A0 =A0 =
=A0 +---> to PB1
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 E \ =A0 =A0 =
=A0|
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0C / =A0 =A0 =A0| =A0 =A0=
 =A0|
> > pin 16(/EN) =A0 =A0 =A0 =A0 =A0 =A0|/ =A0 =A0 =A0
+-|>|--+---> to NadaN=
et
> > -----------/\/\/\------| =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
> > =A0 =A0 =A0 =A0 =A0 =A0 =A010K =A0 =A0 =A0 |\ =A0 =A0 =A0 =A0 =A0 =A0 =
=A0\
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0E \ =A0 =A0 =A0 =A0 =A0 =
=A0 /
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =
=A0 =A0\
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =
=A0 =A0/
> > pins 1-4(GND) =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0|
> > --------------------------+------------+---> to NadaNet
>
> > Now, to send some data, you would need to Initialize:
>
> > STA $C0E0 =A0 =A0 =A0 Phase 0 off
> > STA $C0EB =A0 =A0 =A0 Select drive 2
> > STA $C0E9 =A0 =A0 =A0 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 dr=
ive1,
> > or you will make the drive motor spin up and down:
>
> > STA $C0E0 =A0 =A0 =A0 Phase 0 off (if not done by send routine)
> > STA $C0E8 =A0 =A0 =A0 Drive off, DOS/ProDOS will select correct drive a=
fterwards
>
> 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). =A0Of 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. =A0(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
--- SBBSecho 2.12-Win32
* Origin: Derby City Gateway (1:2320/100.2008)
SEEN-BY: 10/1 3 34/999 106/1 120/228 123/500 140/1 222/2 226/0 236/150 249/303
SEEN-BY: 250/306 261/20 38 100 1404 1406 1410 1418 266/1413 280/1027 320/119
SEEN-BY: 393/11 396/45 633/260 267 712/848 800/432 801/161 189 2222/700
SEEN-BY: 2320/100 105 200 2905/0
@PATH: 2320/100 261/38 633/260 267

SOURCE: echomail via fidonet.ozzmosis.com

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.