PC mouse to QL conversion project

Nagging hardware related question? Post here!
User avatar
RalfR
Aurora
Posts: 870
Joined: Fri Jun 15, 2018 8:58 pm

Re: PC mouse to QL conversion project

Post by RalfR »

Dave wrote: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. ;)


4E75 7000
User avatar
Andrew
Aurora
Posts: 786
Joined: Tue Jul 17, 2018 9:10 pm

Re: PC mouse to QL conversion project

Post by 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.


User avatar
Dave
SandySuperQDave
Posts: 2765
Joined: Sat Jan 22, 2011 6:52 am
Location: Austin, TX
Contact:

Re: PC mouse to QL conversion project

Post by 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.


User avatar
RalfR
Aurora
Posts: 870
Joined: Fri Jun 15, 2018 8:58 pm

Re: PC mouse to QL conversion project

Post by RalfR »

Dave wrote: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!


4E75 7000
Nasta
Gold Card
Posts: 443
Joined: Sun Feb 12, 2012 2:02 am
Location: Zapresic, Croatia

Re: PC mouse to QL conversion project

Post by Nasta »

mk79 wrote:
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.
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
Super Gold Card
Posts: 633
Joined: Fri Jan 18, 2013 5:27 pm
Location: Prague, Czech Republic

Re: PC mouse to QL conversion project

Post by 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
Gold Card
Posts: 443
Joined: Sun Feb 12, 2012 2:02 am
Location: Zapresic, Croatia

Re: PC mouse to QL conversion project

Post by Nasta »

tcat wrote: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.


User avatar
1024MAK
Super Gold Card
Posts: 592
Joined: Sun Dec 11, 2011 1:16 am
Location: Looking forward to summer in Somerset, UK...

Re: PC mouse to QL conversion project

Post by 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


:!: Standby alert :!:
“There are four lights!”
Step up to red alert. Sir, are you absolutely sure? It does mean changing the bulb :!:
Looking forward to summer in Somerset later in the year :)

QL, Falcon, Atari 520STFM, Atari 1040STE, more PC's than I care to count and an assortment of 8 bit micros (Sinclair and Acorn)(nearly forgot the Psion's)
Post Reply