DOS VDM - USB and Game port Gamepad support

[Mark Szkolnicki]

Hi Wim!

Tried the lsusb output you requested first - produced a text file with nothing in it - I've attached a JPG of the window when I ran that - perhaps the syntax was wrong?

M

[Mark Szkolnicki]

Hi Wim!

Tried xeventsF1a, and at the beginning, trying twice all it produced was:

Packet=EEEEEEEEEEEEEEEE,Huh?

After that it started producing different output - not quite sure what changed.

xevents output attached.

M

[Wim Brul]

Hi Mark,

Hi Wim!

Tried xeventsF1a, and at the beginning, trying twice all it produced was:

Packet=EEEEEEEEEEEEEEEE,Huh?

After that it started producing different output - not quite sure what changed.

xevents output attached.

M

Oops, I changed the wrong character again. This is what one gets when one cannot test by oneself first.

In both xeventsF1a.cmd (line 67) and xeventsF2a.cmd (line 63) locate the following code:

Code: [Select]

  report=c2x(substr(oiBuffer,8+2,8))

And change that code into the following (two characters to be changed):

Code: [Select]

  report=c2x(substr(oiBuffer,8+8,1))

What you saw was the result of 4 seconds default timeout present in the code.
The EEEEEEEEEEEEEEEE packets signify no input and will be ignored.

Cheers, Wim.

[Mark Szkolnicki]

Hi Wim!

Found the problem with lsusb this morning - a stray colon was present when I pasted your statement, which was located between the -d switch and the vendor hex code.

The lsusb report was generated this time and is attached

[Mark Szkolnicki]

Hi Wim!

Have more to report, for the new Joystick

My previous post gave you the complete lsusb data for the T.Flight. Let me know if I can generate any additional reports for you.

I made the modifications you indicated to the two xevents files (xeventsF1a and xeventsF2a), and xeventsF1a did generate output, which I will relate below. (have not tested xeventsF2a yet).

I also was able to generate a code output listing for each control, which includes the following:

Buttons 1-10
Hat N, S, W, E
Slider on the base
Joystick Axis Movement N,S,W,E

I have attached a text file called T.Flight Control Assignments.txt to this post, which has the code lines separated out by control, both press and release.

I will say that it took a while to generate, as oinputF1a addressing of each control was sometimes sporatic - sometimes it took 2 or more presses of the buttons, especially, to generate the code. I've attached an oinputf1a.log file, which essentially follows the Control Assignment .txt file, if it is useful.

I have also generated two xevents.log files - because of the sporatic nature related to responding to key presses by xeventsF1b - one for buttons 1 to 8 and the other for button 9, the hat and joystick movement. For some reason Button 10 would not respond in xeventsF1a to any key presses, although it was pressed multiple times in the file - the "Huh" codes appeared when I attempted to move the hat control to the east - the rest of the hat movements generated the output noted in the log.

With your modifications I was able to run TMScope and generate output on the displays - Buttons 1 to 4 reported normally, Buttons 5 to 8 on the base reported as buttons 1-4. Buttons 9 and 10 generated no display output at all.

The T.Flight hat did not generate any output on the TMScope hat display. I was able to move the joystick in all directions, to the maximum of display travel. I should note this was using  the same joystick hardware settings used for my original joystick.

Interestingly, I also encountered the "Loss of Focus" problem noted with the previous joystick, which was again solved by pressing any key on the keyboard. As well, I noted pressing the "Port Speed" button on the right hand side of TMScope that the subjective Port Speed was higher than the older Joystick but only a little.

I'll leave it there for the moment, as that was a lot of testing for the day, in between other matters. If you have any questions let me know and Best!

Mark

[Wim Brul]

Hi Mark,

Thank you for your efforts. From the lsusb report I learned that its input reports are only 7 bytes long. Right now we obtain 8 byte input records and check the 8th byte for certain values. That is why those HUH? packets were encountered. Although it would be best to change xeventsF1a.cmd to work with 7 byte input records, I modified xeventsF1a.cmd into xeventsF1b.cmd to stay at working with 8 byte packets and to ignore these Huh? packets for the time being. That would be the next step when I find more time.

With xeventsF1b.cmd buttons 5,6,7,8 are mapped into buttons 1,2,3,4 as these were before and buttons 9,10 are ignored as these were before. I have added the lacking hat movement. The z-axis movement is now ignored. I also changed the 4 seconds default timeout while obtaining input reports into infinite timeout. Perhaps that helps to cure the "Lost of Focus" problem. Other measures to cure the "Lost of Focus" problem could be to remove the logging functionality altogether or even write an assembly program like I did for the bamboo and intuos finger and pen tablets.

Best, Wim.

[Mark Szkolnicki]

Hi Wim!

Hi Mark,

Thank you for your efforts. From the lsusb report I learned that its input reports are only 7 bytes long. Right now we obtain 8 byte input records and check the 8th byte for certain values. That is why those HUH? packets were encountered. Although it would be best to change xeventsF1a.cmd to work with 7 byte input records, I modified xeventsF1a.cmd into xeventsF1b.cmd to stay at working with 8 byte packets and to ignore these Huh? packets for the time being. That would be the next step when I find more time.

Interesting - I expected changes, as Windows has advanced and most games and associated device drivers for game controllers are written for Windows.

As Linux users wrote HIDAPI, I expected they encountered that problem for game controllers - I wonder what they did related to that, especially as there is a Linux version of DOSBOX.

With xeventsF1b.cmd buttons 5,6,7,8 are mapped into buttons 1,2,3,4 as these were before and buttons 9,10 are ignored as these were before. I have added the lacking hat movement. The z-axis movement is now ignored. I also changed the 4 seconds default timeout while obtaining input reports into infinite timeout. Perhaps that helps to cure the "Lost of Focus" problem. Other measures to cure the "Lost of Focus" problem could be to remove the logging functionality altogether or even write an assembly program like I did for the bamboo and intuos finger and pen tablets.

Best, Wim.

Will take xeventsF1B out for a spin later and report back - frankly, considering this is ArcaOS we're talking about, I expect what I have in the way of controls on both Thrustmasters (4 buttons, hat and joystick movement is all that will be needed anyway for any DOS based game, as they didn't consider having a myriad of keys and controls present - it is very unlikely that anyone will be updating existing or creating new very complex games that are ArcaOS/eCs/OS/2 native using this many controls.

After all, when Martin created this thread, it was about DOS VDM's - I doubt he considered the monster he resurrected with those few first simple comments ............!

A fine weekend to you, Sir and Best!

M

[Mark Szkolnicki]

Hi Wim!

With xeventsF1b.cmd buttons 5,6,7,8 are mapped into buttons 1,2,3,4 as these were before and buttons 9,10 are ignored as these were before. I have added the lacking hat movement. The z-axis movement is now ignored. I also changed the 4 seconds default timeout while obtaining input reports into infinite timeout. Perhaps that helps to cure the "Lost of Focus" problem. Other measures to cure the "Lost of Focus" problem could be to remove the logging functionality altogether or even write an assembly program like I did for the bamboo and intuos finger and pen tablets.

Best, Wim.

Tried xeventsF1b and found the mapping to be as you mentioned with one exception.

Using TMScope I found that the hat, when manipulated in any direction (N,S,W,E) always pointed to the north on the hat display - still had Loss of Focus.

Running Comanche could not get the hat to work - as north is the front facing position, that is not surprising. I did try the Slider in F1a and it actually changed directional looks out of the cockpit similar to pressing the hat with the old joystick - however with F1b that is no longer an issue.

Running Castle Wolfenstein - both buttons 0 and 1 (Trigger 0 and Button 1, as identified in the game) functioned - for some reason although B3 is mapped when you originally install the game, after calibrating the joystick I cannot get it to be identified afterwards. Loss of Focus was again noted requiring keyboard presses, but I tend to use the arrow keys more than the joystick for movement, as a joystick really is too sensitive on a new system for tiny adjustments (tends to move too fast when trying to focus on the enemy). However for firing and opening doors the buttons are perfect.

The button 0 and 1 recognition only is not new - the older Thrustmaster also has that problem in Wolfenstein.

I'm going to try to re-calibrate with the new joystick when I get as chance and see if that solves the problem - still have that annoying problem of Wolfenstein 3D not starting up properly (need to press keys continually  for about 2-3 minutes to enter the game), but once that is over, it affects nothing for testing purposes.

All for now and Best, Sir!

M

[Wim Brul]

Hi Mark,

Using TMScope I found that the hat, when manipulated in any direction (N,S,W,E) always pointed to the north on the hat display - still had Loss of Focus.

I have modified xeventsF1b.cmd into xeventsF1c.cmd such that hat positional values are larger than before. Since TMScope averages hat values, be slow on input.

Running Castle Wolfenstein - both buttons 0 and 1 (Trigger 0 and Button 1, as identified in the game) functioned - for some reason although B3 is mapped when you originally install the game, after calibrating the joystick I cannot get it to be identified afterwards.

Wolfenstein 3D requires both "Joystick Enabled" and "Gravis GamePad Enabled" for B2 and B3 to be recognized. Once I did that, pressing B3 worked for me.

Loss of Focus was again noted requiring keyboard presses, but I tend to use the arrow keys more than the joystick for movement, as a joystick really is too sensitive on a new system for tiny adjustments (tends to move too fast when trying to focus on the enemy). However for firing and opening doors the buttons are perfect.

I am currently working on a new version of gamevdd.sys and gamedd.sys such that joystick speed is reduced. With it, joycheck.exe works alright on my laptop.

Best regards, Wim.

[Mark Szkolnicki]

Hi Mark,

I have modified xeventsF1b.cmd into xeventsF1c.cmd such that hat positional values are larger than before. Since TMScope averages hat values, be slow on input.

Tried xeventsf1c and it was slightly better with hat function - pointing N with the hat registered as north on the TMScope hat display - however, pointing W, S or E all pointed East.

Running Comanche 2, the program is indeed recognizing the hat on the newer Thrustmaster - I can still see north, but pushing any of the other hat directions with the new joystick has me glancing right (which corresponds to the east hat direction).

I know that with the xevents.cmd designed for the older Thrustmaster Joystick, the hat worked perfectly, other than the Loss of Focus problem - would you like me to modify the newest xeventsF1c to address the older joystick and test that?

Wolfenstein 3D requires both "Joystick Enabled" and "Gravis GamePad Enabled" for B2 and B3 to be recognized. Once I did that, pressing B3 worked for me.

Never occurred to me to enable the gamepad as well, Wim, as I've never used one - but it would make sense - Wolfenstein is such an old game, that it was probably designed with a two button joystick in mind, unlike Comanche 2 - tried that this morning and now have buttons B0-B3 mapped to the new joystick - I assume it will work with the older Thrustmaster as well. So I have inputs into Wolfenstein from mouse, keyboard, and joystick. Will test later today to see if I note anything new.

I'm also curious as to whether you ever attempted to run Wolfenstein 3D under DOSBOX?

When I do, the program works perfectly including sound and indicates the presence of a Joystick, but I cannot calibrate it, as none of the controls on the newer joystick seem to address the program. This same behaviour was present when I attempted to test DOSBOX with the older joystick as well.

As DOSBOX is SDL based it may be a problem with HIDAPI or something else, but I seem to recall Jochan mentioning that he has a gamepad enabled on games running under DOSBOX, so I was just curious as to whether the problem there is based on some tweaks being needed to DOSBOX or whether its about the new game controller drivers needing to address DOSBOX?

Best of the weekend to you, Sir!

M

[Jochen Schäfer]

As DOSBOX is SDL based it may be a problem with HIDAPI or something else, but I seem to recall Jochan mentioning that he has a gamepad enabled on games running under DOSBOX, so I was just curious as to whether the problem there is based on some tweaks being needed to DOSBOX or whether its about the new game controller drivers needing to address DOSBOX?

Mark, you seem to have mixed things up a little ;-)

SDL 1, which is used by DOSBOX, has native joytisck support, so in theory Wim's USB drivers should be available in SDL 1.
SDL 2 has HIDAPI support for gamepads only. I only ported Prboom with SDL 2 and there I had gamepad tested and working.

Bye Jochen

[Mark Szkolnicki]

Hi Jochen!

As DOSBOX is SDL based it may be a problem with HIDAPI or something else, but I seem to recall Jochan mentioning that he has a gamepad enabled on games running under DOSBOX, so I was just curious as to whether the problem there is based on some tweaks being needed to DOSBOX or whether its about the new game controller drivers needing to address DOSBOX?

Mark, you seem to have mixed things up a little ;-)

SDL 1, which is used by DOSBOX, has native joytisck support, so in theory Wim's USB drivers should be available in SDL 1.
SDL 2 has HIDAPI support for gamepads only. I only ported Prboom with SDL 2 and there I had gamepad tested and working.

Bye Jochen

Apologies if I'm not up on the nature of HIDAPI, Jochen, as I'm not a programmer - merely a beta tester.

If DOSBOX is indeed SDL1 based, seems to be working perfectly on my systems, and I have the joystick support enabled in DOSBOX, and Wolfenstein 3D seems to see the joystick (which did not occur without Wim's drivers) can you think of a reason why none of the joystick controls can be seen by DOSBOX?

For testing purposes I have a much wider range of DOSBOX enabled DOS games available - I've tried 4 different games which have joystick control functions as well as TMScope through DOSBOX and none of the joystick controls are seen by the programs.

Perhaps I have not set up the joystick support correctly and need to need to play around a bit with the conf settings, related to the joystick - any suggestions, Sir?

Best of the weekend to you!

Mark

[Wim Brul]

Hi Mark,

Tried xeventsf1c and it was slightly better with hat function - pointing N with the hat registered as north on the TMScope hat display - however, pointing W, S or E all pointed East.

Running Comanche 2, the program is indeed recognizing the hat on the newer Thrustmaster - I can still see north, but pushing any of the other hat directions with the new joystick has me glancing right (which corresponds to the east hat direction).

I know that with the xevents.cmd designed for the older Thrustmaster Joystick, the hat worked perfectly, other than the Loss of Focus problem - would you like me to modify the newest xeventsF1c to address the older joystick and test that?

No need for you to modify xeventsF1c.cmd to test with the older joystick. You got me already its hat input values. I looked at it again and it appears that even higher hat position values are required. So I modified xeventsF1c.cmd into xeventsF1d.cmd to do that. You will find it in gamepad-20220507.zip attached.

As mentioned earlier, I am currently working on a new version of gamevdd.sys and gamedd.sys such that joystick speed is reduced. With it, joycheck.exe works alright on my laptop. This version is still very experimental. I removed the GAME_DIRECT_ACCESS property and added tracing (trace code 232). I am slowly learning how it works altogether. To update your installation of gamepad-20220317.zip you need to copy *.sym and *.sys files to \OS2\MDOS and copy TRC00E8.TFF to \OS2\SYSTEM\TRACE and to reboot your system.

Cheers, Wim.

[Mark Szkolnicki]

Hi Wim!

As mentioned earlier, I am currently working on a new version of gamevdd.sys and gamedd.sys such that joystick speed is reduced. With it, joycheck.exe works alright on my laptop. This version is still very experimental. I removed the GAME_DIRECT_ACCESS property and added tracing (trace code 232). I am slowly learning how it works altogether. To update your installation of gamepad-20220317.zip you need to copy *.sym and *.sys files to \OS2\MDOS and copy TRC00E8.TFF to \OS2\SYSTEM\TRACE and to reboot your system.

Cheers, Wim.

Installed the files you provided.

All control functions work under TMScope including the hat functions in all directions with xeventsf1d - I did notice that Loss of Focus did occur more frequently probably about every 5-10 seconds, but I'm only reporting that as you mentioned how experimental the new drivers are.

Running Comanche 2, the hat functions now work perfectly - haven't tested Wolfenstein 3D yet.

As I'm not sure what other input would be useful let me know what you require and Best!

M

[Mark Szkolnicki]

Hi Jochen!

SDL 1, which is used by DOSBOX, has native joytisck support, so in theory Wim's USB drivers should be available in SDL 1.
SDL 2 has HIDAPI support for gamepads only. I only ported Prboom with SDL 2 and there I had gamepad tested and working.

Bye Jochen

It was a blustery windy day out here today, in Collingwood Cove, so I had some time inside to play with some of the DOSBOX conf settings and found the following:

Switching Joystick type on the config file on DOSBOX to:
(with Wims xevents for this joystick enabled)

joysticktype=2 axis - joystick was recognized by Wolfenstein 3D - could not calibrate
joysticktype=4 axis - joystick was recognized by Wolfenstein 3D - could not calibrate
joysticktype=fcs (which is what my older joystick is) - joystick was recognized by Wolfenstein 3D - could not calibrate
joysticktype=ch - joystick was recognized by Wolfenstein - could not calibrate
joysticktype=auto - joystick was NOT recognized by Wolfenstein 3D

So not quite sure if that is related to Wim's drivers, something in SDL1, or DOSBOX itself, but as I've mentioned this is beta testing - so thought I'd add another data point to the mix.

M