1. the ps/2 mouse connector is attached to the keyboard controller so unless you can add the functionality to the existing keyboard controller in the mobo it will not work. also you may need to modify the bios because ps/2 mouse uses IRQ12 so that need to be reserved.

2. it is said that ps/2 doesn't have lag on mouses because of how it works. basically in ps/2 any key pressed or mouse movement will produce an Interrupt Request (IRQ) and so the system will do the corresponding action.
in usb, the system will be constantly checking if there are any changes in the state of the devices (such as movement, etc.)

auron wrote:

1. what's so special about ps/2 that it can't be just added to a PC without needing a driver? ISA i/o cards can add serial, parallel and game ports without needing any driver, but the only cards with ps/2 seem to be PCI cards that are basically USB devices needing a driver.

2. is there any advantage to using ps/2 mice over serial in terms of DPI or lag?

1. Of course PS/2 mice need a driver. In DOS you have to load it, in Windows 9x and following you may not notice that it loads it automatically. But PS/2 mouse ports are implemented in the main board's keyboard controller. So if the main board doesn't have PS/2 mouse it is nearly impossible to add it.

2. PS/2 mice are generally newer, so might have higher resolution. You are just talking about the interface in the end. PS/2 mouse port and PC UART (RS232 serial port) are similar technologies with similar capabilities. RS232 is much older and a general purpose interface PS/2 is dedicated for mouse and keyboard.

weldum wrote:

2. it is said that ps/2 doesn't have lag on mouses because of how it works. basically in ps/2 any key pressed or mouse movement will produce an Interrupt Request (IRQ) and so the system will do the corresponding action.
in usb, the system will be constantly checking if there are any changes in the state of the devices (such as movement, etc.)

Not sure this entirely correct. Yes the USB host controller is constantly polling the connected devices, but this is no problem. It has nothing else to do 😀 and if it finds something to transmit it triggers an interrupt of the main CPU. Constant polling would only be a problem if the main CPU would need to do it.

PS2 mice can be much more enjoyable by changing the refresh rate with ps2rate :
https://www.majorgeeks.com/files/details/ps2rate.html

Nobody mentioned the "optical" factor yet?

konc wrote:

Nobody mentioned the "optical" factor yet?

explain us please

weldum wrote:

explain us please

Nothing fancy, just answering to the 2nd question

auron wrote:

2. is there any advantage to using ps/2 mice over serial in terms of DPI or lag?

Although admittedly it has nothing to do with DPI or lag (well depends on how you interpret lag 🤣 ), ps/2 mice can be optical which is a significant feature for many.

The technology used for motion tracking (optical, opto-mechanical or purely mechanical i.e. a ball or wheels) is completely independend from the interface technology for the PC.

You can get optical mice with USB, PS/2 and serial connectors - and quite likely some other too if needed.

dionb wrote:

The technology used for motion tracking (optical, opto-mechanical or purely mechanical i.e. a ball or wheels) is completely independend from the interface technology for the PC.

Agree on this

dionb wrote:

You can get optical mice with USB, PS/2 and serial connectors - and quite likely some other too if needed.

...but disagree with that.
Serial port cannot provide the power an optical mouse needs, that's why they don't exist (using the common technology of optical mice, not some oddware requiring a special mouse pad). At least that's what I know, I'd be happy if you could show me some examples.

Of couse they exist. I used a serial optical mouse long, long time ago. It was simply running off two batteries (many early optical ps/2 mice did as well).

Also, the 'regular' ones with a mouse mat with a grill are still lightyears ahead of ball mice (so long as your wrists don't get too sweaty), and they are convincingly retro in looks & feel as well.

I had one of this kind on a Sun Station IPC !
1995 computer with 48 Mo ram, great on NetBSD 😀

realoldguy23 wrote:

1. Of course PS/2 mice need a driver. In DOS you have to load it, in Windows 9x and following you may not notice that it loads it automatically. But PS/2 mouse ports are implemented in the main board's keyboard controller. So if the main board doesn't have PS/2 mouse it is nearly impossible to add it.

i know that mice need drivers, i was really talking about the the interface itself (hence the mention of i/o cards). i suppose there are some technical reasons why they couldn't just slap one of those controllers on an ISA card to add PS/2 to any machine, so now we have to mess around with brackets and custom pinouts on AT formfactor boards that did support it. and sure, PS/2 mouseport needs IRQ 12, but that could be surely be just reserved by hand in the BIOS anyway in many cases?

and as for the second question, of course there are things like the Q500 optical mouse for serial, and i'd expect that thing to have lower latency than a ball mouse just by design, but i'd be more interested in a comparison of serial vs. ps/2 for the same type of mouse, like the microsoft serial 2.0 mouse vs. the same looking ps/2 variant. i think i've read claims about ps/2 performing better... ps2rate is certainly an advantage, could the polling rate also be improved for serial mice by messing with the serial port settings in windows device manager?

auron wrote:

and sure, PS/2 mouseport needs IRQ 12, but that could be surely be just reserved by hand in the BIOS anyway in many cases?

No it doesn't work like that. When the hardware reports a mouse event via IRQ12, the driver needs to get the data (i.e. mouse moved, button pressed) from the keyboard controller's I/O ports (0x60 and 0x64 IIRC) . And since each PC already has a keyboard controller which occupies these I/O ports, you can't just put an addon card in the system that provides a PS/2 mouse port. The result would simply be an I/O port conflict.