info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Groups keyboard shortcuts have been updated
Dismiss
See shortcuts
Strange mouse behavior
46 views
Skip to first unread message
Bob Alexander
Jun 16, 2021, 10:58:37 AM6/16/21
to
I have a Unix PC 7300 with a mouse that works ... sort of. When the PC starts up, the mouse cursor is in the upper left. When I move the mouse, the cursor flickers, but does not move. When I click the buttons, they trigger actions on the screen.
Has anyone seen this before? Any ideas for fixing it?
Thank you,
Bob
Has anyone seen this before? Any ideas for fixing it?
Thank you,
Bob
J Booth
Jun 17, 2021, 11:24:12 PM6/17/21
to
Hey Bob.
I happened to write a UNIX PC mouse tester program today, if you have an Arduino handy, you could try testing it out. The data is sent from the mouse in 3-byte packets at 1200 baud. I believe there's logic in the keyboard that then marshals the keyboard inputs with the mouse inputs and sends this to the 6850 chip on the motherboard. The mouse packets are only sent when an update occurs, e.g. button press or release, or an x or y mouse movement. Because the cursor flickers, it sounds like the packets are coming into the motherboard, but the x and y data isn't updated. Maybe something wrong with the x/y encoders in the mouse. You could try my test program if you wanted to confirm that the X and Y data is in fact being sent as zero -- and then you would know the problem isn't being introduced as it passes through the keyboard. If the X/Y data is correct, then it could be something introduced in the keyboard, but that seems unlikely if the mouse button presses are making it through. Looking at a pic of the mouse internals, I see a resistor, a couple capacitors, some optical encoders, 4Mhz crystal, a transistor, and the Motorola mystery chip SC87347P. Not sure where the culprit would be. Here's the link to the mouse tester: https://github.com/agentbooth/3b1mouse/tree/main/3b1MouseTester
Jesse
I happened to write a UNIX PC mouse tester program today, if you have an Arduino handy, you could try testing it out. The data is sent from the mouse in 3-byte packets at 1200 baud. I believe there's logic in the keyboard that then marshals the keyboard inputs with the mouse inputs and sends this to the 6850 chip on the motherboard. The mouse packets are only sent when an update occurs, e.g. button press or release, or an x or y mouse movement. Because the cursor flickers, it sounds like the packets are coming into the motherboard, but the x and y data isn't updated. Maybe something wrong with the x/y encoders in the mouse. You could try my test program if you wanted to confirm that the X and Y data is in fact being sent as zero -- and then you would know the problem isn't being introduced as it passes through the keyboard. If the X/Y data is correct, then it could be something introduced in the keyboard, but that seems unlikely if the mouse button presses are making it through. Looking at a pic of the mouse internals, I see a resistor, a couple capacitors, some optical encoders, 4Mhz crystal, a transistor, and the Motorola mystery chip SC87347P. Not sure where the culprit would be. Here's the link to the mouse tester: https://github.com/agentbooth/3b1mouse/tree/main/3b1MouseTester
Jesse
Bob Alexander
Jun 18, 2021, 10:29:45 AM6/18/21
to
I've taken a different approach for reading the mouse. I have a UART-to-USB gadget. It's configurable for 7 data bits, 1 stop bit. I connected that to a PIC microcontroller that's inverting the UART signals, since the mouse uses an inverted UART, and connected the PIC to the mouse.
When I press the left mouse button, I get (in hexadecimal) 1C 00 80. When I release the button, I get 18 00 80. For the middle button, it's 1A 00 80 and 18 00 80. Button three is 19 00 80 and 18 00 80.
So that looks OK, and it matches your Arduino code in your mouse emulator.
When I roll the wheels, it looks like I'm getting Move messages that cancel each other out. When I roll the Y axis wheel (I've taken the mouse ball out and I'm rolling the wheel directly) I get 18 00 81 10 00 81. Rolling the X axis doesn't send anything (though I'm pretty sure it was working 5 minutes before I wrote this; I tried blowing air at the sensors to dislodge any dust; maybe I've broken something :-( ).
When I press the left mouse button, I get (in hexadecimal) 1C 00 80. When I release the button, I get 18 00 80. For the middle button, it's 1A 00 80 and 18 00 80. Button three is 19 00 80 and 18 00 80.
So that looks OK, and it matches your Arduino code in your mouse emulator.
When I roll the wheels, it looks like I'm getting Move messages that cancel each other out. When I roll the Y axis wheel (I've taken the mouse ball out and I'm rolling the wheel directly) I get 18 00 81 10 00 81. Rolling the X axis doesn't send anything (though I'm pretty sure it was working 5 minutes before I wrote this; I tried blowing air at the sensors to dislodge any dust; maybe I've broken something :-( ).
Bob Alexander
Jun 18, 2021, 11:01:52 AM6/18/21
to
It's not broken: turning the power off and on got the X wheel working again.
But when I roll the X wheel, I get 18 01 80 08 01 80. So again, if I understand this correctly, it sending a Move Left followed by a Move Right and they're cancelling each other out.
- Bob
But when I roll the X wheel, I get 18 01 80 08 01 80. So again, if I understand this correctly, it sending a Move Left followed by a Move Right and they're cancelling each other out.
- Bob
J Booth
Jun 18, 2021, 11:17:24 PM6/18/21
to
That’s great you are able to read data from the mouse. Yes those packets are X: +1 followed by X: -1 .. I’m not sure what in the encoder determines the direction/sign.
Bob Alexander
Jun 19, 2021, 10:52:19 AM6/19/21
to
>and the Motorola mystery chip SC87347P.
Of course! It's a Motorola 6805 microcontroller!
- Bob
J Booth
Jun 21, 2021, 12:15:09 AM6/21/21
to
> I just noticed... the second line of text on that chip is "R6-6805".
Ahhh, great point! That explains it alright, I wasn't familiar with the 6805 but after reading about it, sounds correct!
Peter Schmidt
Jun 22, 2021, 7:37:33 AM6/22/21
to
Is there possibly some de-bounce logic - well, de-jitter logic - in the mouse meant to smooth motion, that's issuing the canceling offsets? I'm picturing oxidized contacts introducing resistance, lowering effective signal voltage, and motion thus failing to get over the de-jitter hurdle.
A stab in the dark...
--Peter
A stab in the dark...
--Peter
Bob Alexander
Aug 5, 2021, 1:41:58 PM8/5/21
to
I fixed it! Two of the optical detectors in the mouse were defective, one one each axis. It took this long to find compatible replacements. But I desoldered the two old detectors, put in new ones, and my AT&T mouse works!!!
I'm sooooo happy!
I'm sooooo happy!
Peter Schmidt
Aug 6, 2021, 12:23:55 PM8/6/21
to
On Thursday, August 5, 2021 at 1:41:58 PM UTC-4, goo...@LoadAccumulator.com wrote:
> I fixed it! Two of the optical detectors in the mouse were defective, one one each axis. It took this long to find compatible replacements. But I desoldered the two old detectors, put in new ones, and my AT&T mouse works!!!
>
> I'm sooooo happy!
Nice work! 🎉
> I fixed it! Two of the optical detectors in the mouse were defective, one one each axis. It took this long to find compatible replacements. But I desoldered the two old detectors, put in new ones, and my AT&T mouse works!!!
>
> I'm sooooo happy!
David Gesswein
Aug 10, 2021, 12:45:07 PM8/10/21
to
In article <18a4d592-e0ce-49ce...@googlegroups.com>,
Good to hear.
May be good to post the part you found if more available in case others
have the same problem.
May be good to post the part you found if more available in case others
have the same problem.
Bob Alexander
Aug 10, 2021, 1:02:35 PM8/10/21
to
> May be good to post the part you found if more available in case others
> have the same problem.
Quite right.
> have the same problem.
The part I got was a Honeywell SDP8600-003. The SDP8601-xxx is an preferable substitute - the pins should be easier to fit into the board. The SDP8602 is electrically compatible, but the pins are too far apart so you might have to jury-rig the wiring.
I had a hard time cramming the SDP8600 down far enough, so that it was lined up with the infrared LED. But it's absolutely vital that the sensor be aligned with the emitter. The light is shining through a narrow slit.
The last three digits in the the part number indicate the sensitivity. It probably doesn't matter what you get.
Now the bad news: these parts are no longer manufactured. I think they went obsolete in 2019. Finding someone who's selling them is tough. There are similar parts numbered SDP861X, and they're still in production, but their output signal is inverted. You'd have to jury-rig a NOT gate into the circuit.
0 new messages