You can use a port in 3 modes: 'standard', ECP, EPP.  We decided to be
'lazy' and use 'standard' mode: who knows if a client has a board that
supports the other modes?

In this mode, the output lines are output and, as far as I can tell, are
always so.  You have to assume so, with the big variety of cards out there.

This means that you must use other lines for input: here they are:
ACK     The interrupt line
BUSY
PE
SLCT
ERROR

Not enough lines for a full byte.  So we do nybble transfer:
1. Put 4 data bits on BUSY, PE, SLCT, ERROR
2. Raise ACK
Now your PC code interrupt procedure is called.  It takes the 4 data bits
and raises one of the standard 8 output lines (we call it STROBE), and then
goes into a loop with a tight timeout.
The PIC sees the data line go high.  Now it:
3. Puts the other 4 data bits on BUSY, PE, SLCT, ERROR
4. Clears ACK
The PC loop sees ACK drop and gets the other 4 bits.  It clears STROBE.  A
byte has been transferred.  Both devices get on with their work.
A word of warning.  We found that PC's take a very variable time to respond
to an interrupt.  We have to cache a few bytes.  Our transfer procedure is
also a bit more complex at the PIC side, we sometimes use opto isolators,
so we have a delay between loading the data bits and setting ACK, due to a
time difference in rise vs drop introduced by the isolator we use.  Again,
our application is complex because it is receiving radio data at the same
time as it is doing parallel transfers, we can only transfer at certain
times, and can't hang about waiting for the PC.  We use a transfer
subroutine with control flags to say which phase of the // transfer we are
in right now.

Our Windows code is still 16 bit (old dog, new tricks).  Enabling/disabling
interrupts is fun......  The interrupt handler isn't too bad, once you've
worked out which port and i/o address you're working with.  You just need
to read the docs to see which i/o address has the lines you are playing
with.  The output lines are on the base address, the other lines on base+1.
 The main thing is to make sure you put in enough timeout tests to avoid
hanging the PC.  You can't debug interrupt procedures very easily, and they
can hang up the PC.  Setting a break point in one is not recommended......

if only:
1. everyone had an ECP card.
2. C compilers had a 'read ECP data' function
3. a nice document described what a PIC had to do to meet the PC read
requirements.
Win/32 appears to have a 'read printer' capability, which may meet point 2.
 It doesn't help the other points.

I feel ECP is fairly complex.  Even if a PC port has ECP capability, it
operates in standard mode until
1. The PC tells it to assume another mode
2. Negociation with the remote peripheral for the new mode takes place.

If you want to do it yourself, it is documented in the Microsoft
Development Platform CD's.  Good luck.

We prefer to use serial protocols/ports:
1. We 'echo' data from radio applications up a serial line bit by bit on
reception for monitoring/debug purposes.  The quotes are due to needing to
'un-manchester' the radio data before echoing.
2. We use serial ports for nearly all command interfaces to remote PICs
3. We provided a // port monitor function only because a mouse and a
command line use both serial ports on standard PC's.  Again, we assume the
worse for client PC's.  For our own work, we have PC's with 4 serial ports
all on different IRQ's.
4. Our internal oscilliscope/logic probe device is still serial, but fairly
high speed.
  <edtodd@sni.net>    Ed Todd