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

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

On Sep 14, 6:12 pm, "Michael J. Mahon" <mjma...@aol.com> wrote:
> mdj wrote:
> > 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...
>
> This sounds like a reasonable way to go.
>
> I have no experience with Smartport signaling, so which combinations
> of phase lines can I twiddle without fear of interference with (or from)
> Smartport protocols?

Host communication with a Smartport device is negotiated by activating
PH1 and PH3. Since these are opposing phases, this doesn't occur
during disk access so the combination is unique to Smartport.

A SmartPort host->device transmission then happens by activating PH0,
and the devices ACK on WRPROT, so if you used PH2 for sending, any
device on the bus would be sitting "at the ready" but not do anything.

The PH0+PH2 combination is used to initiate a SmartPort bus reset. I'd
avoid that one.

Matt