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