[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: NadaNet for the //c - just an idea
On Aug 25, 6:04 pm, "Michael J. Mahon" <mjma...@aol.com> wrote:
> Ferdinan Meyer-hermann wrote:
> > To: Michael J. Mahon
> > Michael J. Mahon wrote:
>
> >> mdj wrote:
> >>> On Aug 25, 9:23 am, "Michael J. Mahon" <mjma...@aol.com> wrote:
> >>>> Ferdinan Meyer-hermann wrote:
> >>>>> To: comp.sys.apple2
> >>>>> It is just an idea that came to my mind:
> >>>>> The //c does not have Annunciator outputs, so it doesn't allow for the
> >>>>> usual way to connect the NadaNet interface. But I think it might be
> >>>>> possible to do this over the disk port.
> >>>>> One could use pin 11(Stepper phase 0) as the data line and pin 16 as an
> >>>>> enable, like this:
> >>>>> pin 6 (VCC)
> >>>>> --------------------------------+
> >>>>> C /
> >>>>> pin 11(PH0) 2.2K |/
> >>>>> --------------/\/\/\------+---|
> >>>>> | |\ +---> to PB1
> >>>>> | E \ |
> >>>>> C / | |
> >>>>> pin 16(/EN) |/ +-|>|--+---> to NadaNet
> >>>>> -----------/\/\/\------| |
> >>>>> 10K |\ \
> >>>>> E \ /
> >>>>> | \
> >>>>> | /
> >>>>> pins 1-4(GND) | |
> >>>>> --------------------------+------------+---> to NadaNet
> >>>>> Now, to send some data, you would need to Initialize:
> >>>>> STA $C0E0 Phase 0 off
> >>>>> STA $C0EB Select drive 2
> >>>>> STA $C0E9 Drive on
> >>>>> And then, the normal NadaNet send routine can be used, with the Address
> >>>>> of the PH0 softswitch($C0E0/$C0E1) instead of the AN1 switch.
> >>>>> After transmitting, you should turn the drive off, but do not select
> >>>>> drive1, or you will make the drive motor spin up and down:
> >>>>> STA $C0E0 Phase 0 off (if not done by send routine)
> >>>>> STA $C0E8 Drive off, DOS/ProDOS will select correct drive
> >>>>> afterwards
> >>>> 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.
> >>> Should work OK, with a couple of caveats:
>
> >>> //c's don't have pin 16 connected, since that's routed to the internal
> >>> drive. Instead you'd have to use pin 17 (which is /DR2). It's still
> >>> important to include the
> >>> emitter follower off PH0 using /DR2 in a sortof tri-state
> >>> configuration (as ferdinand points out) otherwise disk access to the
> >>> internal drive would send useless noise onto the 'net.
>
> >>> As for the input signal, it's probably considerably simpler to add
> >>> another emitter follower to buffer input from WRPROT than use the
> >>> PB's. Firstly, this would negate the need to tap two different
> >>> connectors, and avoids the 'complexity' of dealing with the PB inputs
> >>> on the IIc.
> >> From what I can determine, the state of WRPROT cannot be determined
> >> directly, but only through the state machine shifting it into the
> >> data register. This eliminates it as a possibility for NadaNet sensing,
> >> since that process takes a lot longer than 4 cycles.
>
> > I thought that too at first, but in sense Write protection mode the shift
> > register will shift the bit right into bit 7 in one clock cycle -> in
> > 0.5us, which should be accurate enough. And even if the signal goes through
> > the whole shift register it would just be delayed and not distorted, i.e.
> > it could still be used.
> > I'm saying that based on the original Disk][ controller. I the IWM of
> > the //c may behave differently, of course (but I suspect it does not).
>
> I'm pretty sure it does, too--and I agree that WRPROT will serve as a
> NadaNet input. Any half-cycle dither will be tolerated by the read
> DPLL.
>
> >> I'm also concerned about the rise and fall time of the opto-isolators
> >> and associated circuitry. I haven't made any measurements, but that
> >> could be an issue. Apple made it pretty clear with the Platinum //e
> >> and its 0.1uF caps that they didn't regard PB bandwidth as a spec.
>
> >> It doesn't help that my IIc and IIc+ schematics are all but unreadable..
>
> > you can (at least) the //c technical reference manual here:
> >http://www.scribd.com/doc/200852/Apple-IIc-Reference-Manual-Volume-1-...
>
> Yes, I have a hard copy of that manual, but the real schematic does not
> show the actual PB schematic, and the PB documentation pages have a
> somewhat abstract schematic.
>
> Good thing I'm no longer interested in driving a PB input. ;-)
>
> -michael
>
> AppleCrate II: An Apple II "blade server"!
> Home page: http://members.aol.com/MJMahon/
>
> "The wastebasket is our most important design
> tool--and it's seriously underused."- Hide quoted text -
>
> - Show quoted text -
I am curious. I wonder why you can't build a NadaNet controller
card instead of using I/O GAME or I/O DRIVE because you want too
simple circuit. Too sad for Apple //c. Why can't you use
communication port such as serial port?
Nephi