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

["Michael J. Mahon" <mjmahon@aol.com>]

On Sep 15, 8:00 am, mdj <mdj....@gmail.com> wrote:
> On Sep 15, 4:30 pm, "Michael J. Mahon" <mjma...@aol.com> wrote:
>
>
>
>
>
> > mdj wrote:
> > > 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, where are the SmartPort signalling protocols documented?
>
> > I'd like to be sure that we are staying out of each other's "coding
> > space".
>
> I think you're pretty safe... That said, the acid test is having a
> UniDisk 3.5" on the bus to validate it.
>
> Unfortunately the documentation on the protocol is sparse. The IIgs
> documentation David mentioned shows the 'negotiation' used, which I
> covered previously. It's in essence just like a serial port. PH1+3 is
> used so that Smartport devices can detect an 'enable'. PH0 is request
> to send, and WRPROT is clear to send. Read/write communication then
> happens via the read/write lines in a packet format.

Doesn't that mean that if I raise PH1 + PH3, other devices will be
listening
and could be confused?  Particularly if I then twiddle PH0 and expect
that
WRPROT is mine to drive?

> Unfortunately the
> documentation on the packet format was sufficiently bad that I read
> the ROM listing in the IIc reference manual instead. Do you have that?

Yes, I'll take a look.

BTW, doesn't this mean that SmartPort capability is just a matter of
software?  Could a little software/firmware make any Dx-19 disk
controller SmartPort-capable?

> A possible complication (sorry I'm away from home and don't have many
> of my docs with me) is that WPROT is actually /WPROT. If there's a
> SmartPort device on the bus, that's going to mean the line will be
> high during a PH1+3. I'm not sure whether it's pulled internally high
> or low or whether extra circuitry will be needed to compensate for the
> devices presence. Should be easy enough, just requires a little extra
> investigation....

Yes, WPROT is pulled high internally, but I can pull it back down when
the network is "enabled" so that the network state is read "true".

The polarity of the WRPROT logic on its way to bit 7 is correct--
high = 1 and low = 0.

As I noted in my reply to Ferdinand, I'm finding the software
implications
for NadaNet to be pretty distasteful...

It was designed with a "fully decoded" interface with separate entry
points and multiple exit points.  Clumping them all together to do
the "setup" code, then dispatch to the separate routines, then
force all routines to return to the dispatcher for "takedown" code,
is more than a little annoying, and a considerable waste of time
and space.

I suppose I could impose this structure only on the IIc/IIc+ and
"full speed" IIgs versions, but that would require more divergence
between the eight (!) builds (not counting the two AppleCrate
builds for general use and the Message Server) than can be
reasonably accomodated by conditional compilation.

Come to think of it, the Message Server should *also* exist
in all four variations (IIc, IIc+, IIgs, and "everything else", so
make that 13 builds!).

When faced with a choice between two unpalatable directions,
my inclination is to wait for the light to dawn.  ;-)

-michael