• Strange mouse behavior

    From Bob Alexander@21:1/5 to All on Wed Jun 16 07:58:36 2021
    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)
  • From J Booth@21:1/5 to All on Thu Jun 17 20:24:11 2021
    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)
  • From Bob Alexander@21:1/5 to All on Fri Jun 18 08:01:50 2021
    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)
  • From Bob Alexander@21:1/5 to All on Fri Jun 18 07:29:44 2021
    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)
  • From J Booth@21:1/5 to All on Fri Jun 18 20:17:23 2021
    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)
  • From Bob Alexander@21:1/5 to All on Sat Jun 19 07:52:18 2021
    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)
  • From J Booth@21:1/5 to All on Sun Jun 20 21:15:08 2021
    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)
  • From Peter Schmidt@21:1/5 to goo...@LoadAccumulator.com on Tue Jun 22 04:37:32 2021
    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, goo...@LoadAccumulator.com 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)
  • From Bob Alexander@21:1/5 to All on Thu Aug 5 10:41:57 2021
    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)
  • From Peter Schmidt@21:1/5 to goo...@LoadAccumulator.com on Fri Aug 6 09:23:54 2021
    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! 🎉

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bob Alexander@21:1/5 to All on Tue Aug 10 10:02:34 2021
    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)
  • From David Gesswein@21:1/5 to google@loadaccumulator.com on Tue Aug 10 16:45:05 2021
    In article <18a4d592-e0ce-49ce-8a1c-326b027a7ea5n@googlegroups.com>,
    Bob Alexander <google@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!


    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)