Jo22 wrote on 2021-08-02, 14:33:
PS: I wonder, maybe the MS InPort cards can be upgraded with a 16550A?
The UARTs 8250 and 16550A are for serial communication. The InPort mouse doesn't use serial communication at all, and I have no evidence that the original InPort card contains an UART at all.
You can find the pinout of the InPort mouse at https://deskthority.net/wiki/Bus_mouse#Microsoft_InPort . It shows that the cable from the mouse to the computer contains the raw sensor and button signals, not a serial data stream (as serial mice would). The counter that counts the pulses of the rotary encoders in the mouse is in the one chip on the microsoft InPort card, and the counter values can be directly read over the ISA bus, with no serial data stream in between.
The interrupt rate of a serial MS mouse is higher than the interrupt rate of a bus mouse: A serial mouse sends around 150 bytes / second, and every byte triggers an interrupt. Three bytes make a packet, so you get up to 50 updates / second. If the bochs emulation of the bus mouse is true to the original hardware and emulates a MS InPort-compatible card, only 30 interrupts / second are generated, and an update is available on every interrupt. The process of reading data from the bus port chip seems to need more I/O cycles than reading the serial data from an MS mouse.
So my verdict is: If the IRQ processsing overhead is the main limiting factor, the bus mouse is the clear winner (only 1/5th of the IRQ rate compared to serial mice). On the other hand, if ISA 8-bit cycles are the main limiting factor, the serial mouse might win out. The latter might be the case on fast x86 systems (high end 486, Pentium) without a memory manager like EMM386. On the other hand, I think the whole discussion is academic, because the real CPU load (at least in graphics modes) isn't caused by the communication protocol, but from re-drawing the mouse cursor. Redrawing the mouse cursor takes the same effort no matter how the position has been received. If serial MS mice make use of the technically possible 50 updates per second, and the driver redraws the cursor with every position update, the CPU load will be higher than with a bus mouse that only posts 30 updates per second to the mouse driver. If the mouse cursor is drawn in the main loop of the application at the screen refresh rate of the application instead of the update rate of the mouse, the mouse port type likely makes no difference at all.