[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Reporting Data 1-Way-Out?

mdj wrote:

On May 29, 4:54 am, "Michael J. Mahon" <mjma...@aol.com> wrote:


mdj wrote:


On May 28, 5:08 am, "Michael J. Mahon" <mjma...@aol.com> wrote:



I see.  I think you'll find the Apple //e much easier to interface
with sensors and other devices.  The IIc is less versatile because
it does not provide digital outputs on its joystick/mouse port.



One way around this limitation is to use the stepper phase outputs on
the disk port to provide digital outputs. At the same time, you can
use the write-protect signal to provide another digital input.


Good point!

I'll have to think about that some more...

If all the digital I/O is made mutually exclusive with disk activity,
then that would be a quite elegant solution!

When I get a chance, some experiments are in order...

And that brings up the question:  Why didn't we see a bunch of
devices interfaced to the external disk port?



Good question! Of course, there was the UniDisk 3.5" and the uber rare
Chinook CT-20c ...


But those were both SmartPort devices--much cleverer than a few gates
and buffers to use the seek phases as digital outputs.

And both of these were storage devices--so nothing cute like a robotic
arm or a network.  ;-)


As far as isolating such a device from disk activity goes, the best
approach would be to use the same technique that SmartPort devices use
to turn the Disk Port into a bus:

When the host wishes to chat to a SmartPort device, it enables PH1 and
PH3. Any SmartPort device on the bus will then 'gate' the /ENABLE2
line (by deasserting it), which renders any disk 2 on the bus
inactive. The host then asserts /ENABLE2 which will render disk 1 (or
a //c's internal drive) inactive as well.


Which explains why SmartPort devices must precede "dumb" devices on
the daisychain...


SmartPort devices treat PH0 as REQ, and WRPROT as ACK. To start a
communication, the host activates REQ(PH0), waits for ACK(WRPROT),
then sends a command packet 'writing' the data. REQ goes low at the
end of send, and when ACK goes low that signals the host to 'read'
back from the Smartport device.

If for example one wanted to make a //c nadanet adapter, one could
follow the above standard, and use PH2 to transmit, and WRPROT to
receive. If you only allow the device to be active during PH1+PH3,
you'll avoid any spurious data infesting the network during SmartPort
initialisation or disk activity.

It's also worth pointing out that /IRQ is available at the //c disk
port, which provides a whole other level of options.


Frankly, that level of complexity would seem to suggest a
small microcontroller rather than a couple of TTL parts...

Put another way, a game port, it's not.  ;-)

-michael

AppleCrate: 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."