Author Topic: DOS VDM - USB and Game port Gamepad support  (Read 203288 times)

Mark Szkolnicki

  • Sr. Member
  • ****
  • Posts: 454
  • Karma: +18/-0
    • View Profile
Re: DOS VDM - USB and Game port Gamepad support
« Reply #240 on: May 18, 2022, 03:55:48 am »
Hi Sigurd!

Happy birthday to All of you as well! Wim I celebrated my 56 birthday last saturday as well... :D  That is really funny! :)

As always Spring is the season of many births - probably because fall is such a cold time ....... !

I share my birthday with two relatives ........ and the mother of a very dear friend.

My wife's sister shares her birthday with my youngest brother (March 24) - her brother shares his birthday with my middle brother (April 14) - fate, the stars, or sheer coincidence?

Regardless, best to all with birthdays in May, whether they share them or no, and a fine week!

M
Vincit Que Se Vincit - "He Who Conquers Self Succeeds"

Martin Iturbide

  • OS2World NewsMaster
  • Global Moderator
  • Hero Member
  • *****
  • Posts: 4941
  • Karma: +44/-1
  • Your Friend Wil Declares...
    • View Profile
    • Martin's Personal Blog
Re: DOS VDM - USB and Game port Gamepad support
« Reply #241 on: May 18, 2022, 02:06:36 pm »
Unfortunately, there seems to be little in the way of native OS/2 derived items to test and Best!

In other words, do we need something like "JoystickTestUtils_1998-04-01.zip" but instead of DOS, for OS/2 native?

Regards
Martin Iturbide
OS2World NewsMaster
... just share the dream.

Mark Szkolnicki

  • Sr. Member
  • ****
  • Posts: 454
  • Karma: +18/-0
    • View Profile
Re: DOS VDM - USB and Game port Gamepad support
« Reply #242 on: May 18, 2022, 10:17:10 pm »
Hi Martin!

Unfortunately, there seems to be little in the way of native OS/2 derived items to test and Best!

In other words, do we need something like "JoystickTestUtils_1998-04-01.zip" but instead of DOS, for OS/2 native?

Regards

I doubt such a utility exists, but it would be useful.

We now have connections between the game controllers (pads and joysticks) and DOS VDM's and games running under DOSBOX, so we certainly have proof of concept there - I doubt having these drivers are going to get anyone to start developing interesting complex games native for ArcaOS / eCS / OS/2 - but perhaps there are ports from Linux of originally Windows based games which may be able to get to run natively under this operating system.

The DOS based games have been a good test, as a plethora of them exist right now, which can be tested right "out of the box", literally - porting complex games I suspect is a lot more onerous process.

That why I wanted to test Makman - if a joystick is recognized there, at least we know a connection exists, joystick wise, natively - I may try Trials of Battle again, for interests sake as well.

M
Vincit Que Se Vincit - "He Who Conquers Self Succeeds"

Mark Szkolnicki

  • Sr. Member
  • ****
  • Posts: 454
  • Karma: +18/-0
    • View Profile
Re: DOS VDM - USB and Game port Gamepad support
« Reply #243 on: May 18, 2022, 10:29:11 pm »
Quote
Just installed your new gamepad driver set (gamepad-20220511) and have ran into a problem in DOSBOX in Wolfenstein.

Start-up is fine and runs through the start-up screens (3) as per normal, but then the game immediately shows the messages for ending or continuing the program, where the response Y or N is required. Typing N simply goes to an alternate version of the same shutdown challenge. Typing Y ends the program.
When I implemented the missing functions I made a mistake. This resulted into all 4 buttons being signalled as being pressed on startup. Fixed now.

Quote
Hat functions on the Thrustmaster joysticks still not being recognized under DOSBOX
Perhaps I made another mistake. I did some experimenting and failed to change some values back the way these were before. Try the attached version.

Like before you need to copy *.sym and *.sys files to \OS2\MDOS and copy TRC00E8.TFF to \OS2\SYSTEM\TRACE and then reboot your system.

Wim.

gamepad-20220517 did indeed clear up the problem with Wolfenstein under DOSBOX - the hat functions still don't work with either of the Joysticks, when tested under TMScope, and aren't also recognized running Comanche 2 under DOSBOX.

Both work fine on TMScope running under a DOS VDM, including the hat functions.

I now have Mechwarrior 2 working correctly under DOSBOX so will also try running some training missions there, with the joysticks. I also am hoping to try Makman when I have some time to download it, and take a little more time with Trials of Battle under native ArcaOS to see if I can describe exactly what the problem is I'm seeing - perhaps someone has a clue as to what may be done to get that working for testing purposes.

Best!

Mark

M
Vincit Que Se Vincit - "He Who Conquers Self Succeeds"

Mark Szkolnicki

  • Sr. Member
  • ****
  • Posts: 454
  • Karma: +18/-0
    • View Profile
Re: DOS VDM - USB and Game port Gamepad support
« Reply #244 on: May 19, 2022, 10:28:55 pm »
Hi Wim!


Perhaps I made another mistake. I did some experimenting and failed to change some values back the way these were before. Try the attached version.

Like before you need to copy *.sym and *.sys files to \OS2\MDOS and copy TRC00E8.TFF to \OS2\SYSTEM\TRACE and then reboot your system.


I decided to try a little change-up today and downloaded the Makman game Martin was testing and run it - I was able to enable the joystick settings and run both joysticks successfully (I only tried them separately, not together) in the game, using the latest xevents for the older Mk 2 Thrustmaster and xeventsf1d for the T. Flight. Driver set was gamepad-20220517.

No identified problems, but then again it is a simple Pacman clone, so just X-Y axis movement of the joystick - no buttons or hat involved, to do anything else.

But an important step nonetheless - it seems all USB game controllers tested are seen by ArcaOS and a native OS/2 based game, as simple as it is.

I tried Trials of Battle again and it hangs hard when you enter the arena, video wise, requiring a hard reboot (Ctrl-Alt-Del not working - need to hit the hardware reset switch and reboot). I don't think the problem is related to the GAMEDD driver - entering the arena the video lock-up occurs about 10 seconds into the battle usually (no keyboard, mouse or joystick input accepted) - occasionally the timing is longer, but the amount of time working is usually hit and miss.

Reading on the Stardock site about Trials of Battle, it uses DIVE video support:

DIVE For a modern first person action game to succeed, good video performance is a must! Trials of Battle delivers great graphics combined with great frame-rates (on a high end 486DX2 or better) to keep in immersed in the Trials of Battle world! 

I am using Panorama, latest version, on ArcaOS v5.0.7 on my test system here, so don't know if it implements DIVE well, if at all - I seem to recall that SNAP used to do so, so don't know if changing video drivers may help out in getting the game to work - anyone have any ideas or suggestions?

Best!

Mark





« Last Edit: May 19, 2022, 10:30:39 pm by Mark Szkolnicki »
Vincit Que Se Vincit - "He Who Conquers Self Succeeds"

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4987
  • Karma: +110/-1
    • View Profile
Re: DOS VDM - USB and Game port Gamepad support
« Reply #245 on: May 20, 2022, 02:00:51 am »
You could try disabling the shadow buffer in the screen object as a test. Graphics will be slow until you re-enable it.

Mark Szkolnicki

  • Sr. Member
  • ****
  • Posts: 454
  • Karma: +18/-0
    • View Profile
Re: DOS VDM - USB and Game port Gamepad support
« Reply #246 on: May 20, 2022, 03:12:23 am »
Heh Dave!

You could try disabling the shadow buffer in the screen object as a test. Graphics will be slow until you re-enable it.

Tried TOB three times, after disabling the shadow buffer - had a hard lock after about 5 seconds on the keyboard each time I entered the battle zone, requiring a hard reset - did not enable Wim's xevent.cmd files.

M
Vincit Que Se Vincit - "He Who Conquers Self Succeeds"

Wim Brul

  • Sr. Member
  • ****
  • Posts: 296
  • Karma: +25/-0
    • View Profile
    • Wim's home page
Re: DOS VDM - USB and Game port Gamepad support
« Reply #247 on: May 20, 2022, 02:55:43 pm »
Hi Mark and Jochen,

Running TMScope in DOSBox and VDM gives different results. This occurs because DOSBox obtains calibration values from gamedd.sys and recalculates axes values whereas with VDM no such calculations occur. Unfortunately the recalculation algorithm in SDL_os2joystick is horribly wrong. It is so wrong that it even hangs my laptop when proper calibration values (lower=0, center=128. upper=255 for axes ranging from 0 to 255) are being used. And that is eactly the range of axes values that are currently used. The reason it still works, sort of, is that in gamepad-20220517 calibration values lower=(7*128)/10, center=128+25, upper=(13*128)/10 are being used. That is after my tweaking. Before that center=128 was used which gave even worse readings in TMScope in DOSBox.

My proposed algorithm in rexx code form is as follows:

Code: [Select]
/* proposed algorithm SDL-DOSBox */
SDL_JOYSTICK_AXIS_MAX = +32767
SDL_JOYSTICK_AXIS_MIN = -32768

/* calibration values */
axis_lower = 0
axis_center = 128
axis_upper = 255

/* preparation */
offset = axis_center
scale1 = SDL_JOYSTICK_AXIS_MIN / (axis_lower - axis_center)
scale2 = SDL_JOYSTICK_AXIS_MAX / (axis_upper - axis_center)

/* apply input values and show output values */
do axis = axis_lower to axis_upper
  /* recalculate axis value */
  if (axis < axis_center)
  then value = (axis - offset) * scale1
  else value = (axis - offset) * scale2
  /* show axis input and output values */
  say axis value
end

Best regards,
Wim.
« Last Edit: May 20, 2022, 09:26:00 pm by Wim Brul »

Jochen Schäfer

  • Sr. Member
  • ****
  • Posts: 361
  • Karma: +29/-0
    • View Profile
Re: DOS VDM - USB and Game port Gamepad support
« Reply #248 on: May 20, 2022, 04:41:20 pm »
Hi Wim.

What would be the correct algorithm? Since we have the code, we could fix that. Most likely the code in SDL2 is also wrong, because it is a straight port of the SDL1 code.


Bye Jochen

Mark Szkolnicki

  • Sr. Member
  • ****
  • Posts: 454
  • Karma: +18/-0
    • View Profile
Re: DOS VDM - USB and Game port Gamepad support
« Reply #249 on: May 20, 2022, 06:25:34 pm »
Hi Wim!


Hi Mark and Jochen,

Running TMScope in DOSBox and VDM gives different results. This occurs because DOSBox obtains calibration values from gamedd.sys and recalculates axes values whereas with VDM no such calculations occur. Unfortunately the recalculation algorithm in SDL_os2joystick is horribly wrong. It is so wrong that it even hangs my laptop when proper calibration values (lower=0, center=128. upper=255 for axes ranging from 0 to 255) are being used. And that is eactly the range of axes values that are currently used. The reason it still works, sort of, is that in gamepad-20220517 calibration values lower=(7*128)/10, center=128+25, upper=(13*128)/10 are being used. That is after my tweaking. Before that center=128 was used which gave even worse readings in TMScope in DOSBox.

My proposed algorithm in rexx code form is as follows:

Code: [Select]
/* proposed algorithm SDL-DOSBox */
SDL_JOYSTICK_AXIS_MAX = +32767
SDL_JOYSTICK_AXIS_MIN = -32768

/* calibration values */
axis_lower = 0
axis_center = 128
axis_upper = 255

/* preparation */
offset = axis_center
scale1 = SDL_JOYSTICK_AXIS_MIN / (axis_lower - axis_center)
scale2 = SDL_JOYSTICK_AXIS_MAX / (axis_upper - axis_center)

/* apply input values and show output values */
do axis = axis_lower to axis_upper
  if (axis < axis_center)
  /* recalculate axis value */
  then value = (axis - offset) * scale1
  /* show axis input and output values */
  else value = (axis - offset) * scale2
  say axis value
end

Best regards,
Wim.

Interesting, Wim 

I actually find that whatever your doing is working for my joysticks, jury rig or no - I was playing Wolfenstein under DOSBOX for 2 hours last night, switching Joysticks half way, and no loss of focus, or joystick problems at all - however in comparison to the more complex games where more controls are required, it is really a simple test.

Personally I've not noted any TMScope problems under DOSBOX other than hat function, but I take your word for it, not being a programmer that the algorithms could be a mess. I should have a look more closely at the RAW_DATA screen being generated here for my sticks and send you the travel data for both joysticks.

After your explanation above I wanted to add another data point for you into the mix.

As mentioned I did get Mechwarrior 2 running under DOSBOX - it is a very difficult program to set up under a DOS VDM so it is hard to install it there for comparison purposes. (one of the reasons I use DOSBOX is that things just work almost immediately, complex or no.

The data point I wanted to relate was a comparison between the last xevents which we created for the old Mk II Thrustmaster amd xeventsf1d, which I'm using to run the T.Flight.

Running the training missions (there are four in the game), the older Thrustmaster performs beautifully - stable movement, crisp response on the movement and buttons - no hat functions, but we know about that.

Using the newer xeventsf1d and the T. Flight, sitting in place is quite jittery even after re-calibrating the joystick - controls work but you do see on movement the jitter effect, requiring a fair amount of course correction, which I do not need to do with the older joystick with the older xevents.

I don't know if you think that has any significance, Wim or whether it may be simply that the newer Joystick is more sensitive and has faster response. Is there much difference in the two command files, now, after your modifications? I was thinking of modifying the newer f1d file for use with the older joystick and testing that out - would that be easily feasible?

I should mention also that I chose Mechwarrior 2 as a new advanced test program as it actually has support for the Thrustmaster Mk 2 built in, and the T.Flight seems in other games to follow along nicely with testing of the older Thrustmaster in other games.

I'm almost tempted to see if I can find another of the T.Flight Thrustmasters and ship it to you for testing yourself - I found mine on eBay for a good price - new here they run about $95.00 Cnd - got mine for around $35.00 Cnd used.

I was also curious as to what happens when you get the lock on your laptop?

I'm actually running tests on a tower, with an AMD hexcore processor and 3 Gb of usable memory installed (actually 8 GB in the system, but ArcaOS is not seeing the rest). Occasionally after installing the gamepad package previous to 2022-05-17 and with the current one, I've gotten a black screen trap, attempting to start a game with one of the xevents packages active.

I've attached a photo of the trap screen, if it is of any help - I have not determined a particular reason why it happens at the moment as I've only seen it four times and Best!

M

Vincit Que Se Vincit - "He Who Conquers Self Succeeds"

Wim Brul

  • Sr. Member
  • ****
  • Posts: 296
  • Karma: +25/-0
    • View Profile
    • Wim's home page
Re: DOS VDM - USB and Game port Gamepad support
« Reply #250 on: May 20, 2022, 09:47:19 pm »
Hallo Jochen,
What would be the correct algorithm? Since we have the code, we could fix that. Most likely the code in SDL2 is also wrong, because it is a straight port of the SDL1 code.
I think that my proposed algorithm is the correct algorithm. See my original post.

First the calculation of the offset, scale1 and scale2:
Code: [Select]
offset = axis_center
scale1 = SDL_JOYSTICK_AXIS_MIN / (axis_lower - axis_center)
scale2 = SDL_JOYSTICK_AXIS_MAX / (axis_upper - axis_center)

Followed by the recalculation for all axes:
Code: [Select]
if (axis < axis_center)
then axis = (axis - offset) * scale1
else axis = (axis - offset) * scale2

This has of course to be substituted in SDL_os2joystick.c at the right places. Too difficult for me to do.

Cheers,
Wim.

Mark Szkolnicki

  • Sr. Member
  • ****
  • Posts: 454
  • Karma: +18/-0
    • View Profile
Re: DOS VDM - USB and Game port Gamepad support
« Reply #251 on: May 20, 2022, 11:11:07 pm »
Hi Wim!

Have guests tonight, but just finished cooking the menu with 3 hours to spare, so did get a chance to test both joysticks here under TMScope, both DOS VDM and DOSBOX, using the RAW_DATA provided:

I tested each three times, doing Recal TMS each time between each test and got the following RAW_DATA, DOS VDM TMScope vs TMScope under DOSBOX:

Mk2 Thrustmaster (using xevents, last edit)

                            DOS VDM                                  DOSBOX

               Min         Centre        Max           Min         Centre        Max

X1             4              75           146             5              92            205
                 4              76           146             6              92            207   
                 4              77           146             6              92            207
Y1             5              87           145             6             103          182
                 4              87           143             6              97           182
                 6              90           143             6             100          182

Moving the Joystick to the south (Y1) in the DOS VDM, it would only go 4 notches of 7 in that direction with the output above - this has been the same since we started testing using this program - EDIT: just did this test under DOSBOX - went five notches south of 7. Otherwise full travel in the other directions.

T. Flight (using xeventsf1d)

                          DOS VDM                                    DOSBOX

               Min         Centre        Max           Min         Centre        Max

X1           1              129           256             5             123           234
               1              129           256             6             123           234
               1              131           256             6             124           234

Y1           1              129          256             6              124           233
               1              129          256             6              124           234
               1              129          256             6              124           234

In the case of the DOSBOX TMScope X1 showed the data above moving 6 notches of 7 east. Y1 showed the data above moving 6 notches of 7 south. Otherwise full travel on the display in the other directions.

All done under the latest gamepad. Don't know if that provides anything useful but thought I'd add it to the mix and Best!

M
« Last Edit: May 20, 2022, 11:58:42 pm by Mark Szkolnicki »
Vincit Que Se Vincit - "He Who Conquers Self Succeeds"

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4987
  • Karma: +110/-1
    • View Profile
Re: DOS VDM - USB and Game port Gamepad support
« Reply #252 on: May 21, 2022, 12:57:02 am »

I'm actually running tests on a tower, with an AMD hexcore processor and 3 Gb of usable memory installed (actually 8 GB in the system, but ArcaOS is not seeing the rest). Occasionally after installing the gamepad package previous to 2022-05-17 and with the current one, I've gotten a black screen trap, attempting to start a game with one of the xevents packages active.

I've attached a photo of the trap screen, if it is of any help - I have not determined a particular reason why it happens at the moment as I've only seen it four times and Best!


Hi Mark, that is a weird trap as it is a breakpoint, probably code that should never be reached and perhaps worth opening an issue with Arca Noae, especially if you could get a system dump of it. Unluckily if it is only occasionally trapping, it'll be hard to get a good dump as rally you should lower your memory, 3GB dump is big.

Mark Szkolnicki

  • Sr. Member
  • ****
  • Posts: 454
  • Karma: +18/-0
    • View Profile
Re: DOS VDM - USB and Game port Gamepad support
« Reply #253 on: May 21, 2022, 04:26:01 am »

I'm actually running tests on a tower, with an AMD hexcore processor and 3 Gb of usable memory installed (actually 8 GB in the system, but ArcaOS is not seeing the rest). Occasionally after installing the gamepad package previous to 2022-05-17 and with the current one, I've gotten a black screen trap, attempting to start a game with one of the xevents packages active.

I've attached a photo of the trap screen, if it is of any help - I have not determined a particular reason why it happens at the moment as I've only seen it four times and Best!


Hi Mark, that is a weird trap as it is a breakpoint, probably code that should never be reached and perhaps worth opening an issue with Arca Noae, especially if you could get a system dump of it. Unluckily if it is only occasionally trapping, it'll be hard to get a good dump as rally you should lower your memory, 3GB dump is big.

Heh Dave!

As I have not seen a lot of it, other than in this thread, I think I would give it a miss - if I can find a reason for it that would affect everyone I certainly would report it, if it is the system and not what we are testing - I think I would like to know why first and a fine weekend, as always!

M
Vincit Que Se Vincit - "He Who Conquers Self Succeeds"

Lars

  • Hero Member
  • *****
  • Posts: 1352
  • Karma: +69/-0
    • View Profile
Re: DOS VDM - USB and Game port Gamepad support
« Reply #254 on: May 21, 2022, 09:32:43 am »
I'm actually running tests on a tower, with an AMD hexcore processor and 3 Gb of usable memory installed (actually 8 GB in the system, but ArcaOS is not seeing the rest). Occasionally after installing the gamepad package previous to 2022-05-17 and with the current one, I've gotten a black screen trap, attempting to start a game with one of the xevents packages active.

I've attached a photo of the trap screen, if it is of any help - I have not determined a particular reason why it happens at the moment as I've only seen it four times and Best!

M

It`s a trap 3 which means it is a hard coded int3 breakpoint, put there deliberately by the programmer. The reason it fires is that something is calling/jumping to address 1000:0, that is, a ZERO offset. Since this is not expected and likely is a programmer error in that somebody tries to do an indirect near call/jump with a near NULL pointer, that is caught by this breakpoint.
Note that the trap address is 1000:0001 because for an int3 the trap screen will show the address of the instruction following the int3 and the int3 instruction is 1 byte long.

In order to analyze that, you´d need a trap dump in order to find out what code tried to call/jump to 1000:0 (or rather do an indirect near call/jump with a near NULL pointer).

Thinking about it: selector 1000 points to the DOSCODE segment that contains many low level kernel routines. And the DevHelp Routine is located in that segment (and all the subroutines it calls). The DevHelp Routine in turn is the main entry point for any device driver services and therefore used by about any device driver and a pointer to the DevHelp Routine is passed to each device driver on driver load. If that pointer is not properly saved or subsequently accidentally overwritten then you might see that trap.

So if it`s about a driver, Wim should check that the saved DevHelp pointer was not accidentally overwritten (the offset part of it) by a NULL value.

« Last Edit: May 21, 2022, 10:07:11 am by Lars »