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

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

On Sep 15, 3:34 pm, "Ferdinan Meyer-hermann" <ferdinan.meyer-
herm...@a2central.com.remove-4rg-this> wrote:
>   To: Michael J. Mahon
>
>
>
>
>
> Michael J. Mahon 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:
>
> Hey! Why are you hacking on that?!
> I wanted to do that!
> (just kidding ;-) )

Hey, I'd be happy if you wanted to get this working!

I have a IIc and a IIc+, but only the IIc+ is set up, and I don't have
anything like a complete set of SmartPort peripherals to do the
required compatibility testing.

Frankly, the more I look at what I have to put up with to centralize
the "setup" and "takedown" code, the less I want to mess my code
up with it.

NadaNet currently has multiple entry points and multiple exits to
the caller, depending on the semantics of the request.  It is a
royal pain to create one or a few common points to do things that
1) must be done to access the network and can't be done more
than once, and 2) must be done to "release" the network, and
can't be done more than once.  (If the setup and release code
must be idempotent, then the speed shift for the IIgs is even
more complex--you see, I'm thinking ahead...  ;-)

The alternative is to put up with multiple "setups" and "releases"
and put calls to them all over the place--poor structure, poor
memory usage, and even poorer performance.

NadaNet was coded under the assumption that the network
I/O capability was always available, and it's painful to change
that assumption at this point in the game.

> 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.
>
> Is this actually a problem?
> As long as the send line (let it be PH0) is 0 then nothing will be sent.
> And as soon as DOS/ProDOS needs the internal drive, it will select it and
> thus deselect the other "drive".

True.  Since the read data line won't be changing, the "wait for
previous
drive to stop" code will time out pretty quickly.

> 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.
>
> Can't we just make some versions of the send/receive code and load the
> correct one after detecting the machine?

Yes, but if the IIgs, the IIc, and the IIc are added to "everything
else",
abd then multiplied by ProDOS or DOS environment, that makes 8
different versions in place of the current 2--yuck.

> AFAIK the code is small, so it should not be a big waste of disk space to
> have three versions of the basic send/receive code.

It's not just the basic send/receive code, it's the whole enchilada.
You don't want to be enabling and disabling the network , or slowing
down a IIgs and speeding it back up, for each packet sent or received.
Timing constraints must be maintained between packets of a protocol,
too.

> But I think that a SmartPort like interface is a good idea for being more
> versatile. Although I didn't think of connecting an external disk drive
> yet, I might want to connect a 3.5 drive to the //c as well.
>
> BTW, you won't be able to do a SmartPort like interface with just a '08,
> because you need a three-state driver for the WPROT line.

I'm not too worried about the logic required yet--first I'd like to
see
the possibility of a solution that I don't find repulsive.  ;-)

-michael