USB Mouse

[maxtherabbit]

I'm sorry to report it still isn't working for me

the output of USBMOUSE /b has changed however

the "stage" is now reporting as 214 and the error code is 0009h

EDIT: that is what it said the first time - after rebooting and trying it again it now says both stage and error code are 0
EDIT2: I have 2 DOS profiles: one with UMBPCI and one with EMM386 - when I boot the one with UMBPCI it says stage 214 error 9h but when I boot the one with EMM386 it says stage and error are 0. There are other differences in the profiles so this could be a red herring but I thought it prudent to mention. Regardless the mouse doesn't work in either profile, but the new driver does successfully load into EMS on the EMM386 one.

[Bret]

Thanks for testing. I'll continue looking into it.

[Bret]

Could you send me the device and configuration descriptors,, please? For example oif the Address of the Devices is 2:

USBUHCIL Descr 2 > HPMOUS.TXT

Error 214 has something to do with packet sizes. It looks like the mouse is trying to send 9 bytes of data and USBMOUSE will only accept 8.

[maxtherabbit]

Absolutely, I'll provide that as soon as I get home this evening.

Keep in mind that from a cold boot going into the EMM386 profile is not giving me the same error. Does that jibe?

[maxtherabbit]

Code: Select all

USBUHCIL 0.14, (C) 2007-2010, Bret E. Johnson.
DOS Driver for a Universal HCI compatible USB Host Controller.
  LITE version (maximum 16 Devices, no Isochronous Transactions).

        DEVICE DESCRIPTOR
ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ
Descr Length:                 12h  18
Descr Type:                   01h  Device
USB Release:                0200h  2.00
Device Class:                 00h  Look at Interface
Device SubClass:              00h  None
Device Protocol:              00h  None
Max Packet Size EP0:          20h  32
Vendor ID:                  03F0h  Hewlett Packard                         
Product ID:                 A407h  41,991
Device Release:             0321h  3.21
Manufacturer String:          01h  "HP"
Product String:               02h  "HP Link-5 micro dongle"
Serial # String:              00h  None
# of Configs:                 01h  1

    CONFIGURATION DESCRIPTOR
ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ
Descr Length:                 09h  9
Descr Type:                   02h  Configuration
Descr Total Length:         003Bh  59
# of Interfaces:              02h  2
Configuration Value:          01h  1
Configuration String:         00h  None
Attributes:                   A0h  Valid Historical Attribute 80h
                                   Bus Powered
                                   Remote Wakeup
                                   Not Battery Powered
Current Draw / 2:             32h  50 (100 mA)

      INTERFACE DESCRIPTOR
ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ
Descr Length:                 09h  9
Descr Type:                   04h  Interface
Interface Number:             00h  0
Alternate Setting:            00h  0
# of End Points:              01h  1
Interface Class:              03h  HID (Human Interface Device)
Interface SubClass:           01h  Boot
Interface Protocol:           01h  Keyboard
Interface String:             00h  None

  HUMAN INTERFACE DEVICE DESCR
ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ
Descr Length:                 09h  9
Descr Type:                   21h  HID (Human Interface Device)
HID Class Release:          0111h  1.11
Country Code:                 00h  None/Not Applicable
# of Classes:                 01h  1
Class Descr Type 1:           22h  Report
Class Descr Size 1:         0041h  65

      END POINT DESCRIPTOR
ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ
Descr Length:                 07h  7
Descr Type:                   05h  EndPoint
End Point Number:             81h  EndPoint = 1  Direction = In
Attributes:                   03h  Interrupt NonSynchronous Data
Max Packet Size:            0008h  8
Max Poll Interval:            0Ah  10

      INTERFACE DESCRIPTOR
ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ
Descr Length:                 09h  9
Descr Type:                   04h  Interface
Interface Number:             01h  1
Alternate Setting:            00h  0
# of End Points:              01h  1
Interface Class:              03h  HID (Human Interface Device)
Interface SubClass:           01h  Boot
Interface Protocol:           02h  Mouse
Interface String:             00h  None

  HUMAN INTERFACE DEVICE DESCR
ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ
Descr Length:                 09h  9
Descr Type:                   21h  HID (Human Interface Device)
HID Class Release:          0111h  1.11
Country Code:                 00h  None/Not Applicable
# of Classes:                 01h  1
Class Descr Type 1:           22h  Report
Class Descr Size 1:         00F1h  241

      END POINT DESCRIPTOR
ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ
Descr Length:                 07h  7
Descr Type:                   05h  EndPoint
End Point Number:             82h  EndPoint = 2  Direction = In
Attributes:                   03h  Interrupt NonSynchronous Data
Max Packet Size:            0009h  9
Max Poll Interval:            02h  2

[Bret]

No, that doesn't jibe. But that's going to be a separate issue that will require separate troubleshooting.

The problem is indeed that the mouse says it will send as many as 9 bytes (the Max Packet Size for the End Point is 9) and USBMOUSE will only allow 8. I'll make some changes to USBMOUSE to allow for that.

[Bret]

Here's a new version of USBMOUSE to try. It will hopefully work now with your HP wireless mouse. I would classify this as a "bug", since it's something I really should have seen before but didn't. It only required a small change to the program.

[maxtherabbit]

We are good! 100% working in both UMB and EMS

[LaughingMan]

Wow! This is great. And, I'm sorry for my delay in response.

I only just saw your post and just had time to test with two mice:

• Razer Deathadder Elite
• Corsair Harpoon-RGB

I did test with my usb hub (UGREEN USB Switch Selector).

The Razer worked (1) direct connection to the computer, (2) through the USB switch selector, (3) hot swap (both via switch selector and direct connection), and (4) I could use the switch selector.

The Corsair made beep on connection, but it did not work.

Also, the keyboard does not work after I run my batch file.

Code: Select all

USBUHCIL Index 0
USBUHCIL Index 1
USBKEYB
USBMOUSE
CTMOUSE /P /O /3
EDIT

Thanks again. I'll give you a more detailed response soon.

[watlers world]

The Logitech Connect M-R0006 Mouse with C-BT44 receiver was not working with the older versions of USBMOUSE.
I downloaded usbms013.ZIP and tested the new driver.

The wireless mouse is now functional.
Thanks!

[fatcat386]

Hi! I have a strange problem. After loading USBMOUSE v0.10 my PS/2 keyboard stops responding. But USB mouse works as it should. I tryed to use v0.12 and v0.13 from this thread and both work and not stopping keyboard, but they add significant lag to mouse movements idk why. Interesting what if execute USBMOUSE v0.12-13 and after it USBMOUSE v0.10 then it destroys that lag and keyboard is working too. OS is FreeDOS 0.13-rc2 with JEMMEX or HIMEM/JEMM, keyboard Mitsumi KFK-EA4SA, mouse Logitech M-BD69, m/b AsRock P4i65G.

Also v0.13 resetting my PC when DPMS loaded and hangs and beeping when DPMS not loaded, but I can run it with /EMS:N /DPMS:N flags.

[Bret]

Wow, those are some weird problems. I'll try to investigate and see if I can figure anything out. Also, does it make any difference which version of DPMS is loaded (1.41 or 1.44)?

[Bret]

I just thought of one more thing that might help. Just as an FYI, the PS2 keyboard and PS2 mouse are both very related to each other at the hardware level (they are not completely independent of each other) and they do interact to some degree.

Anyway, the problem might be somewhere in the BIOS so "replacing" part of the BIOS might be a solution. You can do this with the Microsoft KEYB program which came with all of the later versions of DOS and DOS-based versions of Windows. Note that the KEYB program from FreeDOS is NOT equivalent to the MS KEYB program and does not replace the keyboard BIOS the way the MS KEYB program does, so it won't help. If you don't have a copy of MS KEYB available, I can send you one. I don't know if it will help or not, but it's probably worth a try. I know it helps a lot with some of my keyboard related programs.

Another thing that might help is to install the USBKEYB program, even if you don't have a USB keyboard. I really doubt if this would make a difference, but you never know for sure -- troubleshooting can get really weird sometimes.

[fatcat386]

Thank you! I tried all suggestions and MS keyb too but it didn't help. But thanks to all this I figured out what I had bad memory settings. JEMMEX and JEMM386 both warned me "System memory found at e000-efff, region might be in use" but I ignored this thinking its kinda not scary. Finally I applied X=E000-EFFF setting to manager to exclude that region and warning is gone and keyboard problem too .

v0.12-13 is working normally with both DPMS versions except what they add lag to my mouse. So i staying with v0.10.
Yet sometimes USBUHCIL load itself into low memory area I not understanding why. Maybe I'm just lucky)

[Bret]

Yes, a memory conflict will definitely cause weird problems like this -- two things trying to use the same memory at the same time will cause both of them to not work right. I'm kind of surprised it just acted kind of weird and didn't completely crash. I'll still look into the lag issue and try to figure that out (but it may be hard if I can't duplicate it on my own machines). But I'm glad it's working for you now.

[fatcat386]

I just tried to run v0.13 with parameter /Raw and I can say it updates very rapidly, I not see any lag here. But in programs lag exists. Also I tried other mouse and its still here. Maybe its somehow related to CTMOUSE.

[Bret]

It could be related to CTMOUSE. I know when I first tried CTMOUSE (a VERY long time ago) it didn't work for me and I basically abandoned it. I kept being told by others that it did work OK, and I found it did (at least the later versions do). I know CTMOUSE uses a LOT less memory than most of the other mouse drivers, so it's possible they know something that CTMOUSE doesn't.

Anyway, we can do a couple more tests to maybe help narrow the problem down. First of all, a little explanation on all of the different layers may help. The lowest layer of all is the PS2 hardware layer that the PS2 mouse uses (these are the electrical signals and serial protocols that the mouse uses to communicate with the chipset inside the computer). The next layer is the BIOS, where those electrical signals are converted into 3- or 4-byte "software packets" of data. The next layer is the mouse driver (CTMOUSE or equivalent) which takes the information from one of the lower layers (either the hardware or the BIOS) and presents the mouse on the screen (as the mouse cursor) and to the applications that request it.

The layer where USBMOUSE resides is the middle one (the BIOS). What USBMOUSE does is takes the normal (PS2) BIOS layer and "adds" the USB mouse data to it. That is, you can have up to 8 USB mice and a single PS2 mouse all working at the same time on the computer and USBMOUSE presents them all so that they look like a single mouse (at the BIOS layer) to the upper layers (CTMOUSE and the applications).

The way we can see if the problem resides at the CTMOUSE layer or not is with PS2MTEST, the program that I wrote to test USBMOUSE. What PS2MTEST does is sort of "intercept" what would normally go to CTMOUSE and presents the raw BIOS data on the screen in a different format than CTMOUSE does. That is, instead of creating a mouse cursor and presenting a software layer that applications can use, PS2MTEST just shows what's coming out of the BIOS directly with numbers and arrows.

Try testing with PS2MTEST and see if there's a lag. You can even test it with more that one USB mouse at the same time (if you have enough USB ports) and even with a PS2 at the same time (if you have a PS2 port and PS2 mouse). If there's no lag with PS2MTEST, then the problem is more than likely with CTMOUSE (or your video BIOS or something), but probably not with USBMOUSE.

The other thing you might try is with different CTMOUSE options. I always use CTMOUSE (V 2.1) with the /P /O /3 options. I don't know if that will make any difference, but it might.

[fatcat386]

Oh, thanks for such detailed explanation) It's really interesting knowledge for me since I had no understanding. Yet I did some tests and can confirm what unfortunately lag is present in PS2MTEST (not touching CTMOUSE at all). And today I tried all this things on a different PC (old laptop) with FreeDOS and get same laggy results. Adding to this configuration PS/2 mouse making that mouse lag too after USBMOUSE v0.13 load. Both mice work simultaneously and both lag.

Next I decided to try other OS, not a FreeDOS. I had booted with Win98 system floppy (MS-DOS v7) and loaded USBUHCIL, USBMOUSE and PS2MTEST and.. no lag! Then I tried to add CTMOUSE and run some app and no lag too.

So now I think what problem is FreeDOS kernel or something related. And from observations it seems something bad happening on PS/2 resetting stage.
However v0.10 not have such problem.

[Bret]

Thanks for doing all of the testing. It does seem that the common element is FreeDOS, and not either USBMOUSE or CTMOUSE. I should say that I normally use MS-DOS 7.1 ("DOS 98") or DOS 6.2 rather than FreeDOS. I really only use FreeDOS for temporary testing, when I'm getting ready to try and release an "official" version of a program. I didn't test any of the later USBMOUSE versions with FreeDOS, though. If I had I might have caught that issue.

I'll do some more testing when I find the time and see if I can figure out the problem. It wouldn't surprise me if it has something to do with the way FreeDOS uses upper or high memory, though. It's possible that if FreeDOS is loaded into conventional memory the problems will disappear.

[Bret]

I just thought of anther possibility for the delays. Particularly when things are using DPMS, the computer can be constantly switching between real and protected mode and the switching CAN take a very long time. This is due to the A20 (Address 20) line needing to be switched on and off every time a mode switch occurs. In JEMMEX, you can use the A20Method:AlwaysOn option to avoid the switching. Only in VERY rare cases will this ever cause a problem and things usually run much faster. It doesn't look like JEMM386 has an A20Method option.

[fatcat386]

Thanks for a hint to try other methods. Unfortunately lag is present even in just conventional memory mode without any managers. Also no effect when I use A20Method:AlwaysOn switch in JEMMEX. With or without DPMS too.

Maybe offtopic, but what's your opinion. Is MS-DOS more bug free and stable? I worked with it in 90s, it was okay, but computers was more simple. I'm just affraid HIMEM/EMM386 little old for my retro config with P4 and 1024Mb RAM. FreeDOS looking pretty to me. At least something new after many years.

Yet it is FreeDOS 1.3rc2 intended for testing I guess. Maybe we should write to them to fix that problem before final release. I can do it later when I get free time.

[Bret]

I find in general that MS-DOS is better and more reliable than FreeDOS, though FreeDOS is still quite good. There are still a few areas where FreeDOS isn't 100% compatible with MS-DOS, but those areas are usually pretty obscure to most people even though I have noticed some of them with what I do. The one you just found is a new one, and the fact that nothing related to A20 or Upper/high Memory fixes it seems like a real issue. I still don't know if it's something that's "wrong" with FreeDOS or something in USBMOUSE (or USBUHCI), but will try to find time to isolate it.

For example, one of the areas where FreeDOS is not 100% compatible with MS-DOS is that FreeDOS only supports 512-byte sectors on hard drives, while MS-DOS supports sector sizes of up to at least 4096 bytes. In the update to the USBDRIVE program I'm working on (very slowly since I have so little time) one of the things I'm adding is support for CD's, DVD's, and maybe Blu-Rays (BD's) as well. These media all have 2048 (2k) sector sizes, which is one reason you need special drivers to use them and they can't be accessed through the normal DOS file access mechanisms. The one exception to this is DVD-RAM's, which can be formatted in FAT32 just like a hard drive would be. But, they use 2k sector sizes so FreeDOS can't access them directly while MS-DOS can (with an appropriate configuration). I'm still a long ways from having USBDRIVE completed and DVD-RAM media is pretty much obsolete and really hard to find, but the fact that I can do something like that in MS-DOS and I can't in FreeDOS is one reason I stick with MS-DOS. I've not yet discovered anything that works the other way -- something I could do in FreeDOS that I can't do in MS-DOS.

I should also say that I use some of the FreeDOS utilities, since some of them are better than their MS counterparts (and others, of course, aren't). But from the perspective of the OS itself, I much prefer MS-DOS.

In your specific case regarding HIMEM/EMM386 vs something like JEMM, I use JEMM with MS-DOS. JEMM works with either FreeDOS or MS-DOS, and JEMM is one of the utilities that I think for the most part works better than the MS ones. But even JEMM doesn't do some things that HIMEM/EMM386 does, like support I/O Virtualization which is something that's really needed for extensive use of my USB drivers. I/O virtualization is an obscure thing for most people, but not for me.

[fatcat386]

That's really interesting expanded info, thanks Bret! Although I'm not familiar with I/O virtualization and some other details you described (but I understood what you mean) I've lost some doubts and think what MS-DOS more polished even if it have flaws. So further I intend to use it in mix with FreeDOS to get best from these two.

[Torafuma]

Hi All! I created an account just to post to the thread and say thank you! I was able to get my MS Intellimouse USB working on my Pentium 233 MMX system (PCPartner VIB8804DSE)! For some reason, the board had the PS/2 pins permanently soldered to disable PS/2... and with the weird pinout I have been battling getting a mouse of any kind to work on the system (other than breaking down and paying for a Serial Mouse)!

Once I ordered a USB Motherboard Header (Startech) and connected it to the motherboards USB1 header, I was able to finally get a mouse to work!

- Used the USBUHCI.COM driver stack from the original release (2010)
- Used the USBMOSE.COM from the usbms013.zip file in this thread
- Used the Latest version (2.1 beta 4) of CTMouse

Thanks to Bret and all of the helpful people in this thread, I am finally able to enjoy this Retro PC I started building in the summer of 2020!

[pedro]

Hi Guys,

I created an account to also say thank you. What you do here is unique!

I wanted to ask for a driver for the keyboard Mitsumi KFK-EA4SA

I see above that the user @fatcat has it. I am desperate

any help would be valuable

best