Unfortunately, I don't know of a single source for all of the relevant info.
Charles MacDonald has some info spread across his EMS AR doc and his comms protocol doc, and there's the waveform diagram in the Free Wing package. I also poked around with a multimeter some years ago. I'll try to piece it together here (some details are from memory and could be wrong):
There are 4 chips on the PC comms card:
- One 74374/574 8-bit tri-state flip-flop (stores the PC->PAR byte)
- One 74373/573 8-bit transparent latch (stores the PAR->PC byte)
- One 7474 dual flip-flop (stores the "waiting for response" status flag / the state of STB)
- One PAL/GAL chip to decode the port addresses and otherwise glue things together.
(The PAL/GAL might be overkill for what was actually implemented; the Datel card looks like they tried to implement an interrupt-driven mode, but this isn't documented anywhere and I don't know of any software that uses it)
The interface presented to the PC is two I/O port addresses: a data port and a status port, typically at $320 and $322 respectively, but jumpers on the card can move them to $300/$302, $310/$312, or $330/$332.
An exchange basically goes like this:
The PC application writes a byte to the data port. This sets the contents of the PC->PAR flip-flop and causes STB to go high, indicating to the PAR that a byte is available. It also sets the PC-side status flag (essentially the same thing as STB), indicating that a response has not been received yet. The application spins until the status flag goes low again or until a maximum timeout period.
The PAR reads the sent byte, then writes a response byte. This causes /ACK to go high and then low (I think it's just a buffered version of the write pulse from the CPU).
The /ACK pulse does three things:
1) Disables the output of the PC->PAR flip-flop for the duration of the response write (i.e. it's connected to /OE of the PC->PAR flip-flop, and the fact that it's high disables the output)
2) Causes the PAR->PC latch to latch the response byte (i.e. it's connected to LE of the PAR->PC latch, and the falling edge causes the response byte to be latched)
3) Clears STB/status (I don't remember how this is done; might go through the PAL)
The PC application sees that the status flag is cleared and reads the data port, returning the contents of the PAR->PC latch.
If you really need verification of the hardware details, I might be able to find my comms card and throw it on the scanner, but that won't give you the PAL contents...
You might also find
this interesting.