Re: Reporting Data 1-Way-Out?

["Michael J Mahon" <michael.j..mahon@1:124/5009.remove-xtk-this>]

  To: mdj
From: Michael.J..Mahon@familynet-international.net

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."
-+- SBBSecho 2.12-Win32
 + Origin: Derby City BBS - Louisville, KY - derbycitybbs.com (1:2320/100)

--- BBBS/NT v4.01 Flag-5
 # Origin: FamilyNet Sponsored by http://www.christian-wellness.net (8:8/2)
 * Origin: FamilyNet Echogate [972] 496-0650 (1:124/5009)
--- Synchronet 3.15a-Win32 NewsLink 1.85
 *  Derby City Online - Louisville, KY - telnet://derbycitybbs.com