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 -