>  I haven't checked in detail and taking your word for it,  your system could
> work in the circumstances you outlined though you probably wouldn't be
> recommending it as the first one to consider. Usually there are other
> "work-arounds" otherwise a protocol like this would be commonly known and
 used.

Well, often there are other features that can be used, most notably either:
[1] a UART on one/both ends [makes things REAL obvious/easy]; [2] a function
to latch whether a port pin has changed [even if it has since changed back]--
this allows a decent bidirectional interleaving protocol to be run on two
single-directional wires; or [3] a function to keep a pin pulled low after
something external pulls it low [I2C clock works like this].  I was suggesting
my protocol in the context of people using a device like the 16C54 which has
none of the above, talking to a PC printer port which has none of the above.

> Also, I didn't mean to send my reply as it was. I always start of brash and
> mellow down on the second or third revision. I changed proceedure with
> eudora and sent the 1st draft accidentally. I didn't mean to it be so sharp
> on this matter, sorry.