DOS VDM - USB and Game port Gamepad support

[Dave Yeo]

Hi guys.

When I first ported Dosbox, I tested the joystick support, i.e. PC joysticks via DB15 port, on a T23, and it worked. It should still work.

As for USB joysticks:
The linux port of SDL 2 uses the HIDAPI library for supporting USB joysticks. We probably could port that code over to OS/2 (and then back to SDL 1), but I have to understand that code myself first.

Trying to build the HIDAPI library fails as we're missing wcsdup, a wide char version of strdup it seems. Have to find it somewhere unless Paul has added to one of his GCC ports.
Which brings up another possible problem, libusb seems to do unicode, utf8 I think.

[Mark Szkolnicki]

Hi Mark,

I understand your explanations. Thank you. We will take the step by step approach.
I have prepared oinput.cmd that hopefully obtains input from your LogiLink adapter.

Run oinput.cmd and operate your ThrustMaster for a few seconds.
When it works you will see something like below to appear.

Code: [Select]

EC100000810306000100000000FFEEEE
EC180000810306000100FEFFFF00EEEE
EC100000810306000100FFFFFF00EEEE
EC18000081030600010000000000EEEE
EC100000810306000100FFFFFF00EEEE

Please post your output with a description of your actions.

Have fun,

Wim

Hi Wim!

As to fun .............. playing with toys is always fun ........... sure beats cleaning up spills or evacuating people........

I downloaded your file, and undertook the following:

1) created a new /sys/gametest directory on one of my ArcaOS partitions, on the system where I had installed the Thrustmaster Joystick. Copied oinput.cmd into that directory.

Test 1

Ran oinput.cmd the first time from a command prompt and got:

required direct control driver
Device= ?:\OS2\BOOT\USBECD.SYS /D:0583:203#:0110 /N:$THRUST$
not defined in CONFIG.SYS file

(See attached oinput_test001.jpg)

I modified the CONFIG.SYS, to add the /N: descriptor and rebooted.

Test 2

Ran oinput.cmd again

This time the response was:

sys0031: A device attached to the system is not functioning
(See attached oinput_test002.jpg)

In this case I was testing to see whether you had had a typo, as the output that came back previously was:

Device= ?:\OS2\BOOT\USBECD.SYS /D:0583:203#:0110 /N:$THRUST$

As the device USB ID I had posted was 2031 and yours was 203#, I wanted to make sure that was indeed what you wanted in the CONFIG.SYS

I'm interested as to why that syntax was used, as I'm sure other people would be.
(I think we are all learning programming in this exercise)

I modified the CONFIG.SYS again and rebooted.

Test 3

After adding the octet (#) instead of (1) and running oinput.cmd again, the output was a static variation of what you described (see oinput_test003.jpg below):

Multiple rows of:

EC1800008103070000000F4956FF6EEE

I assumed you were attempting to address either the adapter or the Joystick, somewhat like a "ping" to see if your could contact the device. Did not adjust the joystick just left it in place so got that one data point which continued endlessly until I closed the prompt window.

Test 4

Ran oinput.cmd again, this time moving the joystick.

This test was a little harder to do, to capture the output, as the output moves so fast down the ArcaOS prompt window - used the |more command as I was moving the joystick. Output is as attached (oinput_test004.jpg).

This time there was changes to the output, as multiple data points were noted. I tried the same test as well with both the hat and the 4 buttons. but no data point changes were noted.

Hope this was what you were looking for, Wim.

I am usually checking messages until about 21:00 MST each day - if you would like any further information tonight my time, please contact me and Best!

M

[Dave Yeo]

Hi Mark, you might be able to capture the output by redirecting stdout/stderr,

Code: [Select]

oinput.cmd 2>&1 | tee oinput.log


[Dave Yeo]

Meanwhile, I managed to compile hidapi but it seems there is something missing, possibly in my attempt at wcsdup(), the version I found on the net originally used strlenW() which we don't have, so I changed it to wcslen().
Here's the DLL and the test program in the lib directory, needs libusb100.dll, the libusb1 package, and the devel package to build. My patch against the github source also included, after patching run "sh bootstrap", "sh configure" then make.
Tried my Sons XBox controller which wasn't detected. Then his Logitech Dual Action gamepad which was detected. First 2 entries are my unified keyboard/mouse controller, 3rd is his gamepad.

Code: [Select]

H:\tmp\hidapi\lib>hidtest.exe
hidapi test/example tool. Compiled with hidapi version 0.11.0, runtime version 0.11.0.
Compile-time version matches runtime version of hidapi.

Device Found
  type: 046d c534
  path:
  serial_number: (null)
  Manufacturer: (null)
  Product:      (null)
  Release:      2901
  Interface:    0
  Usage (page): 0x6 (0x1)

Device Found
  type: 046d c534
  path:
  serial_number: (null)
  Manufacturer: (null)
  Product:      (null)
  Release:      2901
  Interface:    1
  Usage (page): 0x6 (0x1)

Device Found
  type: 046d c216
  path:
  serial_number: (null)
  Manufacturer: (null)
  Product:      (null)
  Release:      300
  Interface:    0
  Usage (page): 0x4 (0x1)

unable to open device

I guess the serial number etc should be filled in? Perhaps the Usage (page) is good enough for SDL?

[Mark Szkolnicki]

Hi Mark, you might be able to capture the output by redirecting stdout/stderr,

Code: [Select]

oinput.cmd 2>&1 | tee oinput.log


Thanks Dave!

Did get enough, I think to suit Wim's requests, I think with |more - will try that next time.

And how is things going near Abbotsford? Relatives of ours reported they are short of supplies (milk, food, fuel) near Chiiliwack. And we hear more storms are coming ............ !

Best!

M

[Dave Yeo]

Hi Mark,
Use less instead of more, it is a lot more capable including scrolling back up.
Things aren't bad here, some gas stations are empty and the refinery shut down today, so rationing gas, 30 litres on the honour system though some stations are setting things to a $50 limit. Gas in Vancouver is about $1.60 a litre and some were charging close to $2 a litre.
Stores here have the odd empty shelf and some things like eggs and toilet paper are limited to one or two packages to buy. Not bad here but we're still connected to the west.
Driving to Abbotsford the other day, could see the floods, highway was closed so had to take back roads but it is further east where things are bad. Now we have another couple of atmospheric rivers coming, perhaps 100-150 mm of rain, not good. Many of the dykes have been shored up and the Fraser is back down but it snowed up in the hills so might be bad.
See similar is happening to Newfoundland and Labrador except colder, weird times.

[Mark Szkolnicki]

Meanwhile, I managed to compile hidapi but it seems there is something missing, possibly in my attempt at wcsdup(), the version I found on the net originally used strlenW() which we don't have, so I changed it to wcslen().
Here's the DLL and the test program in the lib directory, needs libusb100.dll, the libusb1 package, and the devel package to build. My patch against the github source also included, after patching run "sh bootstrap", "sh configure" then make.
Tried my Sons XBox controller which wasn't detected. Then his Logitech Dual Action gamepad which was detected. First 2 entries are my unified keyboard/mouse controller, 3rd is his gamepad.

Code: [Select]

H:\tmp\hidapi\lib>hidtest.exe
hidapi test/example tool. Compiled with hidapi version 0.11.0, runtime version 0.11.0.
Compile-time version matches runtime version of hidapi.

Device Found
  type: 046d c534
  path:
  serial_number: (null)
  Manufacturer: (null)
  Product:      (null)
  Release:      2901
  Interface:    0
  Usage (page): 0x6 (0x1)

Device Found
  type: 046d c534
  path:
  serial_number: (null)
  Manufacturer: (null)
  Product:      (null)
  Release:      2901
  Interface:    1
  Usage (page): 0x6 (0x1)

Device Found
  type: 046d c216
  path:
  serial_number: (null)
  Manufacturer: (null)
  Product:      (null)
  Release:      300
  Interface:    0
  Usage (page): 0x4 (0x1)

unable to open device

I guess the serial number etc should be filled in? Perhaps the Usage (page) is good enough for SDL?

Yup, weird times indeed, Dave - was 9 C here yesterday and had an abnormal temperature trend here all day today - started at 2 C this morning - was -15 C at 16:00.

Just downloaded and tested your hidapi - attached a JPG of the output  - 0583:2032 is the Logilink USB2.0 to Gameport adapter with Thrustmaster Joystick attached - will have to run lsusb to see what the other device was that was detected.

Best!

M

[Wim Brul]

Hi Mark,

Device= ?:\OS2\BOOT\USBECD.SYS /D:0583:203#:0110 /N:$THRUST$
.
I'm interested as to why that syntax was used, as I'm sure other people would be.
.
(I think we are all learning programming in this exercise)

There is a 4 position switch on your device and it is my understanding that this switch corresponds to 4 different idProduct values.
Dependent upon the switch setting used (1, 2, 3, 4) I expect your device to report idProduct 2030, 2031, 2032, 2033 respectively.
This way oinput.cmd would work for all 4 switch settings and the actual hid input report obtained would vary accordingly.

Code: [Select]

EC18000081030700 | 04000F4956FF6E | EE
EC18000081030700 | 04000F4A94FF6E | EE
EC18000081030700 | 04000F9250FF6E | EE
On each line, between the | characters, you see the actual hid input report data in hexadecimal.

Code: [Select]

04 | 00 | 0F | 49 | 56 | FF | 6E
B  | 00 | H  | X  | Y  | Z  | S
B=button, H=Hat, X=X-axis, Y=Y-axis, Z=Z-axis, S=Slider

Please obtain the lsusb report for each of the 4 switch settings of your input device.

Please try and run oinput.cmd for each of the 4 switch settings of your input device.

Wim

[Mark Szkolnicki]

Hi Mark,

Device= ?:\OS2\BOOT\USBECD.SYS /D:0583:203#:0110 /N:$THRUST$
.
I'm interested as to why that syntax was used, as I'm sure other people would be.
.
(I think we are all learning programming in this exercise)

There is a 4 position switch on your device and it is my understanding that this switch corresponds to 4 different idProduct values.
Dependent upon the switch setting used (1, 2, 3, 4) I expect your device to report idProduct 2030, 2031, 2032, 2033 respectively.
This way oinput.cmd would work for all 4 switch settings and the actual hid input report obtained would vary accordingly.

Code: [Select]

EC18000081030700 | 04000F4956FF6E | EE
EC18000081030700 | 04000F4A94FF6E | EE
EC18000081030700 | 04000F9250FF6E | EE
On each line, between the | characters, you see the actual hid input report data in hexadecimal.

Code: [Select]

04 | 00 | 0F | 49 | 56 | FF | 6E
B  | 00 | H  | X  | Y  | Z  | S
B=button, H=Hat, X=X-axis, Y=Y-axis, Z=Z-axis, S=Slider

Please obtain the lsusb report for each of the 4 switch settings of your input device.

Please try and run oinput.cmd for each of the 4 switch settings of your input device.

Wim

Good Afternoon Wim!

I actually realized what you mentioned related to the mode switch in an inadvertent way.

Dave Yeo has been experimenting with the hidapi libraries, and installing his ported version of them and running his test file I got a product ID of 2032 back, not 2031. Running lsusb it gave a descriptor of the adapter as being USB Nest (mode 3) where previously it was USB Nest (mode 2).

I will attempt to run the tests you noted, with the various configuations, but probably will not be able to do all the configurations today or tonight,. so will try to feed you data as I complete each stage.

Best as always!

M

[Mark Szkolnicki]

Hi Mark,

Device= ?:\OS2\BOOT\USBECD.SYS /D:0583:203#:0110 /N:$THRUST$
.
I'm interested as to why that syntax was used, as I'm sure other people would be.
.
(I think we are all learning programming in this exercise)

There is a 4 position switch on your device and it is my understanding that this switch corresponds to 4 different idProduct values.
Dependent upon the switch setting used (1, 2, 3, 4) I expect your device to report idProduct 2030, 2031, 2032, 2033 respectively.
This way oinput.cmd would work for all 4 switch settings and the actual hid input report obtained would vary accordingly.

Code: [Select]

EC18000081030700 | 04000F4956FF6E | EE
EC18000081030700 | 04000F4A94FF6E | EE
EC18000081030700 | 04000F9250FF6E | EE
On each line, between the | characters, you see the actual hid input report data in hexadecimal.

Code: [Select]

04 | 00 | 0F | 49 | 56 | FF | 6E
B  | 00 | H  | X  | Y  | Z  | S
B=button, H=Hat, X=X-axis, Y=Y-axis, Z=Z-axis, S=Slider

Please obtain the lsusb report for each of the 4 switch settings of your input device.

Please try and run oinput.cmd for each of the 4 switch settings of your input device.

Wim

Hi Wim!

Have done some testing, and this is what I have found so far.

I ran lsusb using your statement in CONFIG.SYS
Device= D:\OS2\BOOT\USBECD.SYS /D:0583:203#:0110 /N:$THRUST$
(specific to my ArcaOS configuration)

And lsusb always came back, despite what mode was switched to as product ID 2032 (USB Nest Mode 3)

And your oinput.cmd essentially generated the same output.

I believe that there are only two types of thinkers generally, Wim - linear thinkers (just follow instructions to the inevitable conclusion) and lateral thinkers (the second ask things like "what do Babylon and Babe Ruth in an encyclopedia have to do with each other?) so I just didn't blindly follow the instructions - I went back to the beginning.

I modified CONFIG.SYS again to remove the /D and /N statements, rebooted, and four times ran your USBREAD.CMD after inserting the LogiLink adapter each time, with the switch setting changed from Mode 1 to 4, to generate the output.

(See the attached Logilink Mode X Test usbreadinsert.JPG files)

And you were correct - four different USB productID's were generated - however, despite the statement contained in the CONFIG.SYS and whatever switch configuration was tested, it would always default to the one that was plugged in last. (in the final case the Mode 3 switch setting and ProductID 2032 on the adapter).

To undertake the testing required, I will have to:

1) Remove the current CONFIG.SYS /D and /N switches from the driver statement and reboot.
2) Run USBREAD.CMD again, plugging in the adapter each time.
3) Put the /D and /N statements back, and
4) Run the tests for each mode again

I'm not concerned about the steps involved - will just require additional time - I expect that using this device (ie. the adapter) is an extraordinary case, given four modes involved.

In the past I have used Mode 2 (and that Mode switch setting) to use the Joystick, but will attempt to generate all four and Best!

M

[Mark Szkolnicki]

Hi Wim!

There is a 4 position switch on your device and it is my understanding that this switch corresponds to 4 different idProduct values.
Dependent upon the switch setting used (1, 2, 3, 4) I expect your device to report idProduct 2030, 2031, 2032, 2033 respectively.
This way oinput.cmd would work for all 4 switch settings and the actual hid input report obtained would vary accordingly.

Please obtain the lsusb report for each of the 4 switch settings of your input device.

Please try and run oinput.cmd for each of the 4 switch settings of your input device.

Completed my current tests successfully and have further to report.

After setting the USB2.0 to Gameport Adapter to each of Switch Modes 1-4 using the methodology I identified in my previous post, I have identified to use of each:

Mode 1: reports the device attached as a 2-axis, 4 button joystick w/view finder (hat), and rudder

Mode 2: reports the device attached as a 4-axis, 4 button joystick w/view finder (hat) (this is the configuration of the Thrustmaster Joystock I have)

Mode 3: reports the device attached as a 4-axis, 4 button joystick

Mode 4:  reports the device attached as a 2-axis, 8 button gamepad

I have attached the lsusb hardware reports of all four modes, as well as the associated oinput.cmd outputs.

As the Thrustmaster Joystick I have really is defined by Mode 2 only, I would suggest that I will reset the adapter to a static Mode 2, and we should concentrate efforts on that mode only, as I do not have any other equipment which may meet the other definitions, for test purposes, and I am not sure anyway if DOSBOX would recognize Mode 1 and 4 configurations, as they were not defined in any of the legacy DOS games I am aware of.

I have not had a look at the hex information presented for the various inputs which may be provided by the Joystick, as I have been doing other things in addition to the testing - will have a look tomorrow and may provide further comments.

In the meantime, best to you Wim and a fine day!

M

[Wim Brul]

Hi Mark,

Thank you for your efforts. I did some analysis - see "LogiLink input analysis.jpg" attached.

I believe that there are only two types of thinkers generally, Wim - linear thinkers (just follow instructions to the inevitable conclusion) and lateral thinkers (the second ask things like "what do Babylon and Babe Ruth in an encyclopedia have to do with each other?) so I just didn't blindly follow the instructions - I went back to the beginning.

I appreciate that. I refrained from detailed instructions and mentioning foreseeable problems because I figured you would do that and that would be most effective.

As the Thrustmaster Joystick I have really is defined by Mode 2 only, I would suggest that I will reset the adapter to a static Mode 2, and we should concentrate efforts on that mode only, as I do not have any other equipment which may meet the other definitions, for test purposes, and I am not sure anyway if DOSBOX would recognize Mode 1 and 4 configurations, as they were not defined in any of the legacy DOS games I am aware of.

Right you are. Which brings me to the question what efforts to concentrate on. I have enough information to process the input report data.

There are still 2 ways to support USB gamepads/joysticks (one  being thru GAMEVDD.SYS/ GAMEPDD.SYS and the other thru HIDAPI to DOSBox) and I think both should be working. I have enough information to try and modify GAMEPDD.SYS to work with your Thrustmaster Joystick. This will take some time and effort for me to accomplish. For starters I am thinking of an ioctl interface for gamepads/joysticks into GAMEPDD.SYS to be used by some program that uses USBECD.SYS to access your Thrustmaster Joystick. When I succeed then perhaps this could also be an alternative way for DOSBox to be used. Although for DOSBox it is better that someone gets HIDAPI to work well.

Our local time is now 13:11 hour. Did you receive this post right away?

Best regards,
Wim

[Mark Szkolnicki]

Hi Wim!

Just starting my day - 0730 in Alberta.

M

[Mark Szkolnicki]

Hi Again Wim!

As the Thrustmaster Joystick I have really is defined by Mode 2 only, I would suggest that I will reset the adapter to a static Mode 2, and we should concentrate efforts on that mode only, as I do not have any other equipment which may meet the other definitions, for test purposes, and I am not sure anyway if DOSBOX would recognize Mode 1 and 4 configurations, as they were not defined in any of the legacy DOS games I am aware of.

Right you are. Which brings me to the question what efforts to concentrate on. I have enough information to process the input report data.

There are still 2 ways to support USB gamepads/joysticks (one  being thru GAMEVDD.SYS/ GAMEPDD.SYS and the other thru HIDAPI to DOSBox) and I think both should be working. I have enough information to try and modify GAMEPDD.SYS to work with your Thrustmaster Joystick. This will take some time and effort for me to accomplish. For starters I am thinking of an ioctl interface for gamepads/joysticks into GAMEPDD.SYS to be used by some program that uses USBECD.SYS to access your Thrustmaster Joystick. When I succeed then perhaps this could also be an alternative way for DOSBox to be used. Although for DOSBox it is better that someone gets HIDAPI to work well.

Currently, Dave Yeo could answer to this better than I, as he did the port, but I don't believe that he has a full implementation of HIDAPI up and running. His exact words were:

Meanwhile, I managed to compile hidapi but it seems there is something missing, possibly in my attempt at wcsdup(), the version I found on the net originally used strlenW() which we don't have, so I changed it to wcslen().

Here's the DLL and the test program in the lib directory, needs libusb100.dll, the libusb1 package, and the devel package to build. My patch against the github source also included, after patching run "sh bootstrap", "sh configure" then make.

I did try what he had ported so far, as mentioned previously, and running his test program was able to identify the joystick in Mode 3 on the adapter - I expect if I reset to Mode 2 as mentioned previously and keep it there, it would report that.

Will have a look at your input report data, Wim and see if any lateral thinking comes to any conclusion, one way or the other. Being a troubleshooter by professional, I can't provide technical specifics to you software programming types, but I can ask some really stupid questions - and occasionally that twigs flashes of brilliance in others ......... !

I was hoping that we weren't putting you to a lot of work, unless you find this fun and a challenge. As always, if I can test something for you, as with Dave or any others, I can at least provide feedback, and hopefully useful feedback.

Best!

M

[Mark Szkolnicki]

Hi Again Wim!

As the Thrustmaster Joystick I have really is defined by Mode 2 only, I would suggest that I will reset the adapter to a static Mode 2, and we should concentrate efforts on that mode only, as I do not have any other equipment which may meet the other definitions, for test purposes, and I am not sure anyway if DOSBOX would recognize Mode 1 and 4 configurations, as they were not defined in any of the legacy DOS games I am aware of.

Right you are. Which brings me to the question what efforts to concentrate on. I have enough information to process the input report data.

There are still 2 ways to support USB gamepads/joysticks (one  being thru GAMEVDD.SYS/ GAMEPDD.SYS and the other thru HIDAPI to DOSBox) and I think both should be working. I have enough information to try and modify GAMEPDD.SYS to work with your Thrustmaster Joystick. This will take some time and effort for me to accomplish. For starters I am thinking of an ioctl interface for gamepads/joysticks into GAMEPDD.SYS to be used by some program that uses USBECD.SYS to access your Thrustmaster Joystick. When I succeed then perhaps this could also be an alternative way for DOSBox to be used. Although for DOSBox it is better that someone gets HIDAPI to work well.

I had a look at your output analysis and it looked like you were playing a game of Tic-Tac-Toe <grin>

Personally I doodle thoughts when I'm doing a project - I've done some graphics design so many times I think in pictures.

Putting my project management hat on, I was suggesting a simple proof of concept to start, to see if we can get things talking.

If you think Dave's current port of HDIAPI would work perhaps the way to go would be that method, if we could also get it talking to DOSBox. Or being able to address a simple CMD style calibration program natively in ArcaOS (symbols or numbers appear when the joystick is manipulated, or button pressed)

Again being a programming expert (IOW you didn't duck fast enough when the job was suggested) in your opinion, would either of those types of suggestions be limited intensity in terms of effort?. Or can you suggest from your paths above a simple method to test whether we're getting the joystick recognized?

Looking at both methods you suggested, I will have to say that there are limited ways to test joysticks under ArcaOS natively at the moment, and most likely in future (Stardock used to retail a program called Trials of Battle which I do have but not loaded on my systems at the moment, which I could get running again)

As per discussion DOSBOX is supposed to recognize a joystick if the host operating system does and the device conforms to the specifications noted previously, which would be why the HIDAPI option may be attractive - I have at least 12 DOS flight and warfare games (eg. Mechwarrior) running through DOSBOX now, with Joystick capability, which may be candidates to see if that option may work.

Unless you think this will be fun and challenging, and yet another interesting test of USBECD capabilites, I'm not trying to fob a job off on you - would do it myself if I had the programming skills.

There's an old quote attributed to Pliny the Elder, Wim, which I have taped on the wall above my screen "Age takes on things that youth will not do, because they say it will take too long"

A fine day to you Sir and Best!

Mark