rasz_pl wrote on 2024-06-25, 07:36:

judging by the results MS Mouse 9.01 is also talking to PS/2 controller directly like CuteMouse 2.0a4, so no difference in the end

No, it is not. It uses the BIOS in 1 packet mode.

ahyeadude wrote on 2024-06-25, 01:14:

I was a big fan of CuteMouse, but after seeing the performance impact

Likely making CuteMouse use 1 packet will speedup in your system significantly, too, having the best of both worlds. CuteMouse is normally ridiculously speedy...

I really doubt this is something intrinsic to the mouse driver, rather just a poor BIOS that sleeps too much for packet synchronization.

I don't know what extra compatibility is gained if you use the BIOS rather than the PS/2 controller directly, but consider
A) MS always uses the BIOS even up to 9x (yes, even with a virtualized PS/2 controller).
and B) cutemouse guys got bitten by it and went back to using PS/2 BIOS.
I used to think this was to support "legacy USB" (i.e. BIOS support for MS mouses) but I have since realized that on most systems this is implemented by trapping the PS/2 IO ports directly with SMM rather than with BIOS code, so that can't be (and besides, it would be too much foresight...).

i found that with ms mouse 11 (or maybe already 9.x, didn't check), compared to 8.20, strangely they removed the /Px acceleration settings from the /? list. but in the mouse.lan file it still lists the corresponding profiles, and the driver seems to accept /p4. by the way, all of these drivers have interrupt rate settings - that may be something to look into for performance comparisons. the documentation is lacking in terms of what is default here (or rather, there is no seperate documentation on the image that's out there).

the file got quite a bit bigger compared to the 8.20 mouse.com i have though - 107kb vs. 36.7kb, and it will complain if there is no mouse.lan file in the same directory. don't get why it's packed with win95 .dlls either. and it seems even version 11 won't allow to fully unload the driver, making comparisons a bit annoying.

Thank you for this topic, I didn't know, I actually tested cutemouse with my Slot 1 build and it slows down quite noticeably, quake benchmark in 320 drops from 109,5 fps to 88.
I switched to microsoft drivers and the difference is much less noticeable, I do have a question though, I use a optical mouse with wheel but even if enabled on cutemouse I noticed that edit from dos 7.1 it doesn't work, I suppose that the program needs to support the wheel feature too other than the drivers?

think i've now noticed a speedup when comparing ms mouse 11 to 8.20 in games myself. so it may be a worthwile upgrade indeed, though i still find it annoying that supported commands would be removed from the list. maybe they ran into a limit in terms of how much text it could output.

and programs definitely need to support the wheel, not just in DOS, older win95 era games won't have any clue about it either.

auron wrote on 2024-10-16, 08:30:

think i've now noticed a speedup when comparing ms mouse 11 to 8.20 in games myself. so it may be a worthwile upgrade indeed, though i still find it annoying that supported commands would be removed from the list. maybe they ran into a limit in terms of how much text it could output.

and programs definitely need to support the wheel, not just in DOS, older win95 era games won't have any clue about it either.

Thank you, in this case I can happily switch to microsoft driver.

Edit: I did the same test on my Amd 5x86 build, with cute mouse when moving the cursor the performance drops to the performance of an dx2 66, with microsoft driver there is almost no difference.
Another build switched then... Later I will try other builds.

Tried the pentium 4 3.06ghz:
Quake 320:
No mouse movement: 93 fps
Cutemouse 2.1: 91,6 fps
Microsoft mouse 9.01: 92,6 fps

So I decided to give some tests with the same optical mouse 2 buttons + wheel, tests made on nssi with cpu benchmark, numbers in brackets are the kb of memory used:

Amd 5x86 133:
No mouse: 63088
CTMOUSE20: 62000 (3552)
CTMOUSE21: 43500 (3104)
DRMOUSE: 49735 (6544)
MOUSE: 62000 (24560)

According to those tests, the performance of ctmouse2.0 and microsoft mouse are the same, what changes is the memory foot print (huge on microsoft drivers), the dr mouse dr-dos is just meh...

upon further testing, as in something that isn't an FPS game, it was clear immediately that my concerns with ms mouse 11 were warranted - even though it appears to accept the /p4 switch, it doesn't do anything. so for whatever reason they really did take out the option to switch off acceleration, unless there is some other hidden way to do it.

then went to ms mouse 9.01, and that one comes with a useful GUI tool which shows that here, switching off acceleration is still possible. the problem with this one is, after about 3 minutes of gameplay, intermittent multi-second freezes happen, and eventually the mouse completely stops working until a reboot. this happened three times, though on the third time it also locked up the system as well. so it looks like this driver is not compatible with my logitech M-SBF96 mouse, unless there is a setting to change, but i didn't bother with that so far.

What about the Logitech mouse driver?
It supports cloaking in later versions and thus requires just 1 KB of conventional memory for its stub.

Re: Can I skip Smartdrive?

Edit: Back in the 90s I had used a Genius mouse and gmouse.com..
Another vintage driver I've used to use was MS Mouse 6.24BZ.
It was very Windows 2.03 friendly, it didn't mess up the native Windows mouse driver.

PS: Uwe Sieber's site has a bunch of old mouse drivers..
https://www.uwe-sieber.de/util_e.html

I never liked ctmouse, neither for its compatibility nor its cursor behavior (has a certain acceleration profile that I utterly hate).

MS Mouse is a great driver, and GMouse.com was the golden standard back in the 386 days.
I'd imagine the slowdowns mentioned here would have been detected by PC Magazine or any other lab if it was really noticeable. Mouse games and Windows 3.1 were all over the place, and a 50% slowdown wouldn't have gone unnoticed. Sierra games ran on potatoes and mouse movement never seemed to cause any slowdowns even on a 286 running SQ4 VGA.

I personally prefer using the mouse's manufacturer's driver. GMouse for Genius, MS Mouse for Microsoft, and LMouse for Logitech. I wouldn't bother with other mouse brands generally.

Jo22 wrote on 2024-10-19, 04:47:

What about the Logitech mouse driver? It supports cloaking in later versions and thus requires just 1 KB of conventional memory […]
Show full quote

What about the Logitech mouse driver?
It supports cloaking in later versions and thus requires just 1 KB of conventional memory for its stub.

Re: Can I skip Smartdrive?

Edit: Back in the 90s I had used a Genius mouse and gmouse.com..
Another vintage driver I've used to use was MS Mouse 6.24BZ.
It was very Windows 2.03 friendly, it didn't mess up the native Windows mouse driver.

PS: Uwe Sieber's site has a bunch of old mouse drivers..
https://www.uwe-sieber.de/util_e.html

thanks, have tested logitech 6.50 and 7.30. they both do allow to switch off acceleration and have quite a few options in general. with 7.30 i've noticed however that in doom, with this driver i'm getting a lot of extra hitches. apparently, this 1997 driver is quite heavy.

with 6.50 from 1995, things are better and i'd have to compare a few times to see if there are really extra hitches compared to ms 8.20. one thing with both logitech drivers though is, it seems the adjustable sensitivity range is smaller than with the microsoft driver. s10 with logitech seemed less sensitive than h80 with ms 8.20. that's really just relevant with acceleration off, but there might be some edge case game where the extra range would help.

with the same system i've also run some quick benchmarks with 3dbench2 as in this post. hardware is a p90 with neptune chipset and a matrox millennium. also, acceleration was disabled with every driver:

baseline (no drivers loaded): 79.5
ms mouse 8.20: 79.3
logitech 6.50: 78.7
logitech 7.30: 78.7

so oddly the two drivers show identical numbers here despite quite different results in practice. the 1997 driver must be doing something else that interferes with demanding games. and the logitech both bench slower than even the old ms 8.20, which was benched in this thread to be slower than the later ones. i'm wondering why the logitech drivers even report a VGA being present - doesn't seem like something that should concern a mouse driver, or maybe it does, given all the options with blinking cursors and such.

Well not everything is perfect. I'm having issues with the microsoft mouse drivers and jemmex, if I use the old good emm386 it gets all loaded into umb, while if I use jemmex it stays or in conventional memory or not completely load into umb. Sure cute mouse doesn't suffer from this problem due to the very low memory footprint compared to microsoft driver.
As for performance wise the difference is clearly noticeable, what may avoid noticing it it's that you need to move the mouse every moment because the gap just stop as soon the mouse is not moving.

Unlucky I need to add another con to microsoft mouse driver 9.01. When I use it on my pentium 4 build it makes the computer crash with memory errors.

Just FYI, the 50%+ slowdown with ctmouse 2.1 on PS/2 mice is real. I have an ASUS P3B-F with a celeron @ 1.4GHz and a V5 6000 zxc64 clone and with my QDOS, Q2DOS and DKDOS ports I noticed that just moving the mouse around dropped the frame in half in some places. I actually added code in those games to set the PS/2 sampling rate directly. Setting it to 10-20hz made a huge difference but did not eliminate it. Since I have FPS counters in these games it's really easy to see the drop. For DKDOS it's very CPU heavy and requires a Voodoo 3 minimum for playing. It's very obvious in this game since framerates are not exceptionally high.

Different PS/2 mice made it worse. I noticed the Mouse-Trak systems industrial trackball worked the best, and could do 200hz with minimal CPU usage on ctmouse 2.1, but it's not as accurate.

I have not test ctmouse 2.0 but just found out about this thread so I will try it today. I do have MS mouse driver but never thought to try it. I have the logitech one, and I vaguely remember trying that driver to check CPU usage and it seemed to make no difference, but I can test it again.

Tested ctmouse 2.0. It fixes the issue, but there is one caveat: if you have mouse wheel it will detect it and it will work fine for one session of a Quake engine game and then the next time it will be silly. You have to run ctmouse again (does not need to be unloaded) to reset whatever it does not like.

I did test Logitech's mouse driver v8.50. It DOES work if you set PS2Synchronization=On in the [Technical] area of mousedrv.ini.

I'm attaching the driver with the INI. I'm also hosting it at https://dk.toastednet.org/vogons/dos/LHMOUSE_850_PS2_HW.zip in case the attachment goofs up or whatever. This has no acceleration. I actually say this is better than ctmouse if you got enough RAM configured properly to run it. With no acceleration it's practically the same as using raw input on the desktop. I'll never use ctmouse again unless it's necessary for some game.

I'm not advertising my ports to get you to use them, however if you are trying to play Q1 or Q2 with a PS/2 mouse under DOS I highly recommend it as I have added special CVARs for fine tuning the sample rate and resolution per mm. I found this by just looking at the ralf brown's interrupt list. You may be surprised to notice that when loading the game it's always set to 100hz by default. On slower machines you can lower it further to save some CPU time or go up to 200hz and have 140hz refresh rate on your monitor for smoothness.

https://dk.toastednet.org/QDOS
https://dk.toastednet.org/Q2DOS

wbahnassi wrote on 2024-10-19, 07:42:

I never liked ctmouse, neither for its compatibility nor its cursor behavior (has a certain acceleration profile that I utterly hate).

Cutemouse has no acceleration at all?

I think this thread is a bit unfair to Cutemouse -- I suspect above the issue is likely in the BIOS, maybe only when used in 3 packet mode (this changed around MS Mouse 8 I think where they started using 1 packet mode).
I rather doubt ridiculously optimized Cutemouse is "slow" by any definition.

EDIT: Actually as per this very thread no need to suspect at all, the issue is exactly that:

AvalonH wrote on 2019-03-09, 20:32:

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.

It is not just 1-byte packet sizes. Cutemouse v2.0 uses direct hardware instead of the BIOS and it functions the same. There is clearly some sort of acceleration going on with cutemouse. Run logitech mouse and microsoft mouse and compare to cutemouse. It was also mentioned earlier in this thread.

Maraakate wrote on 2026-09-30, 22:31:

It is not just 1-byte packet sizes. Cutemouse v2.0 uses direct hardware instead of the BIOS and it functions the same. T

What do you mean "It is not just 1-byte packet sizes"? Every result in this thread, even your previous post, has so far agreed with this theory?

Maraakate wrote on 2026-09-30, 16:44:

Tested ctmouse 2.0. It fixes the issue

Maraakate wrote on 2026-09-30, 22:31:

There is clearly some sort of acceleration going on with cutemouse. Run logitech mouse and microsoft mouse and compare to cutemouse. It was also mentioned earlier in this thread.

Certainly there is a difference because precisely Cutemouse does no acceleration 😀

I found no code for acceleration whatsoever in Cutemouse. Even the simpler algorithm for the "double speed threshold" from MS Mouse 6.x times is commented out.

Note I may be overly picky, as acceleration for me has a very clearly defined meaning:
Acceleration means that the speed is NOT constant , i.e. if you move physically the mouse 10 millimeters in 10 seconds, it will move X pixels. But if you move it 10 millimeters in 1 millisecond, it will move more than X pixels .
Without acceleration, in both cases it moves the same distance.
Cutemouse only applies constant factors https://github.com/FDOS/mouse/blob/dd268521dc … mouse.asm#L1010 , one coming from the sensitivity setting and one coming from the mickeysPerX/Y (both are settable via int33, i.e. from a program). So it can't possibly do any acceleration.

If you dislike the default speed from Cutemouse, you can tune it (the command line has an argument for it).

Anecdotally I spent this last weekend trying to figure out what the hell the "sensitivity " slider does in the MS Mouse 8 / 9 drivers.
Here are my notes on it -- https://git.javispedro.com/cgit/vbados.git/tree/int33.h#n117
Since MS did not publish the actual formula to map this "sensitivity" value into an actual speed (in mm/second or whatever), it appears each driver does its own guess. I made my own approximation at https://git.javispedro.com/cgit/vbados.git/tr … /mousetsr.c#n63
But as you can see it is still a "constant" coefficient -- no acceleration. The sensitivity does not change over time.

The acceleration in MS Mouse seems to work in a different way.
In MS Mouse 6 there was a very simplistic acceleration mechanism (called the double speed threshold), where upon if you move the mouse more than 64 "mickeys" per second it will start doubling the speed.
But it seems that at least from MS Mouse 8 onwards they disabled this and instead switched to "proper" acceleration curves, which is what you can change in mouse.ini and/or select using the panel program.

CuteMouse definitely has merits: super small, wheel-as-middle-button.. but unfortunately it made my blood boil with how it responds.. particularly in games that require pixel hunting like Island of Dr.Brain and Lemmings 2. You try to nudge one pixel, but CuteMouse resists that nudge until you make a bigger movement on the physical device, making you lose accuracy and precision. Other classical drivers don't do that (e.g. GMouse.com).

I don't know if this is "acceleration" or "filtering" or God knows what... but this behavior definitely was apparent.

I'm a bit dissappointed that the devs of CuteMouse are seemingly so, -pardon my words-, conservative.

Instead of using minimalistic code, they could consider writing a more sophisticated mouse driver that's smooth, intelligent and very compatible.

Something like Logitech mouse driver.
Something that uses Cloaking technology or DPMS (no typo).

Because by writing a proper 64 KB mouse driver that resides in extended mode could solve many issues.

Alternatively, it would be possible to try to experiment with EMS.
If there's a physical EMS hardware involved, the switch could be very fast with low CPU overhead.

Edit: No offense, but I'm a bit dissappointed with modern DOS development.
Back in early 90s, everything was somewhat more ambitious.

There was Novell DOS 7 and the Star Trek project,
or Helix Headroom v3 which used virtual machines to outsource large network software and drivers.

Then there was the draft for the Windows 3.0 386 protected mode extender, which basically implemented a 32-Bit Protected Mode implementation of int21h API.
It went much further than DPMI did, it was a 32-Bit DOS implementation, basically.

When I read news about FreeDOS, I wonder when the contributors will introduce 64-Bit extenders or make use of MMX, SSE and other modern techniques in certain applications and tools.

I don't have the right to demand for anything, of course,
but I always silenty hope that DOS development would continue to elvolve into the future.
And that there will be optimized binaries for modern PCs, as well.

I mean, let's take the PCIe serial/parallel ports with their native modes that surpass 90s era hardware.
There could be modern DOS drivers that would at least provide DOS API level access even if they ports are not in ISA address space.
More focus on implementing the FOSSIL interface standard would be nice, too.

wbahnassi wrote on 2026-09-30, 22:59:

CuteMouse definitely has merits: super small, wheel-as-middle-button.. but unfortunately it made my blood boil with how it responds.. particularly in games that require pixel hunting like Island of Dr.Brain and Lemmings 2. You try to nudge one pixel, but CuteMouse resists that nudge until you make a bigger movement on the physical device, making you lose accuracy and precision. Other classical drivers don't do that (e.g. GMouse.com).

I don't know if this is "acceleration" or "filtering" or God knows what... but this behavior definitely was apparent.

I have to use CuteMouse 2.0a4 to bypass instability with the BIOS PS/2 routines on my mainboard and experience this behaviour as well. The sensitivity settings seem to shift the speed/acceleration threshold around but never make it go away. On my system the difference between slow and fast mouse input is fairly large and makes playing first person shooters more difficult than it should be. The mouse responds normally in win 3.11 and win9x.

Even if CuteMouse itself isn't adding any acceleration, however it interacts with the hardware seems to result in it anyway.

It seems that even if it's not accelerating, it's decelerating for small movement instead.

javispedro1 wrote on 2026-09-30, 22:57:

What do you mean "It is not just 1-byte packet sizes"? Every result in this thread, even your previous post, has so far agreed w […]
Show full quote

Maraakate wrote on 2026-09-30, 22:31:

It is not just 1-byte packet sizes. Cutemouse v2.0 uses direct hardware instead of the BIOS and it functions the same. T

What do you mean "It is not just 1-byte packet sizes"? Every result in this thread, even your previous post, has so far agreed with this theory?

Maraakate wrote on 2026-09-30, 16:44:

Tested ctmouse 2.0. It fixes the issue

---

Maraakate wrote on 2026-09-30, 22:31:

There is clearly some sort of acceleration going on with cutemouse. Run logitech mouse and microsoft mouse and compare to cutemouse. It was also mentioned earlier in this thread.

Certainly there is a difference because precisely Cutemouse does no acceleration 😀

I found no code for acceleration whatsoever in Cutemouse. Even the simpler algorithm for the "double speed threshold" from MS Mouse 6.x times is commented out.

Note I may be overly picky, as acceleration for me has a very clearly defined meaning:
Acceleration means that the speed is NOT constant , i.e. if you move physically the mouse 10 millimeters in 10 seconds, it will move X pixels. But if you move it 10 millimeters in 1 millisecond, it will move more than X pixels .
Without acceleration, in both cases it moves the same distance.
Cutemouse only applies constant factors https://github.com/FDOS/mouse/blob/dd268521dc … mouse.asm#L1010 , one coming from the sensitivity setting and one coming from the mickeysPerX/Y (both are settable via int33, i.e. from a program). So it can't possibly do any acceleration.

If you dislike the default speed from Cutemouse, you can tune it (the command line has an argument for it).

Anecdotally I spent this last weekend trying to figure out what the hell the "sensitivity " slider does in the MS Mouse 8 / 9 drivers.
Here are my notes on it -- https://git.javispedro.com/cgit/vbados.git/tree/int33.h#n117
Since MS did not publish the actual formula to map this "sensitivity" value into an actual speed (in mm/second or whatever), it appears each driver does its own guess. I made my own approximation at https://git.javispedro.com/cgit/vbados.git/tr … /mousetsr.c#n63
But as you can see it is still a "constant" coefficient -- no acceleration. The sensitivity does not change over time.

The acceleration in MS Mouse seems to work in a different way.
In MS Mouse 6 there was a very simplistic acceleration mechanism (called the double speed threshold), where upon if you move the mouse more than 64 "mickeys" per second it will start doubling the speed.
But it seems that at least from MS Mouse 8 onwards they disabled this and instead switched to "proper" acceleration curves, which is what you can change in mouse.ini and/or select using the panel program.

I know how to read documentation and use command line arguments. Cutemouse does something that is not the same as other mouse drivers. It was mentioned in other posts below yours, but it just flies around all over the place. It's very similar to when you have mouse acceleration turned on in Windows. Even with /R00 and friends (which youd have to bump up sensitivity in a game to max) it's silly.

I am not slamming the devs. I am a developer myself. It is hard to write good software that is reliable. Cutemouse does well for a number of people, but it appears to have some limitations for certain motherboard configurations with PS/2 mice. It also seems to be very inaccurate and hard to use for games where precision is very important.

You're taking it very personally. If this driver does everything for you then keep using it. Nobody is forcing you to use a different mouse driver. Good thing you can pick and choose one easily under DOS.