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

["Ferdinan Meyer-hermann" <ferdinan.meyer-hermann@a2central.com.remove-4rg-this>]

  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 ;-) )
> 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".
> 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?
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.
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.

Regards,

Ferdinand Meyer-Hermann