Looks like a crystal oscillator in a ceramic package- the markings suggest a 4MHz frequency. Should be easy enough to replace if it's gone bad.

Edit- technically it's called a ceramic resonator (https://en.wikipedia.org/wiki/Ceramic_resonator), but its function is similar to a crystal oscillator.

Does the 486 have an faulty UART for the serial port, maybe?
I'd run CheckIt! v3, with a loop-back dongle if available.

Also, some older multi i/o cards had an 16450 FiFo still.
It was usually being replaced by modem users by a 16550 (A, AF, AFN etc)..

sometimes old mice just die https://www.leadedsolder.com/2023/09/12/tokio … se-adapter.html

I can still test the mice on my K6 system to have more data, I'll check that tomorrow.

Loop-back dongle is also a good idea to check the UART itself, if I look at https://knowledge.ni.com/KnowledgeArticleDeta … YFtECAW&l=en-US I just have to connect pins 2 and 3 it seems.

What puzzles me is that the mice fail on 2 different (old) computers, but slightly differently.

...and I tested them on the K6 (GA-5AX) and both mice work flawlessly even after 5 cold reboots.

Great...I guess the next step is really to test the ports using the loopback method as suggested on both 486/Nexgen systems. I still can't understand why it sometimes works on these machines.

check the -12v line for irregularities.

Hmmm somewhere there is a doc that explains the diff between MS, Logitech and Mouse system protocols and only MS was the most backward/forward compatible iirc.
Just thinking outloud.... I use only MS serial mice on my vintage gear, never have a problem... but that is just my experience.

Hi, I remember there's a Logitech mouse driver for DOS.
Because, it's also part of Helix Multimedia Cloaking package I'm using (as a cloaked driver).
I know so far that it works with MS Mouse compatible mice, but maybe also has special support for its own Logitech mice.

Btw, I remember that MSD in DOS had the ability to "detected" mice, even if no mouse driver was installed.
Still wonder how that works. Do some mice models have a microcontroller?
Or is mouse type being determined by what pinout is being used?
Or is it the protocol/format, the way serial data is being received?

For PS/2 mice, it just probes the IRQ line (IIRC, it is always 12?), and gets a response at a fixed IO address.

For serial mice, it would need to detect a serial UART, then probe it at 9600 baud, if I recall right. Serial mouse is more dodgy, as there were competing standards. Vintage serial mice have a little switch on the bottom, in most cases. Microsoft's communication protocol won out, most likely due to it being defacto standard with windows.

Some mice work better in dark ambient.
Some mice have problems when being used in sunlight.
This is no joke!

Perhaps your mouse is affected too?

Jo22 wrote on 2024-02-01, 18:45:

Does the 486 have an faulty UART for the serial port, maybe? I'd run CheckIt! v3, with a loop-back dongle if available. […]
Show full quote

Does the 486 have an faulty UART for the serial port, maybe?
I'd run CheckIt! v3, with a loop-back dongle if available.

Also, some older multi i/o cards had an 16450 FiFo still.
It was usually being replaced by modem users by a 16550 (A, AF, AFN etc)..

No need to have a 16550 for a serial mouse to work correctly.

All standard serial mice (Mouse Systems, Microsoft, Logitech) operate at 1200 baud.

For Microsoft and Logitech mice, the procedure for determining the mouse type is as follows:
The mouse driver first tries to determine its presence on the first COM port; if this fails, it tries the second port and, possibly, the following ones. Some drivers support only the first two ports; some need to specify the port number in the driver call parameters if the mouse is connected to the third or fourth port.
To determine the presence of a mouse, the driver sets a positive voltage of 12V on the RTS port line; the mouse must respond to this by transmitting the first byte containing the value 4Dh if the mouse is Microsoft or Logitech. This may be followed by ID bytes by which the driver can recognize a specific type of mouse.

There are three varieties of Microsoft compatible serial mice:
1. “Old” or MS - two buttons, responds only with the 4Dh byte. The mouse reports in three bytes.
2. MS+ (Logitech) - three buttons, responds with the 4Dh byte and an additional identifier. The mouse reports three bytes (the same as for MS) and an additional fourth if the middle button is pressed.
3. MS 3D – three buttons and a wheel, responds with the 4Dh byte and an additional identifier. The mouse reports four bytes (the first three are the same as for MS).

From this we can see that a driver designed to work with an MS mouse (and these are all Microsoft DOS drivers) will work with any Microsoft or Logitech mouse, but only in two-button mode. The Logitech DOS driver supports the middle button when using an MS+ (Logitech) mouse.

Determining the presence of a three-button Mouse Systems mouse is made difficult by the fact that the original standard did not provide for a mouse response to a driver request. Usually the driver assumes that the mouse is connected to the first COM port, but cannot check this. No other ports are scanned. Related to this is Mouse Systems' "detection" of the mouse, even if no mouse is connected or in the event of a faulty mouse. If the mouse is connected to a port different from the first one, then the port number should be specified in the parameters when starting the driver. Attempts have been made to develop methods for Mouse Systems to detect mice: some drivers check for the presence of a DSR - DTR connection, assuming that these lines are closed at the mouse, but this method is unreliable; mice from some manufacturers respond to the request with the 6Dh byte, and when using the appropriate driver, such a mouse can be detected by polling the ports.

I'm guessing the problem with the new Minutemanqvs mouse is due to the LEDs in the mouse not being bright enough due to not having enough current through them. All COM ports have a variation in the current they are capable of delivering along their lines. This is due to some difference in the +12 and -12V voltages in different computers, variation in the resistance of the current-limiting port lines, and differences in the current consumption of different mice. To begin with, I would suggest setting up the LED-photodiode pairs so that their lenses are strictly opposite each other and coaxial. If this does not help, you should reduce the resistance of the resistor in series with the LEDs by about 20%. On the board of this mouse, such a resistor should be located on the side of the printed conductors, apparently in an SMD design.

Thanks a lot for all your replies and tips, I have something to occupy my weekend with now.

The last explanation (limited current/voltage) would explain why these mice behave differently and are "half detected" on some systems, while working perfectly fine in the newer K6. Note that all my tests were made on COM1 to avoid detection issues on other COM ports. There was still a third (dirty) Logitech serial mouse at the second-hand shop for around 3€, I'll pick that up for my testings.

The more I start debugging old computers, the more I'm looking to buy a cheap oscilloscope so I can actually see low-frequency signals. Would someone have one to recommend, in the sub- 150€ range? At the moment I only have a multimeter and it begins to be pretty limiting.

kingcake wrote on 2024-02-02, 09:34:

Jo22 wrote on 2024-02-01, 18:45:

Does the 486 have an faulty UART for the serial port, maybe? I'd run CheckIt! v3, with a loop-back dongle if available. […]
Show full quote

Does the 486 have an faulty UART for the serial port, maybe?
I'd run CheckIt! v3, with a loop-back dongle if available.

Also, some older multi i/o cards had an 16450 FiFo still.
It was usually being replaced by modem users by a 16550 (A, AF, AFN etc)..

No need to have a 16550 for a serial mouse to work correctly.

Not necessarily needed, true. The 16550 does cause fewer interrupts, though.
It's less annoying, so to say. ;)

So it's always a good idea to retire a 16450.
Back in the 90s, it was a common recommendation in PC magazines to replace it.

Many multi i/o cards have the DIP/DIL version soldered, so a socket for an 16550A/AF/AFN can be easy installed.

WfW 3.11 can use the FiFo natively, there is a setting in system.ini.

Edit: More modern ISA modems usually had an 16550 installed.
Merely the fax modems and lower speed modems for Minitel/BTX had an 16450.

Which was mainly money-related, I think.
Companies assumed this was good enough, especially since DOS was single-tasked and that no buffering was being required.

Because otherwise, it makes no sense.
The 16550 had been superseded that 16450 in the 80s already.
The 16450 is barely better than an 8250 dinosaur.

Edit: I forgot to mention something.
Serial mice aren't all the same. Older 80s era models may use 1200 Baud (Genius?), while newer models use 4800 to 115200 Baud.
It also depends on the mouse resolution/sensitivity.
Some mice drivers can be configured to be more speedy.

Edit: I don't mean to sound like a nitpicker, whatsoever.
These are just considerations that come to mind.
I admit I'm a layman when it comes to mice. 🤷‍♂️

Jo22 wrote on 2024-02-02, 11:52:

Not necessarily needed, true. The 16550 does cause fewer interrupts, though. It's less annoying, so to say. ;) […]
Show full quote

Not necessarily needed, true. The 16550 does cause fewer interrupts, though.
It's less annoying, so to say. 😉

So it's always a good idea to retire a 16450.
Back in the 90s, it was a common recommendation in PC magazines to replace it.

Many multi i/o cards have the DIP/DIL version soldered, so a socket for an 16550A/AF/AFN can be easy installed.

WfW 3.11 can use the FiFo natively, there is a setting in system.ini.

Edit: More modern ISA modems usually had an 16550 installed.
Merely the fax modems and lower speed modems for Minitel/BTX had an 16450.

Which was mainly money-related, I think.
Companies assumed this was good enough, especially since DOS was single-tasked and that no buffering was being required.

Because otherwise, it makes no sense.
The 16550 had been superseded that 16450 in the 80s already.
The 16450 is barely better than an 8250 dinosaur.

Edit: I forgot to mention something.
Serial mice aren't all the same. Older 80s era models may use 1200 Baud (Genius?), while newer models use 4800 to 115200 Baud.
It also depends on the mouse resolution/sensitivity.
Some mice drivers can be configured to be more speedy.

Edit: I don't mean to sound like a nitpicker, whatsoever.
These are just considerations that come to mind.
I admit I'm a layman when it comes to mice. 🤷‍♂️

The 16550 just may help to buffer mouse input, if driven with active FIFO and interrupt still per byte.
And, except there would exist any driver that supports this setting, there will be no difference with mice at all to a 16450 or 8250.
And which system has such an response time to interrupts occuring every ~ 80 ms at 1200 baud?

For standard usage even a 8250 is good enough.
A 16450 won't make it better than a 8250 because its improvements are in speeds above 38400 (57600 and 115200).

For modem and zero modem connections: Ok. Don't let us talk about 8250. 😀

"General Descriptiont

The Logitech MouseMan Bus Board is a single port, 16550 based
serial I/O board. It can be used in both 16 bit or 8 bit ISA
slots (though IRQ channels above 7 will not be available when
the board is installed in an 8 bit slot).

The board supports two hardware configuration modes: Automatic
mode, and Legacy mode. The board is set to Automatic mode when
shipped.

In Automatic mode, the boards resources will generally be
configured by the BIOS or operating system without user
intervention.

In Legacy mode, the board supports the four standard comport
addresses and numerous IRQs. These are software configurable as
described in the Software Configuration Utility section below.
You can set the card to legacy mode if you need to configure
the cards resources so they will not be altered by a Plug and
Play BIOS."

http://www.vogonsdrivers.com/getfile.php?fileid=702

😝

So, after some measurements on the mouse that is "detected" sometimes randomly (windows displays a cursor), but doesn't move.

First of all, the order of the connector on the mouse, I disconnected it for the measurements:

The connector on the other side:

The measurements. Cable resistance varies from 2 to 12.7 Ohms, I was expecting the same everywhere.
The the voltages, measured from a GND on a Molex connector, to the end of the connector (at the mouse, still disconnected)

If looking at https://www.cable-tester.com/rs232-pin-out/
Pin 1 = TXD (Transmit Data)
Pin 2 = RTS (Request to Send
Pin 3 = RXD (Recieve Data)
Pin 4 = GND (Ground)

And for reference, the underside of the PCB:

Except the somewhat low voltages on TXD and RTS (expecting 12V) I can't see anything particularly special at this point. But that's probably just because I'm measuring DC on pins which transmit a changing signal.

For a normal cable resistance value, those values are a bit too high. your cable is suspect.
From my own experience, where the cable enters the mouse tends to be prone to cable breakage, that or the connector side. The two places were the cables tends to be bent and stretched in a 90° angle.

I recently recovered a broken microsoft mouse (made by mitsumi) and compared the resistance values for that one with yours and all resistance values are less than 1 ohm.
The pins on the serial connector are the same.

edit: try measuring the resistance while playing/bending the cable at those points mentioned.

Please everyone make sure that the battery in the multimeter is fresh.
If it's depleted, the reported numbers might be a bit off from reality.