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. https://www.win.tue.nl/~aeb/linux/kbd/scancodes-13.html

I just noticed this issue has been mentioned on the recent Dosbox commits
https://sourceforge.net/p/dosbox/code-0/commit_browser
under Dosbox commit r4191 it says:
Only standard 3-byte mouse data packets are supported, so return an error for other packet sizes. MS Mouse driver versions 9.X and later use 1-byte packets for some obscure reason, and now they won't load instead of messing up

The author was ripsaw8080 who posts in these forums, maybe he can clear up how MS mouse ver 9 and newer fixes this high CPU utilization on these motherboards.

AvalonH wrote:

I just noticed this issue has been mentioned on the recent Dosbox commits https://sourceforge.net/p/dosbox/code-0/commit_browser […]
Show full quote

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. https://www.win.tue.nl/~aeb/linux/kbd/scancodes-13.html

I just noticed this issue has been mentioned on the recent Dosbox commits
https://sourceforge.net/p/dosbox/code-0/commit_browser
under Dosbox commit r4191 it says:
Only standard 3-byte mouse data packets are supported, so return an error for other packet sizes. MS Mouse driver versions 9.X and later use 1-byte packets for some obscure reason, and now they won't load instead of messing up

The author was ripsaw8080 who posts in these forums, maybe he can clear up how MS mouse ver 9 and newer fixes this high CPU utilization on these motherboards.

ok, so after reading the commit it seems Microsoft driver is too lazy to interface hardware directly (like cutemouse in 2.0 branch does) and instead asks Bios(int 14 ax=C205 bh=1) to handle PS2 port communication, but generate interrupt on every byte instead of per data packet (3-4 bytes).

It still looks like broken bios, all 'int 14 ax=C205 bh=1' does is use BIOS for PS2 access, but skips BIOSes internal mouse decoding logic.
OP could test this by trying http://cutemouse.sourceforge.net/ V2.0 and V2.1 drivers.
2.0 doesnt use bios at all, trapping int12 directly and reading raw port 60h (PS2 controller)

rasz_pl wrote:

ok, so after reading the commit it seems Microsoft driver is too lazy to interface hardware directly (like cutemouse in 2.0 bran […]
Show full quote

ok, so after reading the commit it seems Microsoft driver is too lazy to interface hardware directly (like cutemouse in 2.0 branch does) and instead asks Bios(int 14 ax=C205 bh=1) to handle PS2 port communication, but generate interrupt on every byte instead of per data packet (3-4 bytes).

It still looks like broken bios, all 'int 14 ax=C205 bh=1' does is use BIOS for PS2 access, but skips BIOSes internal mouse decoding logic.
OP could test this by trying http://cutemouse.sourceforge.net/ V2.0 and V2.1 drivers.
2.0 doesnt use bios at all, trapping int12 directly and reading raw port 60h (PS2 controller)

Cute mouse 1.9.1 and the latest 2.1 b4 both slow down cpu when moving PS2 mouse.

Of all mouse drivers I tested I skipped Cutemouse 2.0 Alpha4 and went from 1.91 to the latest.
Anyway cutemouse 2.0A4 works (like MS mouse driver 9 and newer) there is no slowdown after loading it on both the MSI and ASUS motherboards.
Reading the Cutemouse differences in the branche releases again it says:
V1.9 branch uses BIOS to handle PS/2 mice.
V2.0 branch uses direct hardware access for PS/2 mice, and supports the wheel.
V2.1 branch uses BIOS to handle PS/2 mice but also supports the wheel.

So as you said it seems like a bios bug. The MSI 6156 has Award and AMI bios versions. I flashed between the latest of each one and the bug is in both Award 4.51PG) and AMI bios, which is strange. The Asus motherboard with the same mouse slowdown uses the newer Award Bios 6. So I don't know how common this bug is.
I wonder if Microsoft changed the driver in version 9 and newer to avoid problems like this with buggy bios.
Question is why would you use bios instead of direct hardware access for PS2 mouse.

AvalonH wrote:

I wonder if Microsoft changed the driver in version 9 and newer to avoid problems like this with buggy bios.

that would be my guess too, MS has a strong tradition of silently fixing/working around oem bugs, one of the more famous ones being Windows95 simcity compatibility patch https://www.osnews.com/story/8079/to-be-backw … -compatibility/

mixmax:
--------
The original version of Sim City was written for windows 3.x and included a bug that read memory that had been freed to the system. It worked in windows 3.x, even though it shouldn't, because that particular range of memory wasn't being used for anything else until the program was terminated.

In beta versions of windows 95 Sim City didn't work because the operating system allocated memory differently, and Sim City would crash as expected because of the bug in the program. Amazingly, in the final version of Win95 the original Sim City worked. Microsoft engineers had actually tested backwards compatibility with Sim city, located the bug, and worked around it in their sourcecode.
--------

AvalonH wrote:

Question is why would you use bios instead of direct hardware access for PS2 mouse.

PS2 has really kludgy programming interface, plus hardware got really complicated in the nineties, KBC was integrated into chipsets and EC(laptop), we got ACPI - old interfaces were dynamic(toggleable), often virtual/emulated (using ring -1/-2 SMM/-3 ME!).

All in all MSI simply didnt care about bios bugs affecting legacy, unsupported OSes in boards for the OEM market, often bottom of the barrel supermarket computers.

I noticed this issue for the first time today while recording some game music. It happened on two separate computers, one with an Abit KT7A motherboard (VIA KT133A chipset) and another with an Abit ZM6 motherboard (Intel 440ZX chipset).

It could be that some games exibit slowdowns more severely than others, but for me, this was most evident in Tyrian where the music slows down considerably as soon as you start moving the mouse. As suggested in this thread, I installed the Microsoft mouse driver from the Intellipoint package and that completely eliminated the issue.

Thinking back, I wondered why I didn't spot this before, but then I realized that I had been playing games mostly under the Win98 DOS prompt instead of in pure DOS. I'm still surprised that this issue isn't more widely known though. Kudos to all the people in this thread for documenting the problem so thoroughly and providing a solution.

Joseph_Joestar wrote on 2020-06-27, 13:20:

I noticed this issue for the first time today while recording some game music. It happened on two separate computers, one with an Abit KT7A motherboard (VIA KT133A chipset) and another with an Abit ZM6 motherboard (Intel 440ZX chipset).

It could be that some games exibit slowdowns more severely than others, but for me, this was most evident in Tyrian where the music slows down considerably as soon as you start moving the mouse. As suggested in this thread, I installed the Microsoft mouse driver from the Intellipoint package and that completely eliminated the issue.

Thinking back, I wondered why I didn't spot this before, but then I realized that I had been playing games mostly under the Win98 DOS prompt instead of in pure DOS. I'm still surprised that this issue isn't more widely known though. Kudos to all the people in this thread for documenting the problem so thoroughly and providing a solution.

Since I posted this last year I've also noticed it affects all of the modern motherboards I have, P965, P45, and Z370 chipsets .
Older 486 boards and early Pentium chipsets i own are not affected.
Most people don't use newer boards in real mode dos and a speed drop of 30% is less noticeable on 2Ghz+ cpus. MS Mouse driver 9.X (and newer) and the V2.0 branch of Ctmouse fix this bios issue with direct hardware access.

Another slowdown issue I came across was the keyboard buffer in dos games. This affects some motherboards and not others regardless of different keyboards used. In Quake, Doom etc. holding down a single key for too long, like a cursor key for movement would cause the keyboard buffer to overflow and beep, freezing the pc for a second. You can test this issue by using NSSI's cpu benchmark (the bar graphs display). Hold down any key and after 7-8 seconds the cpu will slowdown dramatically on some motherboards to 386 speeds. Loading FreeDOS Xkeyb fixes this on some motherboards.
Before I fixed the issues above, running Quake on a PII-300mhz while using the mouse to look around and pressing the cursor to move turned the game in to a slideshow.

AvalonH wrote on 2020-06-27, 16:57:

Loading FreeDOS Xkeyb instead of MS-Dos keyb.com fixes this on some motherboards.

Interesting, does this only affect people who use a regional keyboard layout? I.e. something other than English US.

I'm not too clear on when/how keyb.com is used.

Joseph_Joestar wrote on 2020-06-27, 17:11:

AvalonH wrote on 2020-06-27, 16:57:

Loading FreeDOS Xkeyb instead of MS-Dos keyb.com fixes this on some motherboards.

Interesting, does this only affect people who use a regional keyboard layout? I.e. something other than English US.

I'm not too clear on when/how keyb.com is used.

Yeah, Keyb is just used to configure a keyboard for a layout other than the standard US layout (codepage 437).
I wasn't too clear in the other post (I will change it), freezing after holding a key down for some seconds will happen regardless of loading keyb.com on some motherboards. Loading Xkeyb fixes it (modifies keyboard buffer). I should have been clear the issue has nothing to do with keyboard layouts it is caused by the keyboard buffer.
You can use NSSI CPU benchmark in realmode dos to check if it affects your motherboard. With one of the CPU benchmarks running, keep a key pressed and after a few seconds the benchmark will slow down dramatically. If it happens, try again after loading xkeyb and it should fix it.

AvalonH wrote on 2020-06-27, 18:04:

You can use NSSI CPU benchmark in realmode dos to check if it affects your motherboard. With one of the CPU benchmarks running, keep a key pressed and after a few seconds the benchmark will slow down dramatically. If it happens, try again after loading xkeyb and it should fix it.

Looks like both of my systems are thankfully unaffected by this issue. NSSI gave nearly identical scores whether a key was pressed or not.

To double check, I ran a few Quake time demos with and without a key pressed and the score was also the same (plus minus 1 frame) in both cases

rasz_pl wrote on 2019-03-11, 19:00:

that would be my guess too, MS has a strong tradition of silently fixing/working around oem bugs, one of the more famous ones be […]
Show full quote

AvalonH wrote:

I wonder if Microsoft changed the driver in version 9 and newer to avoid problems like this with buggy bios.

that would be my guess too, MS has a strong tradition of silently fixing/working around oem bugs, one of the more famous ones being Windows95 simcity compatibility patch https://www.osnews.com/story/8079/to-be-backw … -compatibility/

mixmax:
--------
The original version of Sim City was written for windows 3.x and included a bug that read memory that had been freed to the system. It worked in windows 3.x, even though it shouldn't, because that particular range of memory wasn't being used for anything else until the program was terminated.

In beta versions of windows 95 Sim City didn't work because the operating system allocated memory differently, and Sim City would crash as expected because of the bug in the program. Amazingly, in the final version of Win95 the original Sim City worked. Microsoft engineers had actually tested backwards compatibility with Sim city, located the bug, and worked around it in their sourcecode.
--------

AvalonH wrote:

Question is why would you use bios instead of direct hardware access for PS2 mouse.

PS2 has really kludgy programming interface, plus hardware got really complicated in the nineties, KBC was integrated into chipsets and EC(laptop), we got ACPI - old interfaces were dynamic(toggleable), often virtual/emulated (using ring -1/-2 SMM/-3 ME!).

All in all MSI simply didnt care about bios bugs affecting legacy, unsupported OSes in boards for the OEM market, often bottom of the barrel supermarket computers.

That's cool. Hey, Microsoft wasn't so bad back in the day...working around bugs, releasing good mouse drivers :p

AvalonH wrote on 2019-03-10, 13:24:

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 know this is an old thread, but I found the answer: https://www.betaarchive.com/wiki/index.php/Mi … B_Archive/97883

Basically, they switch the BIOS to 1 byte packets in order to be able to compute the timestamp of each individual byte. Then the driver uses the timestamps to segment bytes into packets by itself, avoiding problems in the BIOS synchronization code (which by my experience most of the time is non-existent).

They even provided a fixed VKD.386 for Win386/3.x that uses the same strategy to avoid well-known PS/2 synchronization issues with the stock VKD.

I am trying to write a DOS mouse driver and I think I'm going to switch to 1-byte packets too, but for a different reason. Most mice with scroll wheel follow a 4-byte protocol. However there is no standardized method for the PS/2 BIOS to deliver 4-byte packets to the callback routine. Even between VirtualBox and VMware there are already differences. I saw some wheel mouse drivers from the era (e.g. Genius) and they all seem to use 1-byte interface too.