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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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 :-( ).

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

and the Motorola mystery chip SC87347P.

I just noticed... the second line of text on that chip is "R6-6805".

Of course! It's a Motorola 6805 microcontroller!

- Bob

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

On Friday, June 18, 2021 at 11:01:52 AM UTC-4, [email protected] wrote:

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday, August 5, 2021 at 1:41:58 PM UTC-4, [email protected] 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! 🎉

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

May be good to post the part you found if more available in case others
have the same problem.

Quite right.

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <[email protected]>,
Bob Alexander <[email protected]> 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!

Good to hear.
May be good to post the part you found if more available in case others
have the same problem.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)