tcat wrote:My mouse connects to SER1, while Linux host to SER2. What has troubled me so far, is that incoming mouse data on SER1 appears also in SER2 input queue. I have not been able to figure out why.
That I can easily answer. The two receive lines are internally connected, the hardware cannot distinguish between them. My question is more how the QL was ever supposed to separate SER1 and SER2. I can only imagine toggling the handshake lines and multiplexing the combined receive line to the one that currently has an active handshake or something like that.
Two serial ports can only be used on a QL if BOTH devices attached support handshake. If not, data will bleed over from one port to the other.
This is because there is really only one receive channel and it's 'multiplexed' between two ports.
The multiplexing scheme simply makes a logical 'OR' function between the incoming data on the two ports, and relies on just one transmitting, the one that has the RTS (request to send) signal active, and it's thus allowed to send data, while the other's transmit line should stay in the inactive state.
The reason data bleeds into the other port when a mouse is attached is that a serial mouse typically does NOT support handshake, and will happily continue sending movement data when it is moved, regardless of the state of the handshake signal.
Unfortunately it's not possible to 'fix' the issue of the other port chattering even when the handshake signal tells it not to by cutting off the signal using the handshake line, because the serial communication standard defines that the sending device only checks the handshake signal before sending the start bit of the next character. This makes it possible for the receiver to deactivate the handshake in the middle of the last character that the sender sends, and this was done because of old serial chips, so that the sender would receive an interrupt that no more characters should be sent, while the last one is being sent, in order to give it's internal logic (software) to react and prevent sending of the next character.
Because of this, it's not possible to gate the serial input of a port by it's own request to send, because that may cut off the communication while bits of the previous sent character are still being transmitted.