Yup.... I think it is normal. Well. It is normal to me, that the CPU will throttle down, when moving the mouse. I have seen it for the first time, way back in the late 80's on 286's and through the first half of the 90's on Dos. And even as new as P4-WinXP machines. I saw it in 1994 as well, when I was one of them that ran beta, alpha and test releases of Windows95. Opening the performance monitor in Win9x onl to see how much I was able to make the CPU work, by the use of a mouse only, was actually something I would do, whenever I was too bored to do anything else.

To make it short. I have seen it from 286's to Pentium4's. From Dos to WinXP.

It's also because of the use of interrupts. Some ports use more of them than others (USB vs. PS/2 vs. V.24).
Especially in old pre-586 systems, old serial UARTs were the culprit. Gratefuly, they can be replaced.
See https://www.tldp.org/HOWTO/Serial-HOWTO-18.html, http://www.byterunner.com/why.html

It might be a good idea to do it on Win98 systems, yet USB mice tends to work good enough on Win98 systems. For MS Dos 6.22 systems, then you are not really using any software that have slowdown in the gameplay, when using the mouse. You know. Civilization, Cannon Fodder, Monkey Island and games like that never have issues with slowdown. Heck. Even an 1987 optical serial port mouse does not slow down the gameplay in Monkey island or Civilization, if you are playing on a 286 with EGA gfx and 640k Ram. I shure did not feel any difference back in 1987/88.

My point is. Shure the mouse slows down the machine, yet do you actually feel anything in the actual gaming experience, when using MS Dos 6.22?

AvalonH, this problem does exist (although not to the extent of dropping literally half the performance, so your particular issue might also be a hardware one), and the culprit is the mouse driver. Try this one from the MS Intellipoint 2.2 driver package. On my P3 system it completely eliminated the annoying performance drop in DOS applications when moving the cursor (especially with the CPU throttled down and with cache disabled).

Just to be clear, the problem doesn't happen in Win9x, only in DOS (both 6.22 and 7.1). I wonder how common this problem is/was back in the day in DOS. Maybe people simply didn't notice it and just thought they needed a faster PC.

After spending a lot of time the problem was indeed the mouse driver.
Every mouse driver (I tested over 25) bar Microsoft's mouse driver (ver 9 and newer) slowed down the CPU by 30-50% just by moving the mouse around. Quake would half in speed when moving the mouse, same with doom and even non graphic dos text benchmarks.
The best drivers recommended on vogons due to small memory footprint all had the same bug.
CuteMouse 1.9.1 to v2.1 beta 4 (uses int 10h, 33h)
Logitech v7.3
PhysTechSoft v1.16
QTRONIX MOUSE Version 3.02a
Microsoft Mouse Driver v7 (1989)
Microsoft Mouse driver v8

The fix was to use Microsoft’s Mouse driver (only versions 9 and newer worked). Downside is they take around 20-25kb memory in DOS. With this driver installed I can move the mouse around in a Dos benchmark like NSSI or Quake and Doom and now there is no slow down. It has less than 1% effect on the CPU Speed.
It seems most DOS mouse drivers are not 100% compatible as MS Mouse driver v9-11 and they can cause this slowdown on certain Bios/motherboard combinations. Probably a rare occurrence but one to be aware of with older boards. I tried testing the various options of the MS Mouse driver (disable hardware cursor, change Interrupt rate etc) to recreate the slowdown with no success. MS Mouse driver regardless of options doesn't cause any slowdown, whereas every other 25+ mouse drivers I tested did.

Another interesting bug I came across when using this motherboard (MSI6156 BX) and 2 other Asus 440ZX motherboards was pressing multiple keys quickly caused the CPU in any DOS program to slow down massively.
Multiple keyboard combos and holding keys in Quake etc slowed down the frame rate to a slide show.
Again I spent a lot of time on it and found the cause; ironically it was a Microsoft driver this time, the KEYB TSR used to load keyboard.sys localization. Skipping the loading of this caused no slowdown when pressing/holding multiple keys in benchmarks and games like Quake.
To keep keyboard localization the fix was to use Freedos' KEYB or MKEYB. With either of these loaded there was is no cpu slowdown when pressing multiple keys in Quake, doom etc. Also they take up around 3-4kb less memory than Microsoft’s KEYB. Again I wonder how common this is/was in the past but unnoticed because it is obscure.

It is normal for performance to drop a tad when for example a serial mouse sharing an interrupt is being moved.
Albeit the drop in performance should be around anything up to 10 percent maximum (with old processors like for example a 386-SX20, it will be almost 10% the performance.) The faster the processor, the more minuscule the amount gets. 50 percent sound like a hardware issue to me.

Highly interesting analysis!
It is about 30 years ago now, and I still remember how often I was asked why the computer got so sluggish/jerky with the mouse.

Remember, there were literally thousands of proprietary mouse drivers, even when the mice claimed full MS compatibility.
For this reason I kept a collection of known-good drivers, not only for mice, but for example Tseng VGAs, too, just to avoid installing a random driver of random quality. It was often fun to explain to users why I didn't bother to touch the driver diskettes delivered with mouse, vga etc.

keyb had also issues from the beginning. And that not only regarded the big memory footprint. For this reason I used DOS 2.11 keybgr.com on DOS 3 and up to get german layout. It did not need specify a country file etc, and worked just fine, although the resident TSR size was just a small fraction of what keyb+keyboard.sys consumed.

Reminds me of a problem with a cheap old computer I used to have, where moving the serial mouse while using the parallel port (e.g. scanning a document) would cause Windows to bluescreen.

Even on my P2-300, moving the (PS/2) mouse only uses 1% of the CPU, and that's under Win2000.

AvalonH wrote:

Just to be clear, the problem doesn't happen in Win9x, only in DOS (both 6.22 and 7.1). I wonder how common this problem The bes […]
Show full quote

Just to be clear, the problem doesn't happen in Win9x, only in DOS (both 6.22 and 7.1). I wonder how common this problem The best drivers recommended on vogons due to small memory footprint all had the same bug.
CuteMouse 1.9.1 to v2.1 beta 4 (uses int 10h, 33h)
Logitech v7.3
PhysTechSoft v1.16
QTRONIX MOUSE Version 3.02a

MSI OEM board with 440BX chipset, and VIA southbridge 😮 ? EDIT: nope, MSI just sold whatever was cheapest that week under same designation


and was also sold with 440ZX, because MSI oem 😀 probably for some low low budged supermarket chain (think Medion branded).
Its safe to assume its the motherboard problem, bios assigning interrupts in a wrong way or something.

On my cheap as chips Asus X540sa ( about 2016 ) laptop the touchpad utility used to load the cpu up to 100% when doing processor intensive tasks like scrolling a web page or clicking on something , so it's nice to see that the art of writing shit drivers for input devices is an ancient and honored tradition.

rasz_pl wrote:

MSI OEM board with 440BX chipset, and VIA southbridge 😮 ? EDIT: nope, MSI just sold whatever was cheapest that week under same designation

and was also sold with 440ZX, because MSI oem 😀 probably for some low low budged supermarket chain (think Medion branded).
Its safe to assume its the motherboard problem, bios assigning interrupts in a wrong way or something.

Yeah, I have read that the VIA southbridge version of the MS6156 is a bit flaky, but the board I have is the less common 440BX version. It is a solid board apart from the mouse issue in DOS. Very stable, been using it for years.

In testing my other old boards, I found the exact same problem on two Asus p2Z-VM, a 440ZX motherboard. Different chipset. In DOS with this board when I move the mouse around while running a benchmark or game it slows the CPU anywhere from 25-50%. All mouse drivers I have tested do this this apart from Microsoft Mouse version 9 (1993) and newer. MS Mouse version 8 and below cause the same heavy CPU usage.
So two boards from two different manufacturers with this exact same problem, both fixed when using MS mouse driver 9+.

Again I don't know how common this was in DOS in the past because I doubt many would have picked it up. In Win9x with the default MS mouse driver they both work fine, less than a 1% slowdown when moving the mouse running a becnhmark/game. This is only a DOS problem which probably affects more motherboards.

It's easy to test for this problem. Do a clean boot in DOS, load Cutemouse and then run NSSI, select one of the benchmakrs from the menu and then continuously move the mouse. It should only slow down by around 1-2% if there is no problem (most motherboards). Motherboards with this issue show a CPU slowdown or around 25% and more.

Found out Microsoft Mouse version 9 and newer driver in DOS uses 1-byte packet sizes. It fixes the slowdown problem.
Ctmouse and the other drivers I tested use the standard 3 byte mouse data packets and cause heavy CPU usage and slowdown when moving the mouse on this board in DOS.

AvalonH wrote:

Found out Microsoft Mouse version 9 and newer driver in DOS uses 1-byte packet sizes. It fixes the slowdown problem.
Ctmouse and the other drivers I tested use the standard 3 byte mouse data packets and cause heavy CPU usage and slowdown when moving the mouse on this board in DOS.

what do you mean? PS2 mice can send either 3 or 4 byte packets.

rasz_pl wrote:

AvalonH wrote:

Found out Microsoft Mouse version 9 and newer driver in DOS uses 1-byte packet sizes. It fixes the slowdown problem.
Ctmouse and the other drivers I tested use the standard 3 byte mouse data packets and cause heavy CPU usage and slowdown when moving the mouse on this board in DOS.

what do you mean? PS2 mice can send either 3 or 4 byte packets.

For some reason, MS stopped using standard packet size from Microsoft Mouse version 9 (1993 and newer up to version 11). It uses 1 byte instead. I have been searching and reading old USENET posts about this.
I'd like to know why MS changed this because it fixes the high CPU utilization just by moving PS2 mouse in these boards.
I also managed to find an old serial port mouse and tested it in the MSI and ASUS boards running cute-mouse and MS mouse driver ver 9. There was negligible slowdown (less than 1-2%) when moving the mouse in benchmarks and games, both drivers performed the same. Serial mouse is unaffected on these boards in dos. Only PS2 mouse slows down the CPU massively just by moving the mouse, and is fixed by using MS mouse dos driver 9 and newer.

AvalonH wrote:

rasz_pl wrote:

AvalonH wrote:

Found out Microsoft Mouse version 9 and newer driver in DOS uses 1-byte packet sizes. It fixes the slowdown problem.
Ctmouse and the other drivers I tested use the standard 3 byte mouse data packets and cause heavy CPU usage and slowdown when moving the mouse on this board in DOS.

what do you mean? PS2 mice can send either 3 or 4 byte packets.

For some reason, MS stopped using standard packet size from Microsoft Mouse version 9 (1993 and newer up to version 11). It uses 1 byte instead. I have been searching and reading old USENET posts about this.

can you give an example link? how would you even send 3 bytes of information in 1 byte? PS2 mouse communication is standardized, afaik there is no 1 byte mode. https://www.win.tue.nl/~aeb/linux/kbd/scancodes-13.html

rasz_pl wrote:

can you give an example link? how would you even send 3 bytes of information in 1 byte? PS2 mouse communication is standardized, afaik there is no 1 byte mode.

I think what he means is that the serial data from the mouse is read bytewise, and the interrupt is released after reading every byte.
I.e. buffering the data and dispatching the actual mouse event only after receiving the full packet.
The former behavior seems to have been reading all 3-4 bytes in a go, without releasing the interrupt.

Now put this information together with the low serial data rate of the mouse and you'll understand why this change improved responsiveness of the system.
(For this reason some people hacked their mouse/driver to work with 19200 instead of 1200bps which is the default rate iirc)

retardware wrote:

(For this reason some people hacked their mouse/driver to work with 19200 instead of 1200bps which is the default rate iirc)

you might be thinking serial, PS2 is ~12Kbit/s

^Didn't have the PS/2 port got its own problems though ? 😉
https://web.archive.org/web/20131222093045/ht … m.com/wp/?p=892