[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: NadaNet for the //c - just an idea
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. 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?
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....
Matt