This is only on topic if you are building a PIC related device that connects to a PC parallel port and you want to keep your printer connected to the same port at the same time. If I read the IEEE 1284 standard correctly, the signal "IEEE 1284 Active" (pin 17-36, nSelect Input) must always be set high by the host before the data bus direction can beÊreversed except in EPP mode. The Host must also direct the Peripheral to drive data bus by setting HostBusy (pin 14, nAutoFeed) low while in Byte mode, nReverseRequest (pin 16-31, nInit)low in ECP reverse mode, or nWrite (pin 1, nStrobe) high in EPP mode. If I want to build a device (a PIC programmer, print buffer, printer switch etc...) that connects between the PC and the printer so that the printer is connected at the same time as my device, can I know that the direction on the data bus has been reversed when "IEEE1284Active" AND (NOT "HostBusy" OR NOT "nReverseRequest") OR "something that tells us we are in EPP mode"ÊAND "nWrite"? I doubt that this is reliable. All these signals are defined EXCEPT "something that tells us we are in EPP mode." Unlike the other modes that use IEEE 1284 Active and are terminated when it is not asserted which would then indicate a normal SPP mode, EPP is terminated by nInit (pin 16-31) which would not normally be asserted during SPP operation and cannot be used as an EPP mode indicator. Monitoring the negotiation phase to detect request and acceptance of EPP operation would seem to be the only other alternative. The question then becomes, "how few signals can I monitor to verify that EPP (or another) mode has been entered." My guess is that only the host request for negotiation via nSelectIn high and nAutoFeed low, the data lines (to see what mode was requested) clocked by nStrobe and the peripherals response via nAck (asserted BEFORE nStrobe so we know we are "not in SPP land anymore, Toto" and then released to clock Select) and Select (high if the mode was accepted and low if not) are required. Then I can monitor nSelectIn as "IEEE 1284 active" to see an exit from Byte or ECP modes and nAutoFeed as HostBusy to see reversals in Byte mode and nStrobe as nWrite to see reversals in EPP mode. But then, I also have to monitor pin 16-31 as "nInit" to see the exit from EPP mode and as nReverseRequest to see reversals in ECP mode so the total is 4 status pins and the 8 data pins. pin number SPP signal negotiation byte mode ECP mode EPP mode host periph name function function function function ---- ------ ----------- --------------------- ---------------- ------------ ----- ------------------ 1 1 nStrobe "mode # on data bus" nWrite(H=Rev) 13 13 Select XFlag(H=mode ack) 14 14 nAutoFeed (L=Start then H=1284) HostBusy(L=Rev) 16 31 nInit nRevReq(L=Rev) nInit(L=Exit) 17 36 nSelectIn (H=Start) IEEE1284(L=Exit) IEEE1284(L=Exit) OK: So the questions are: 1. Can normal (SPP) operation mimic a mode that reverses the data direction to the extent that "IEEE 1284 Active" would be low (the SPP printer is selected) and nAutoFeed is low or nInit is low? In other words does anybody use nAutoFeed or nInit while using nSelect? Probably: YES. 2. What is "something that tells us we are in EPP mode." Probably: MODE NEGOTIATION 3. What is the minimum number of pins that can be used to reliably detect negotiation to other than SPP mode? Probably: 4 STATUS, 8 DATA 4. Is there a way that the Host/Peripheral could leave a mode or not reverse that these pins would not indicate? 5. Is there a better (electronic: sense the direction current wants to flow?) way to do this? If we could be assured that the Peripheral would always terminate the data lines with pull-ups to Vdd, we could insert a buffer between the Host and Peripheral and tri-state it when $FF is read at the Host side then reverse and drive the Host when anything other than $FF is read at the Peripheral side. Terminate reverse when $FF again appears at the Peripheral (but then what if the Peripheral was trying to SEND $FF? can we be assured that the Host will have pull ups?) 6. Is this too long and too complex a question to post to the PICLIST and should I apologize for that? Where else should I post it? The questions I am not going to ask are: 1. Has there ever been a virus written that drives the PC parallel port to simulate mode negotiation into a reverse data capable mode and then signals a reversal while at the same time driving the data lines, thereby blowing out the PC parallel port or the printers parallel port? 2. How do manufacturers of printers etc... protect against this? 3. Has anyone ever made a PIC programmer or other device specific PC program that would accidentally get a IEEE 1284 printer into reverse mode when run with the printer (erroneously) still attached? 4. Why do I get into these things???? James Newton, webmaster http://get.to/techref jamesnewton@geocities.com 1-619-652-0593 phone