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

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

On Sep 14, 10:14 am, "Michael J. Mahon" <mjma...@aol.com> wrote:
> Michael J. Mahon wrote:
> > Ferdinan Meyer-hermann wrote:
> >>   To: Michael J. Mahon
> >> Michael J. Mahon wrote:
>
> >>> 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.
>
> >> One could also use the WRITE PROTECT signal for reading from the net to
> >> allow for a one-connector solution, as the signal can be easily driven by
> >> a '125, which then can also replace the output circuitry above (with the
> >> other three units of an AC125 wired in parallel, one would have 75mA
> >> guaranteed drive capability).
>
> >>      3x74AC125 in parallel
> >>         |\
> >> PH0-----| >---|>|-----+--------->NadaNet
> >>         |/o           |
> >>           |           |
> >> /EN-----+-+           |
> >>         |             |
> >>         o/|           |
> >> WPROT---< |-----------+
> >>          \|
> >>        74AC125
>
> >> The signal can be read in the high bit of $C0EE, if the controller is
> >> configured for checking write protection (STA $C0ED).
>
> > With some multiple of 0.5us latency in rise and fall times, no doubt...
> > I'd have to do some experiments with WRPROT to determine any limits
> > on timely sensing.
>
> > And the diode should just be an emitter follower to OR onto the net.
>
> >>> 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.)
>
> >> I wouldn't think that there are so many exits that you can't just add
> >> an STA $C0E8 to all of them (Although thats not a good style)
>
> > For the IIc, a single instruction in a few places wouldn't be a
> > deal-breaker, but for the IIgs, it's several instructions in a
> > few places.  That makes it appropriate to consolidate the exits.
>
> A brief status update...
>
> I've done some experiments with a IIc+ and have found out a couple
> of annoying things:
>
> 1. When de-selecting the network by turning the "motor" off, there
>     is a 1+ second delay before the /EN line is deasserted.  I can
>     disable instantly by switching to the other drive, but that will
>     cause its motor to twitch.

> 2. On a IIc+, pin 17 is not /EN2, it's /EN1 (since S6,D1 is not the
>     built-in drive).
>
> The accumulation of annoyances would make doing this more kludgey
> than I hoped, and the space required to adapt dynamically would be
> way out of line.

The only way around both of these issues is to use SmartPort style
logic - do an AND on PH1 and PH3 for enable, then transmit on PH0 or
PH2 (or vice versa). This would get you something that should work on
any disk port - even hanging off the back of a 5.25" on a IIe should
be fine.

You could probably use a 7408 to do all the logic...

> I've made some progress on creating common nodes for doing the net
> "setup" and "takedown" code.  It would be implicit for high-level
> NadaNet requests, but M/L programmers who wish to do lower-level
> operations would need to call "setup" and "takedown" explicitly
> to bracket network activity.

That seems a reasonable tradeoff to me ...

Matt