PC mouse to QL conversion project

[RalfR]

Separately, we're still discussing the option of replacing the QIMI socket with an InPort socket (mini-DIN9) so that any PC bus mouse can be used directly, without adaptors. PC mice are still generally available and cheap.

Hmm, an Atari mouse compatible socket would make a bit more sense in my opinion.....?! I think, a lot of user have such mice. Or change to a reliable PS/2 socket to use a common mouse. Just my idea.

[Andrew]

USB mouse - so we can use a common mouse
There is a convertor from USB mouse to ATARI mouse, so maybe it could be included on the board - this would be most convenient.
Also I have seen schematics for a USB to DB9 serial convertor - I do not know if they work or not.

[Dave]

Most Atari mice are old now, and aperture type. There are new optical bus mice.

My biggest persuasion is that I have "almost free access" to a couple of large boxes full of brand new 3-button bus mice. Black mice. For about $3.50 a piece.

[RalfR]

Most Atari mice are old now, and aperture type. There are new optical bus mice.

My biggest persuasion is that I have "almost free access" to a couple of large boxes full of brand new 3-button bus mice. Black mice. For about $3.50 a piece.

Great!

[Nasta]

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.
Marcel

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.

Aside:
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.

[tcat]

Hi,

The multiplexing scheme simply makes a logical 'OR' function between the incoming data on the two ports, and relies on just one transmitting

That explains that nicely. Reading QL wiring schematics now makes sense. RXD(SER2), TXD(SER1), are fed through two NOR-NAND gates, to drive INT of IPC, they also join P20 single input pin, which is RS232 common ine in. NOR-NAND are replaced by HAL on Iss#6 board, so it seems. Am I close?

Tomas

[Nasta]

Hi,

The multiplexing scheme simply makes a logical 'OR' function between the incoming data on the two ports, and relies on just one transmitting

That explains that nicely. Reading QL wiring schematics now makes sense. RXD(SER2), TXD(SER1), are fed through two NOR-NAND gates, to drive INT of IPC, they also join P20 single input pin, which is RS232 common ine in. NOR-NAND are replaced by HAL on Iss#6 board, so it seems. Am I close?

Tomas

Yes, but it's negative logic so it uses a NAND gate followed by another NAND gate connected as an inverter, to get an AND gate. An AND gate is the logical equivalent of OR for negative logic, it's output will be zero if one OR the other OR both inputs are zero. It is a bit confusing because the TTL level serial port pins are inverted, because RS232 drivers and receivers invert, so you get double inversion which cancels out the inversion.
The reason why the IPC uses INT and P20 connected together is to detect a start bit, which will be a low level on the INT pins and cause an interrupt, which in turn activates the receive algorithm which reads the actual bits through P20 (since the IPC can't test the INT pin directly, nor cause an interrupt on a change of state of a port pin).

I should say that the different labeling of the ports drives me nuts. So, RXD is an input in one case, and TXD is an input in the other, which is very counter-intuitive. Why that standard even specified DTE and DCE labeling, I will never understand, in effect it created a system that has a 50% chance of connecting properly, from the outset.

[1024MAK]

The RS232 standards are mostly concerned with connecting Data Terminal Equipment (teletypewriters and later computers and other equipment) and Data Communications Equipment (MODEMs). Indeed, a 25 pin D connector cable should be straight through in this application. The only reason for the cable being the physical problem of it not being practical to directly connect two items together without a cable. Of course, just like many so called ‘standards’, to cut costs, many manufacturers did not implement full interfaces. And home computer manufacturers could not make their mind up if the computer should be wired as a DTE or DCE device. Printer manufacturers also could not make up their minds...

Hence why RS232 break out boxes became popular...!

Sinclair, with the interface 1, labelled the non-standard 9 way D connector signals as DCE, as it was expected to mainly be used with serial printers. So it is not that surprising that one QL serial port is treated the same way.

Mark