OS2 World Community Forum

OS/2, eCS & ArcaOS - Technical => Games => Topic started by: Martin Iturbide on September 30, 2021, 11:33:38 pm

Title: DOS VDM - USB and Game port Gamepad support
Post by: Martin Iturbide on September 30, 2021, 11:33:38 pm
Hi

At Warpstock there was a quick Q&A with Lewis and there was some talk about ArcaOS as a retro gaming platform.
There was some fast comment about gamepads/joysticks and DOS old games.

I asked on the FreeDOS mailinglist (https://sourceforge.net/p/freedos/mailman/search/?q=Somekind+of+Game+Port+Emu%2FConverter+%3F) if there was something like a way to connect an USB gamepad and some "interpreter" that will allow old DOS games see it as a game port joystick. (So, in the end you can be able to play games that are supposed to use a game port joystick with an USB joystick).

Bret Johnson, that developed some USB device drivers for DOS (http://bretjohnson.us/ (http://bretjohnson.us/)) , answer me that it is possible with his driver, but under a very specific USB hardware set running FreeDOS.

The final idea will be to be able to support an USB gamepad under DOS VDM for old DOS games, but it seems we are still some steps behind.

I just post this as a discussion topic and maybe something of the open source DOS USB driver/program can be useful someday for the OS/2 platform.

Regards
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mentore on October 02, 2021, 11:02:28 am
Hi

At Warpstock there was a quick Q&A with Lewis and there was some talk about ArcaOS as a retro gaming platform.
There was some fast comment about gamepads/joysticks and DOS old games.

I asked on the FreeDOS mailinglist (https://sourceforge.net/p/freedos/mailman/search/?q=Somekind+of+Game+Port+Emu%2FConverter+%3F) if there was something like a way to connect an USB gamepad and some "interpreter" that will allow old DOS games see it as a game port joystick. (So, in the end you can be able to play games that are supposed to use a game port joystick with an USB joystick).

Bret Johnson, that developed some USB device drivers for DOS (http://bretjohnson.us/ (http://bretjohnson.us/)) , answer me that it is possible with his driver, but under a very specific USB hardware set running FreeDOS.

The final idea will be to be able to support an USB gamepad under DOS VDM for old DOS games, but it seems we are still some steps behind.

I just post this as a discussion topic and maybe something of the open source DOS USB driver/program can be useful someday for the OS/2 platform.

Regards

ISTR that Wim Brul developed usbecd**.zip "generic" drivers, which may be useful to understand/read classless devices. Maybe one could try these?

(Too bad I currently do not have an ArcaOS machine. Need time to install the latest beta for the italian NLV!)

Mentore
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Martin Iturbide on October 02, 2021, 02:27:11 pm
ISTR that Wim Brul developed usbecd**.zip "generic" drivers, which may be useful to understand/read classless devices. Maybe one could try these?

Hi Mentore

That may be interesting as a first step. Trying to see if with "USBRESMG.SYS" and/or the Wim Brul' drivers something came out of a USB gamepad attached to OS/2.

Regards
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Lars on October 02, 2021, 03:55:32 pm
US CALLS and USBRESMG are completely generic and you can set up any control,bulk,IRQ transfer that you want. But you will need some layer that maps the USB response packets to the packets that an analog or digital joystick would return (as far as I understand it).
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Roderick Klein on October 02, 2021, 04:04:47 pm
This whole thing has two sides to it.

First of all its the device driver it self that needs to communicate with the USB joystick or gamepad. How that can be done. While writing the device driver should not be that difficult I do not know how well standardized gamepads and USB joysticks are.  Is there a USB class for such devices ?

However if you have an OS/2 driver that is the first step. What I do not know is if Wim Brull his driver or usbresmgr.sys can used for such a project.
USBRESMGR in my understanding seems to effectively a ring 3 to ring 0 device driver that enables you to use a DLL to control equipment from OS/2 with a DLL. A good example of this is TAME.

You then automatically come with the second portion. You will need a VDD for DOS sessions. This VDD would emulate a legacy Joystick. I think the hex address is 301 or for a Joystick port ? The VDD would need to capture port 301 and send the data from and to the USB OS/2 driver.

Since joysticks are so timing senstive a command given on a USB stick should arrive up at the game ASAP!
So you need a driver that the DOS VDM driver can directly talk at ring 0. I do not know if thsi can be done at ring0 with USBRESMGR.SYS or Wim Brul his driver.

Joystockv.sys (VDM driver)-> USB PDD->USB stack->Joystick

Roderick Klein
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Martin Iturbide on October 02, 2021, 05:24:47 pm
Thanks.

I guess the idea will be something like this graphic, to have some gamepad/joystick support for ArcaOS with an USB gamepad.
The red squares are the things that do not exist.

Regards
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Dave Yeo on October 02, 2021, 05:42:07 pm
First of all its the device driver it self that needs to communicate with the USB joystick or gamepad. How that can be done. While writing the device driver should not be that difficult I do not know how well standardized gamepads and USB joysticks are.  Is there a USB class for such devices ?

Joysticks are standardized USB Human Interface Devices (HID) https://en.wikipedia.org/wiki/USB_human_interface_device_class#Game_controllers (https://en.wikipedia.org/wiki/USB_human_interface_device_class#Game_controllers) so pretty standardized with one driver supporting most USB joysticks.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on November 16, 2021, 02:21:56 am
Hi

At Warpstock there was a quick Q&A with Lewis and there was some talk about ArcaOS as a retro gaming platform.
There was some fast comment about gamepads/joysticks and DOS old games.

I asked on the FreeDOS mailinglist (https://sourceforge.net/p/freedos/mailman/search/?q=Somekind+of+Game+Port+Emu%2FConverter+%3F) if there was something like a way to connect an USB gamepad and some "interpreter" that will allow old DOS games see it as a game port joystick. (So, in the end you can be able to play games that are supposed to use a game port joystick with an USB joystick).

Bret Johnson, that developed some USB device drivers for DOS (http://bretjohnson.us/ (http://bretjohnson.us/)) , answer me that it is possible with his driver, but under a very specific USB hardware set running FreeDOS.

The final idea will be to be able to support an USB gamepad under DOS VDM for old DOS games, but it seems we are still some steps behind.

I just post this as a discussion topic and maybe something of the open source DOS USB driver/program can be useful someday for the OS/2 platform.

Regards

Hi Martin!

Interestingly, I was just about to broach the subject of whether there is some way to support use of USB joysticks under ArcaOS, as I've been reinstalling a lot of legacy games as well as SDL and Java games lately, so an interesting topic to me.

A few years ago, I purchased an item from Logilink in the EU which is called a USB 2.0 to Gameport adapter, which is a neat little device, which allowed me to connect one of the original Thrustmaster joysticks (made of metal) with a gameport connector to a usb port, to allow it to be used on newer computers under Windows. It works very well in situations like that. I don't know how the translation was done from the gameport connection to USB.

I've attached a couple of pictures of the adapter below. I don't think it is available for sale anymore retail as Amazon here lists it with a caveat of "not available". May still be available on eBay.

Mark
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on November 16, 2021, 05:58:31 am
First of all its the device driver it self that needs to communicate with the USB joystick or gamepad. How that can be done. While writing the device driver should not be that difficult I do not know how well standardized gamepads and USB joysticks are.  Is there a USB class for such devices ?

Joysticks are standardized USB Human Interface Devices (HID) https://en.wikipedia.org/wiki/USB_human_interface_device_class#Game_controllers (https://en.wikipedia.org/wiki/USB_human_interface_device_class#Game_controllers) so pretty standardized with one driver supporting most USB joysticks.

Hi Dave!

Do you, or does anyone else know if the OS/2/eCS/ArcaOS version of DOSBOX has Joystick support built in?

I was reading this article tonight and it raised an interesting question:

https://itstillworks.com/12226738/how-to-use-usb-joysticks-with-dosbox

It seems that Windows versions of DOSBOX can recognize Joysticks, if the devices are recognized by Windows, and assuming that joystick support exists in the DOS software being emulated by DOSBOX.

Would that simplify the process, and only require a driver under OS/2/eCS/ArcaOS for USB Joysticks (or perhaps items like the USB 2.0 to Gameport adapter I mentioned) to address DOSBOX? Not being a programmer, but being a troubleshooter, I thought the question needed asking.

You have to admit that the majority of legacy games that we would require direct support for would be either DOS or legacy Windows 3.1 (mostly flight simulators, or shoot'em up games), I would assume.

I don't know if any Java games have or need such support.

I also don't know of many games that are native OS/2 that have ever needed Joystick or Gamepad support (well perhaps Galactic Civilizations or Trials of Battle).

Best!

Mark
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Dave Yeo on November 16, 2021, 06:05:43 am
Seems to me that adding joystick support to SDL would be relatively easy, at least compared to writing device drivers. I'd assume that it would also give joystick support to DosBox. I'm not really a programmer so haven't looked into it.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on November 16, 2021, 02:56:24 pm
Seems to me that adding joystick support to SDL would be relatively easy, at least compared to writing device drivers. I'd assume that it would also give joystick support to DosBox. I'm not really a programmer so haven't looked into it.

HI Dave!

Probably wouldn't do much good in SDL, as I've seen few games with complex input requireemnts (maybe gamepad support?)

Interestingly I did some further reading in the DosBox Wiki on Wikipedia and found some interesting facts:

https://en.wikipedia.org/wiki/DOSBox#Hardware_emulation

DOSBox uses the Simple DirectMedia Layer external library to not only build new versions of DOSBox from source, but also handle graphics, audio, and input devices.

It can simulate the PC joystick port, with limited options being to emulate one joystick with four axes and four buttons; one gamepad with two axes and six buttons; two joysticks each with two axes and two buttons; a Thrustmaster Flight Control System joystick that has three axes, four buttons, and a hat switch; and a CH Flightstick with four axes, six buttons that can be pressed only one at a time, and a hat switch. Newer joysticks and gamepads will need to use one of these configurations to function.


So actually a very sophisticated piece of software, building on the original Simple DirectMedia layer external library.

As we have an ArcaOS version of DosBox which works well already (I have over 60 games running under DosBox). it seems the problem may be simplified to how to get USB input devices to address ArcaOS, and how to get the OS to address DosBox, as the architecture already exists within the emulator, as DosBox is really the standard go to now for all platforms, for people who want to run most DOS games at least. Don't know about any other legacy DOS programs.

But it is really Games and Input devices were talking here, so it may be very applicable.

I'm not a programmer as well, so I don't know how much it would simplify or complicate matters. I know Joystick drivers were written in the past to address gameport devices under OS/2. Perhaps they could be a framework to start the process.

Best as always!

M
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Roderick Klein on November 16, 2021, 04:14:43 pm
Thanks.

I guess the idea will be something like this graphic, to have some gamepad/joystick support for ArcaOS with an USB gamepad.
The red squares are the things that do not exist.

Regards

If you want the DOS VDM and the VDD communicate with the USB joystick you will need to have the knowlegde of the SDL library in a driver. That can be a PDD or a VDD. That is tricky part of supporting the VDM. And the VDD has to have code to "trap" I/O instructions so they are routed to the USB device.

Roderick
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Roderick Klein on November 16, 2021, 04:26:52 pm
Seems to me that adding joystick support to SDL would be relatively easy, at least compared to writing device drivers. I'd assume that it would also give joystick support to DosBox. I'm not really a programmer so haven't looked into it.

HI Dave!

Probably wouldn't do much good in SDL, as I've seen few games with complex input requireemnts (maybe gamepad support?)

Interestingly I did some further reading in the DosBox Wiki on Wikipedia and found some interesting facts:

https://en.wikipedia.org/wiki/DOSBox#Hardware_emulation

DOSBox uses the Simple DirectMedia Layer external library to not only build new versions of DOSBox from source, but also handle graphics, audio, and input devices.

It can simulate the PC joystick port, with limited options being to emulate one joystick with four axes and four buttons; one gamepad with two axes and six buttons; two joysticks each with two axes and two buttons; a Thrustmaster Flight Control System joystick that has three axes, four buttons, and a hat switch; and a CH Flightstick with four axes, six buttons that can be pressed only one at a time, and a hat switch. Newer joysticks and gamepads will need to use one of these configurations to function.


So actually a very sophisticated piece of software, building on the original Simple DirectMedia layer external library.

As we have an ArcaOS version of DosBox which works well already (I have over 60 games running under DosBox). it seems the problem may be simplified to how to get USB input devices to address ArcaOS, and how to get the OS to address DosBox, as the architecture already exists within the emulator, as DosBox is really the standard go to now for all platforms, for people who want to run most DOS games at least. Don't know about any other legacy DOS programs.

But it is really Games and Input devices were talking here, so it may be very applicable.

I'm not a programmer as well, so I don't know how much it would simplify or complicate matters. I know Joystick drivers were written in the past to address gameport devices under OS/2. Perhaps they could be a framework to start the process.

Best as always!

M

I really wonder how good a DLL is going to work timing wise and then the commands from the USB gamepad or joystick have to end up with the game.
This is extremely timing sensitive. I doubt Dosbox with a ring 3 DLL and usbresmgr.sys can be responsive enough and that the communication becomes to slow.
When you hit the firebutton the game should receive and process this command ASAP.

The DOS VDM I think has better performance then DOSbox.

Roderick
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on November 16, 2021, 05:26:58 pm
Hi Roderick!

As to your comments I can't really say, not being able to try input devices on ArcaOS DosBox at the moment. You are far more familiar with the architecture involved based on your involvement with the entire OS/2 based line of OS's in the past, but that has peeked my interest.

I think it would be interesting to set up DosBox on one of my other Windows partitions (Windows XP or 7), and try running a game that uses the Thrustmaster Control System as I have Joystick and Throttle, and see just how fast it responds. It is probably the most complex input array DosBox is programmed to handle.

As the equipment I have is set up for gameport, it would also allow me to test how it responds through the Logilink USB adapter box I have.

Best!

Mark
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on November 16, 2021, 08:15:24 pm
Seems to me that adding joystick support to SDL would be relatively easy, at least compared to writing device drivers. I'd assume that it would also give joystick support to DosBox. I'm not really a programmer so haven't looked into it.

Hi Dave!

It shows that I'm a Luudite when it comes to software technobabble.
(The reason I'm a hardware geek)

Of course SDL = Simple DirectMedia Layer - and from reading the Wikipedia Wiki, it seems DosBox is running the SDL libraries and is essentially an SDL program. Duh!

I reached out to Jochen Schäfer, whose porting DosBox to ask two questions:

1) In his ports, is the OS/2 DosBox code related to Input Devices still present? I noted in the .conf file for the ArcaOs inplementation a section exists under "Joysticks", but I'm sure would not work if we have no frontend USB Input driver under ArcaOS. Addressing your comment, if it is already there, NFAR, which is why I suggested this may be a solution to the problem presented, related to DOS.

2) I also wanted to know if he had some idea of how well Input Devices worked when captured by DosBox (timing, response, implementation), under other OS's, if he had some knowledge in the matter? I agree with Roderick, that would be a key factor as to whether DosBox or a native VBM would be an option.

2Roderick: I also had a follow-up question - for the frontend native USB driver, would there be any different programming required in the ArcaOS input driver to address either a VDM or DosBox? If not, the worst that could happen, if code exists in the current ArcaOS DosBox, is that it works poorly on capture of the Input device, and then a VDM could be developed, as a follow-on.

Perhaps the focus should be on getting a native USB Input Driver first, if that's possible, in whatever manner necessary?

As mentioned, just asking dumb questions, Guys and Gals, because I'm not aware of how labour intensive development of either (native USB driver / Dos VDM) would be. And being a consultant for 28 years, I know how the devil is in the details ......... and the personnel time and cost involved.

Best as always!

M

Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Andreas Schnellbacher on November 16, 2021, 10:27:35 pm
1) In his ports, is the OS/2 DosBox code related to Input Devices still present? I noted in the .conf file for the ArcaOs inplementation a section exists under "Joysticks", but I'm sure would not work if we have no frontend USB Input driver under ArcaOS. Addressing your comment, if it is already there, NFAR, which is why I suggested this may be a solution to the problem presented, related to DOS.
The contained dosbox.conf file is common for all OS. The first line says:
Code: [Select]
# This is the configuration file for DOSBox SVN. (Please use the latest version of DOSBox)Jochen has built it from the sources. Even the translated (and reencoded) files are recently pulled from the sources.

I was responsible for the packaging and (as a non-player) haven't tried much with the files itself. BTW: If you have something to add to the .conf or to README.OS2, I'm sure we could add it with no much effort. Patching the .conf with additions specially for OS/2 is possible.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: David McKenna on November 16, 2021, 11:31:33 pm
 Hey Mark,

  Wim Brul created a 'USB Extended Control Driver' ( https://home.hccnet.nl/w.m.brul/usbprobe/index.html ) for USB devices without drivers. Maybe that could be a starting point for a joystick? Would have to interface with the software somehow though. Maybe you could e-mail Wim and ask his opinion about using his driver for your games.

Regards,
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on November 17, 2021, 03:53:10 am
1) In his ports, is the OS/2 DosBox code related to Input Devices still present? I noted in the .conf file for the ArcaOs inplementation a section exists under "Joysticks", but I'm sure would not work if we have no frontend USB Input driver under ArcaOS. Addressing your comment, if it is already there, NFAR, which is why I suggested this may be a solution to the problem presented, related to DOS.
The contained dosbox.conf file is common for all OS. The first line says:
Code: [Select]
# This is the configuration file for DOSBox SVN. (Please use the latest version of DOSBox)Jochen has built it from the sources. Even the translated (and reencoded) files are recently pulled from the sources.

I was responsible for the packaging and (as a non-player) haven't tried much with the files itself. BTW: If you have something to add to the .conf or to README.OS2, I'm sure we could add it with no much effort. Patching the .conf with additions specially for OS/2 is possible.

Hi Andreas!

Thanks for confirming that the code for input devices would still be in Jochen's build of DosBox. It gives me an idea I'd like to try, as a proof of concept. If it does work, we may see input devices appearing in DosBox under ArcaOS in future. If not, no harm done and a learning experience.

Thanks and Best to you Sir!

Mark
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Dave Yeo on November 17, 2021, 08:15:33 am
Hi Mark,
It is cross platform and, guessing in pseudo code, the code in joystick.c will be something like
Code: [Select]
#else if define (__OS2__)
return NOT_IMPLEMENTED;
#else if define (__WIN32)
bunch of code to read and return the joystick state on Win32 using Windows API
...
We'd need code for OS/2 added there as only the code under the #if define (__OS2__) will be compiled on OS/2.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Jochen Schäfer on November 17, 2021, 09:04:16 am
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.


Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on November 17, 2021, 04:49:47 pm
Hey Mark,

  Wim Brul created a 'USB Extended Control Driver' ( https://home.hccnet.nl/w.m.brul/usbprobe/index.html ) for USB devices without drivers. Maybe that could be a starting point for a joystick? Would have to interface with the software somehow though. Maybe you could e-mail Wim and ask his opinion about using his driver for your games.

Regards,

Heh and Best to you David!

Long time no talk!

Others had already discussed Wim's driver USBECD here earlier, but I had time a look at the link you provided to Wim Brul's 'USB Extended Control Driver' page last night. Wim is very meticulous in his documentation, which I found very impressive, being a methods geek myself. It also gave me an idea to try, as an experiment..

Under Installation Wim states:

Installation - Move the USBECD23.ZIP file into a directory of your choice and unzip it. Copy the USBECD.SYS file to your C:\OS2\BOOT directory. Add the device driver to the CONFIG.SYS file with the DEVICE=C:\OS2\BOOT\USBECD.SYS statement (MBS Note - need to change the actual drive letter to the Drive you have OS/2/eCS/ArcaOS stored on) and restart your system. Attach the usb device that you want to control and it will be accepted by the device driver for inquiry via the DosRead function. Run the USBREAD.CMD file and it will obtain and display the device descriptor of the attached usb device and the device driver parameters required to control it with the DosWrite function.

There is more, but what struck me is plugging in a USB device, and running USBREAD.CMD which is provided with the driver to obtain and display the device descriptor.

I mentioned earlier in this thread using the Logilink USB2.0 to Gameport adapter to connect my gameport based Thrustmaster Joystick successfully to Windows systems in the past. After we started this discussion, I decided to try and see if ArcaOS detected the USB ID of the adapter.

Martin a few weeks ago in a discussion on Corsair gaming keyboards pointed me to Paul Smedleys handy little tool LSUSB which is ideal for the task of detecting specifically USB ID's and generating a hardware report on same.

So I decided to run lsusb -v |more to see what happened.

When I had it attached under ArcaOS, Paul Smedleys lsusb could not find the adapter. So I decided to download Wim's driver last night to see if it would be recognized under ArcaOS, if I run the driver, then USBREAD.CMD and subsequently lsusb,.

I considered it a proof of concept and a start to the process, At least it would tell us if the USB adapter and attached Joystick could be seen under ArcaOS with the driver installed. I attached the adapter, ran USBRead.CMD ........... and it worked!

I've attached a copy of the USBRead output from Wims driver below (USBRead Output.jpg). It produced the idVendor, idProduct and bcdDevice info immediately, and running LSUSB with the Vendor/Product ID combination produced a hardware report for a 4axis, 4 button Joystick (See Thrustmaster Joystick.txt).

I didn't go farther than that last night, but I think the proof of concept worked.

It also made me wonder if DosBox would see the Joystick as well. Correct me if I'm wrong Guys, but even without a native driver to address using the Input Device under ArcaOS, a DOS VDM or DosBox should be able to address the Input Device, if ArcaOS can see it, and code exists within the DOS implementation to enable input devices.

Andreas and an e-mail from Jochen today (who I see has joined the conversation) confirmed that the Input device code was ported from source and exists, so today I plan to try adding the device specific info to Wim's USBECD.SYS and then running a DOSBOX emulation of something like Comanche 3, with fcs support enabled, to see what happens. The worst thing that could happen is it wouldn't work, but you never know ............

Others might want to try installing Wims driver, then attaching a USB Joystick or Game Port to your computer and running USBRead.CMD as well. I found that adding it at the bottom of my Config.SYS on a system running ArcaOS v5.0.6 worked fine. However, I would caution that I tried to install it on a system that still is running v5.0.4 and for some reason it locked the keyboard and mouse inputs, requiring me to reboot and remove the statement to get back to normal (I have two ArcaOS partitions on each system, so that was an easy process when I experiment - possibly the USB package on that partition was not up to date).

But, in summary, proof of concept successful, and we have our feet through the door. What would still need to happen is to get the Input Device(s) working as they should, under ArcaOS and addressing implementation of a DOS VDM, if still required, or getting DOSBOX to work, if it doesn't already, for USB input devices.

Will have a read further in Wims Wiki to see what can be done with his driver, after testing DOSBOX, but a hopeful start and Best to all!

M
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on November 17, 2021, 05:22:06 pm
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.

Good Morning Jochen!

Got your e-mail reply this morning - thanks for the info.

None of my computers have Gameports anymore (well, maybe one extremely old tower) and I never tried DOSBOX in those days, but it seems that Wim"s USBECD driver might be a solution to help get native OS/2/eCS/ArcaOS USB HID support working (and possibly other devices as well). Will be trying to get DOSBOX to see and use my Thrustmaster flight control system today, as I understand it has native support for it setting the Joystick .conf settings to "fcs".

I asked the question about Input Device performance under DOSBOX, as I've never used any there previously, but Roderick further back in this thread had expressed some concerns about how well Input Devices performed under DOSBOX, so thought you might have more to add to the conversation.

Will let you and other know what I find, when I try to use the Thrustmaster under DOSBOX this afternoon and Best!

M
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Dave Yeo on November 17, 2021, 05:36:34 pm
Using the hidapi library with its usbcalls support should be a simple plugin solution assuming our usbcalls.dll is up to snuff, and if not, we can file issues and hopefully get it working.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Roderick Klein on November 17, 2021, 09:04:36 pm
Seems to me that adding joystick support to SDL would be relatively easy, at least compared to writing device drivers. I'd assume that it would also give joystick support to DosBox. I'm not really a programmer so haven't looked into it.

Hi Dave!

It shows that I'm a Luudite when it comes to software technobabble.
(The reason I'm a hardware geek)

Of course SDL = Simple DirectMedia Layer - and from reading the Wikipedia Wiki, it seems DosBox is running the SDL libraries and is essentially an SDL program. Duh!

I reached out to Jochen Schäfer, whose porting DosBox to ask two questions:

1) In his ports, is the OS/2 DosBox code related to Input Devices still present? I noted in the .conf file for the ArcaOs inplementation a section exists under "Joysticks", but I'm sure would not work if we have no frontend USB Input driver under ArcaOS. Addressing your comment, if it is already there, NFAR, which is why I suggested this may be a solution to the problem presented, related to DOS.

2) I also wanted to know if he had some idea of how well Input Devices worked when captured by DosBox (timing, response, implementation), under other OS's, if he had some knowledge in the matter? I agree with Roderick, that would be a key factor as to whether DosBox or a native VBM would be an option.

2Roderick: I also had a follow-up question - for the frontend native USB driver, would there be any different programming required in the ArcaOS input driver to address either a VDM or DosBox? If not, the worst that could happen, if code exists in the current ArcaOS DosBox, is that it works poorly on capture of the Input device, and then a VDM could be developed, as a follow-on.
<SNIP done by Roderick>

I can not speak for the USB driver itself in ArcaOS. What I can say is that using a library for DOSbox (a DLL) to talk to the USB joystick or gamepad VIA USBRESMGR might work.

However what is a key issue is if you want to get the DOS VDM to work. That is slightly more complicated!

You see a DLL running in OS/2 will not work. Since the VDM can not talk to that DLL.

First you have the DOS game.

That would "listen" to hex port 301 (I think was the Joystick hex I/O address under DOS).

A VDD (Virtual Device driver) would provide this port 301. This would also emulate the old joy stick.
What you need then is the next layer, a PDD (physicall device driver). This would know how to "talk" to the USB device's you want to communicate with.

A VDD loaded in OS/2 CAN NOT communicate with a DLL running in OS/2. At least not that I am aware off.
And even if it could I do not know how timing sensitive this would become.

DOSbox might be a whole different story perfomance wise. I have experience with this.

To put it differently. A driver such as USBRESMGR.SYS is NOT realy a device DRIVER. Its purely a ring 3 interface (application level) to have a DLL talk to a USB device. That is why a scanner app such as TAME can do this. But for more timing sensitive applications such a Joystick I  have some doubts if such a DLL can work. But I understand somebody want to see how well this works on Windows.

Roderick

Roderick
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on November 18, 2021, 11:07:59 pm
Hi All!

Just thought I'd check in to report my findings so far on this subject of USBECD, as a possible first step in developing  a USB Input Device driver.

And as I'm not techno-babble savvy when it comes to programming please excuse any gaffs I may make, explaining in summary what I've found.

Looking at a Linux programming Wiki ( https://www.linuxjournal.com/article/7353 ) related to writing a simple USB driver, the following is required (their words):

1) A pointer to the module owner of this driver: this allows the USB core to control the module reference count of the driver properly.

2) The name of the USB driver.

3) A list of the USB IDs this driver should provide: this table is used by the USB core to determine which driver should be matched up to which device; the hot-plug user-space scripts use it to load that driver automatically when a device is plugged in to the system.

4) A probe() function called by the USB core when a device is found that matches the USB ID table.

5) A disconnect() function called when the device is removed from the system.

Reading further in Wim Brul's Wiki on the subject of USBECD, it seems what he has provided is a gateway into the USB device and its functions,  which seems to match the requirements above.

The part I did as a proof of concept previously (running USBRead which essentially calls the DosRead function) seems to satisfy 1) above, at least to me, as it addressed the USB device, and found its unique identification (Vendor ID, Product ID, and the bcdDevice, the Device Release Number}.

Adding that to the Device listing in Config.Sys (DEVICE=D:\OS2\BOOT\USBECD.SYS /D:0583:2031:0110 in my case) and rebooting, I was then able to run USBWrite (which essentially calls the DosWrite function) which generated the report I've attached below (USB Gameport Adapter.txt).

It obtained and displayed the device descriptor, configuration descriptors and associated interface and endpoint descriptors, which I assume is needed to address 3) to 5) above (Paul's LSUSB probably does the same, but I have not compared the two printouts - his was provided in a previous post)

Wim's USBECD also provices a switch /N:$$$$$$$$ for the driver which Wim says specifies the device driver name, which must be unique and valid. It must be different to all other file, directory and driver names throughout the system. The driver accepts the characters allowed by the HPFS file system for file and directory names but not the space and the dot. An invalid character truncates the device driver name.

That sounds to me like the item that would satisfy 2) above.

So I seem to have discovered all the jigsaw pieces to the puzzle - the question is .......... how do they go together?

Most of the rest of Wim's description centres on what I assume are Rexx calls, to use the descriptor information provided. These include Direct Control Interface calls to:

- Acquire the device
- Obtain the device descriptor
- Execute Control Transfer
- Execute Data Transfer
- Release the Device

For anyone who has done Rexx programming, does that sound similar to what is described in items 3) to 5) of the Linux programming Wiki? And if so, is it possible to write a sample Rexx program to further test, as proof of concept?

I've been a project manager in my consulting capacity for decades, so I'm a generalist not a specialist in this field, hence out of my depth, detail wise.  I also don't know if would prove anything or be too complex a task. Thoughts anyone?

One other thing I noted in Wim's Wiki is that, if we ever planned to use this approach to having a working USB Input Device driver using the USBECD approach some method would be required to, when the USB device is plugged in, automatically acquire and use the unique USB ID info under USBECD - currently it is needed to be entered manually - however, I assume something can be done if writing an actual driver to address that.

Just some musings, Guys and Gals and Best!

M
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Wim Brul on November 19, 2021, 12:11:34 pm
To access USB gamepads/joysticks from an SDL based application such as DOSBox you should not use my USBECD.SYS driver. The reason for this is that you would need a very specific device driver statement in config.sys for the particular gamepad/joystick that you want to use. Plugging in a different gamepad/joystick would require config.sys to be changed. The way to go is via the generic USBCALLS interface.

To extend existing support of joysticks provided by GAMEVDD.SYS and GAMEDD.SYS to USB gamepads/joysticks requires an additional interface from GAMEDD.SYS to USBHID.SYS to be developed. This implies at least modifications to GAMEDD.SYS and possibly an additional USBGAME.SYS device driver in between. Right now I am experimenting and studying to see what I can do to provide this particular support.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on November 19, 2021, 05:24:54 pm
To access USB gamepads/joysticks from an SDL based application such as DOSBox you should not use my USBECD.SYS driver. The reason for this is that you would need a very specific device driver statement in config.sys for the particular gamepad/joystick that you want to use. Plugging in a different gamepad/joystick would require config.sys to be changed. The way to go is via the generic USBCALLS interface.

To extend existing support of joysticks provided by GAMEVDD.SYS and GAMEDD.SYS to USB gamepads/joysticks requires an additional interface from GAMEDD.SYS to USBHID.SYS to be developed. This implies at least modifications to GAMEDD.SYS and possibly an additional USBGAME.SYS device driver in between. Right now I am experimenting and studying to see what I can do to provide this particular support.

Hi Wim!

We've never corresponded before, but I wanted to express personal thanks for the explanation.

One question occurred to me related to your post - I know that a lot of the advantage to using USB is the Plug and Play nature of USB.

However if you were not planning to switch or remove the device, simply have it remaining plugged in (IOW simply using the same joystick or gamepad device all the time) and are sufficiently savvy, technically, to modify Config.Sys yourself manually, providing the /D: and /N: information, could input device support for a specific device be done through your USBECD driver?

Or are you referring to another specific Config.sys statement that would need to be added to address each device, to allow the input functions of the Joystick to be used? (essentially in the case of the Thrustmaster joystick I'm using it would be X-Y direction, enable 4 separate buttons, and a POV (Point of View switch)

I ask because it sounds like you are referring to your driver not being able to provide a "hot swap" function, as opposed to not being able to address and use the device.

Or are you thinking that since the infrastructure already exists, through GAMEVDD.SYS and GAMEDD.SYS, that adding the USB translation layer would be a better approach?

The reason the discussion turned to DOSBOX is that, while the ArcaOS has no interface to use newer USB based gaming input devices (the current support as I understand it is centered on Gameport devices natively), DOSBOX does have the ability currently to address and use USB input devices if they conform to the parameters that were used originally with many of the old DOS games including:

2axis (supports two joysticks)
4axis (supports one joystick, first joystick used
4axis_2 (supports 2 joysticks),
fcs (Thrustmaster) 4 axis, 4 button with POV viewer
ch (CH Flightstick)

People using DOSBOX under both Windows and Linux are doing this successfully with the newer USB input devices, using the existing built-in source code in DOSBOX, if the layout of controls is similar to one of the above configurations. Having that support available already in DOSBOX may mean not having to reinvent the wheel again related to creating a whole new DOS infrastructure to address USB input devices, as legacy games represents the majority of uses that a input device of this nature would be used for.

I'm not a programmer (41 years responding to, planning for and training people in emergencies and response to same) but have become very interested in this subject as both a gamer and someone who has done a lot of methods writing in the past (ie. manuals and emergency plans) Your Wiki on USBECD has helped me a lot in understanding the process of getting USB device support working in ArcaOS.

Best and a fine day, Sir!

Mark

Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Wim Brul on November 20, 2021, 06:13:07 pm
Hi Mark,

I am happily impressed by your clear and thorough investigations. Let me try to answer your questions.

Quote
One question occurred to me related to your post - I know that a lot of the advantage to using USB is the Plug and Play nature of USB.

However if you were not planning to switch or remove the device, simply have it remaining plugged in (IOW simply using the same joystick or gamepad device all the time) and are sufficiently savvy, technically, to modify Config.Sys yourself manually, providing the /D: and /N: information, could input device support for a specific device be done through your USBECD driver?
Yes. That is the way how I implemented a.o. touch screen support for some Wacom Bamboo (https://home.hccnet.nl/w.m.brul/usbwacom/index.html#OperatingInstructions) models. The supporting program (without looking into the HID report descriptors) knows by heart what the actual input report format is and acts on it accordingly. That program allows to hotswap the device (only tested for the same model though).

Quote
Or are you referring to another specific Config.sys statement that would need to be added to address each device, to allow the input functions of the Joystick to be used? (essentially in the case of the Thrustmaster joystick I'm using it would be X-Y direction, enable 4 separate buttons, and a POV (Point of View switch)
Yes. That is the way how I implemented a.o. touch screen support for some Wacom Intuos (https://home.hccnet.nl/w.m.brul/ptintuos/index.html#OperatingInstructions) models. The supporting program (without looking into the HID report descriptors) knows by heart what the actual input report format is and acts on it accordingly. That program allows to hotswap the device (only tested for the same model though).

Quote
I ask because it sounds like you are referring to your driver not being able to provide a "hot swap" function, as opposed to not being able to address and use the device.
No. The reason is that each USBECD.SYS device driver grabs the first USB device that fulfils its config.sys specification. This way the proper USB device is connected to the proper supporting program i.e the one that knows how to handle this particular device.

Quote
Or are you thinking that since the infrastructure already exists, through GAMEVDD.SYS and GAMEDD.SYS, that adding the USB translation layer would be a better approach?
Hard to say. There is more to it. It is complicated. Personally I favor as much backwards compatibility as possible. Existing programs that do work with game port joysticks need, on modern system without game port, to work with USB joysticks. This is why I think that an additional interface from GAMEDD.SYS to USBHID.SYS is to be developed. I am under the impression that the current port of DOSBox for OS/2 does contain game port joystick support. I wonder if that has been done by means of accessing our GAME$ device driver or through direct i.e. non-emulated game port access (unlikely because hard to do).
   
Quote
The reason the discussion turned to DOSBOX is that, while the ArcaOS has no interface to use newer USB based gaming input devices (the current support as I understand it is centered on Gameport devices natively), DOSBOX does have the ability currently to address and use USB input devices if they conform to the parameters that were used originally with many of the old DOS games including:

2axis (supports two joysticks)
4axis (supports one joystick, first joystick used
4axis_2 (supports 2 joysticks),
fcs (Thrustmaster) 4 axis, 4 button with POV viewer
ch (CH Flightstick)
Understood.  As mentioned before , one way to go would be via the generic USBCALLS interface. Another way could be via our to be modified GAMEDD.SYS i.e. GAME$ device driver. Yet another way could be through that additional USBGAME.SYS device driver.

Quote
People using DOSBOX under both Windows and Linux are doing this successfully with the newer USB input devices, using the existing built-in source code in DOSBOX, if the layout of controls is similar to one of the above configurations. Having that support available already in DOSBOX may mean not having to reinvent the wheel again related to creating a whole new DOS infrastructure to address USB input devices, as legacy games represents the majority of uses that a input device of this nature would be used for.
I am not sure what you are saying. Do you mean that, for DOSBox only, some shortcut solution would be acceptible limited to just those 5 devices? How about other SDL based games then?

Best regards,

Wim
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on November 22, 2021, 04:19:33 pm
Hi Wim

Busy weekend so was not on-line at all

Quote
One question occurred to me related to your post - I know that a lot of the advantage to using USB is the Plug and Play nature of USB.

However if you were not planning to switch or remove the device, simply have it remaining plugged in (IOW simply using the same joystick or gamepad device all the time) and are sufficiently savvy, technically, to modify Config.Sys yourself manually, providing the /D: and /N: information, could input device support for a specific device be done through your USBECD driver?

Yes. That is the way how I implemented a.o. touch screen support for some Wacom Bamboo (https://home.hccnet.nl/w.m.brul/usbwacom/index.html#OperatingInstructions) models. The supporting program (without looking into the HID report descriptors) knows by heart what the actual input report format is and acts on it accordingly. That program allows to hotswap the device (only tested for the same model though).

Are touch screens quite complex devices to program for?

When it comes to Joysticks and Game Pads, they are actually very simple devices - in the majority of cases, whether Gameport connected or USB connected they simply provide inputs to control direction / view/ control selection (POV), or a variety of on/off inputs in the way of buttons to provide fire control / control selection 


Quote
Or are you thinking that since the infrastructure already exists, through GAMEVDD.SYS and GAMEDD.SYS, that adding the USB translation layer would be a better approach?

Hard to say. There is more to it. It is complicated. Personally I favor as much backwards compatibility as possible. Existing programs that do work with game port joysticks need, on modern system without game port, to work with USB joysticks. This is why I think that an additional interface from GAMEDD.SYS to USBHID.SYS is to be developed. I am under the impression that the current port of DOSBox for OS/2 does contain game port joystick support. I wonder if that has been done by means of accessing our GAME$ device driver or through direct i.e. non-emulated game port access (unlikely because hard to do).

I myself am actually currently using an old Thrustmaster joystick circa 1995 (the base is made of metal and the stick is very well constructed - almost indestructible). It is connected to a modern system via USB, using a neat little adapter developed by Logilink (USB2.0 to Gameport adapter). It runs very well on Windows based games.

I'm not sure if that is what you are referring to related to non-emulated game port access, Wim, but as you may have read in my posts previously, USBRead successfully found the adapter and attached Joystick and successfully identified it as a 4 axis, 4 button joystick.

So your driver is accessing the device, and USBWrite sent back a very detailed descriptor (attached to one of my previous posts), which is why I thought your device driver might be the answer to addressing this particular problem.
   
Quote
People using DOSBOX under both Windows and Linux are doing this successfully with the newer USB input devices, using the existing built-in source code in DOSBOX, if the layout of controls is similar to one of the above configurations. Having that support available already in DOSBOX may mean not having to reinvent the wheel again related to creating a whole new DOS infrastructure to address USB input devices, as legacy games represents the majority of uses that a input device of this nature would be used for.

I am not sure what you are saying. Do you mean that, for DOSBox only, some shortcut solution would be acceptable limited to just those 5 devices? How about other SDL based games then?

Apologies for not being clearer, Wim - it was a long post.

As to SDL games, that is a different topic really - we are running those natively under ArcaOS, using SDL libraries - the discussion has really focused on running legacy games in a DOS session. To DOS VDM or not to, that is the question (adding a little classical Shakespeare to the conversation .......... !)

Regarding the Windows and Linus reference I was making reference to an article I had read in my research on a site called "ItStillWorks.com"

https://itstillworks.com/12226738/how-to-use-usb-joysticks-with-dosbox

It is not a technical article - it simply pointed out that if Windows recognizes a Joystick, in the case of the article, and if it conforms to one of the five configurations I described previously, then DOSBox should be able to both find and use the device in question, USB or Gameport connection being irrelevant.

As I said, Joysticks are actually very simple input devices, and very little has been done since the DOS days to change how a Joystick or Game Pad operates, other than adding additional buttons perhaps, and programming scripts to run complex functions (eg. casting spells in some fantasy games) - DOSBox emulates an old DOS machine and supports input devices from the old days, with directional control, up to four buttons, and the POV function (control which is called a "hat" on top of some joysticks) or any of the four other configurations. Essentially if a new USB based input device is configured in the same layout as one of the five configurations mentioned, it should be able to be used "out of the box" under DOSBox.

As the same source code is being compiled under Windows, and Linux and according to Jochan for the current ArcaOS implementation without modification, it should work for us as well, theoretically - its the reason, being a project manager as one of many things in the past, that I think the first step is to get USB Gaming Input devices talking to ArcaOS, as at least a proof of concept - I then suggested trying to run a game in DOSBox which could use an input device like a Joystick, and see what happens. It may mean a DOS VDM solution may not need to be developed.

I hope that clarified what I was attempting to say.

Now one caveat to all that - I am going on what other people have said, Wim, I have not tried running a DOSBox game myself under Windows to verify whether it is indeed that easy - I have set up a DOSBox implementation of an old DOS air warfare game on a Windows 7 system and plan to test it hopefully this week.

But, in summary, it was why I was wondering if your USBECD Driver could be used to test that proof of concept? I'm willing to be the guinea pig as, after 20 months straight of responding to first CoViD then Forest Fires, without any break, I am currently in a state of semi-retirement for the foreseeable future.

Best to you Sir and thanks for the interesting discussion!

M
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Wim Brul on November 22, 2021, 11:05:12 pm
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
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Dave Yeo on November 23, 2021, 06:54:01 am
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.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on November 24, 2021, 03:15:45 am
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
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Dave Yeo on November 24, 2021, 04:00:51 am
Hi Mark, you might be able to capture the output by redirecting stdout/stderr,
Code: [Select]
oinput.cmd 2>&1 | tee oinput.log
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Dave Yeo on November 24, 2021, 04:15:37 am
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?
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on November 24, 2021, 04:24:29 am
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
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Dave Yeo on November 24, 2021, 04:36:51 am
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.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on November 24, 2021, 04:46:25 am
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
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Wim Brul on November 24, 2021, 04:54:32 pm
Hi Mark,

Quote
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
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on November 25, 2021, 12:11:42 am
Hi Mark,

Quote
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
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on November 25, 2021, 02:27:37 am
Hi Mark,

Quote
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
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on November 25, 2021, 06:00:43 am
Hi Wim!

Quote

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
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Wim Brul on November 25, 2021, 01:11:49 pm
Hi Mark,

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

Quote
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.

Quote
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
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on November 25, 2021, 03:30:54 pm
Hi Wim!

Just starting my day - 0730 in Alberta.

M
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on November 25, 2021, 03:56:44 pm
Hi Again Wim!

Quote
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:

Quote
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
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on November 25, 2021, 07:33:14 pm
Hi Again Wim!

Quote
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

Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Dave Yeo on November 26, 2021, 12:07:23 am
Meanwhile I recompiled hidapi with some debugging printf's, now the output is,
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.

make_path() failed. unknown error
iconv_open() failed
iconv_open() failed
make_path() failed. unknown error
iconv_open() failed
iconv_open() failed
make_path() failed. unknown error
iconv_open() failed
iconv_open() failed
Device Found
  type: 046d c534
  path:
  serial_number: (null)
  Manufacturer: (null)
  Product:      (null)
  Release:      2901
  Interface:    0
  Usage (page): 0x0 (0x0)

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

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

unable to open device

The make_path failed is likely the problem.
I also compiled some of the test programs that come with libusb-devel-docs.
Code: [Select]
H:\tmp\libusb_test>testlibusb.exe
Dev (bus 1, device 1): Logitech - USB Receiver
Dev (bus 1, device 2): Kingston - DataTraveler 3.0
Dev (bus 1, device 3): Logitech - Logitech Dual Action
Code: [Select]
H:\tmp\libusb_test>listdevs.exe
046d:c534 (bus 1, device 1)
0951:1666 (bus 1, device 2)
046d:c216 (bus 1, device 3)
and here testing the joypad,
Code: [Select]
H:\tmp\libusb_test>xusb.exe 046d:c216
Using libusb v1.0.21.11156

Opening device 046D:C216...

Reading device descriptor:
            length: 18
      device class: 0
               S/N: 0
           VID:PID: 046D:C216
         bcdDevice: 0300
   iMan:iProd:iSer: 1:2:0
          nb confs: 1

Reading BOS descriptor: libusb: error [libusb_get_bos_descriptor] failed to read BOS (-1)
no descriptor

Reading first configuration descriptor:
             nb interfaces: 1
              interface[0]: id = 0
interface[0].altsetting[0]: num endpoints = 2
   Class.SubClass.Protocol: 03.00.00
       endpoint[0].address: 81
           max packet size: 0008
          polling interval: 0A
       endpoint[1].address: 01
           max packet size: 0008
          polling interval: 0A

Claiming interface 0...

Reading string descriptors:
   String (0x01): "Logitech"
   String (0x02): "Logitech Dual Action"
   String (0xEE): "?"

Releasing interface 0...
Closing device...
libusb: warning [libusb_exit] some libusb_devices were leaked

Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Dave Yeo on November 26, 2021, 04:25:20 am
Taking iconv out of the equation for now (problems with converting UTF-16LE?), I now get,
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.

make_path() failed. unknown error
make_path() failed. unknown error
make_path() failed. unknown error
Device Found
  type: 046d c534
  path:
  serial_number: (null)
  Manufacturer: Logitech
  Product:      USB Receiver
  Release:      2901
  Interface:    0
  Usage (page): 0x6 (0x1)

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

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

unable to open device

Better but there is still the make_path() error.
Looking at the code, it seems that libusb screws up returning the number of ports,
Code: [Select]
static char *make_path(libusb_device *dev, int interface_number, int config_number)
{
char str[64]; /* max length "000-000.000.000.000.000.000.000:000.000" */
/* Note that USB3 port count limit is 7; use 8 here for alignment */
uint8_t port_numbers[8] = {0, 0, 0, 0, 0, 0, 0, 0};
int num_ports = libusb_get_port_numbers(dev, port_numbers, 8);

if (num_ports > 0) {
int n = snprintf(str, sizeof("000-000"), "%u-%u", libusb_get_bus_number(dev), port_numbers[0]);
for (uint8_t i = 1; i < num_ports; i++) {
n += snprintf(&str[n], sizeof(".000"), ".%u", port_numbers[i]);
}
n += snprintf(&str[n], sizeof(":000.000"), ":%u.%u", (uint8_t)config_number, (uint8_t)interface_number);
str[n] = '\0';
} else {
/* USB3.0 specs limit number of ports to 7 and buffer size here is 8 */
if (num_ports == LIBUSB_ERROR_OVERFLOW) {
LOG("make_path() failed. buffer overflow error\n");
} else {
LOG("make_path() failed. unknown error\n");
}
str[0] = '\0';
}
return strdup(str);
}

Or maybe something else? There's also the null serial number, problem with UTF-16?
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Lars on November 26, 2021, 01:24:58 pm
I am currently working on libusb (for various reasons).
I did some updates on what port you will find what device. That'll hopefully solve it. We will see.

Note that our implementation of libusb will NEVER be able to list the whole bus hierarchy (which encompasses root hubs and chained hubs) because USBD.SYS (and therefore USBRESMG.SYS and also USBCALLS.DLL) does not publicly expose hub information.

EDIT: now I see that "libusb_get_port_numbers" tries to resolve the whole bus hierarchy, from the plugged in device upstream up to the root hub port. As I said, that cannot work. Unless we modify USBD.SYS, USBRESMG.SYS and USBCALLS.DLL.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Dave Yeo on November 26, 2021, 10:14:48 pm
OK, my understanding is obviously limited. It seems the code I quoted is limited to 8 ports, a USB3 limit. I took it for granted that was root ports, of which I have 8 of, as well as 2 hubs totaling 14 ports. The tree,
Code: [Select]
Controller 0: USBXHCD$
Root Hub 0 (4 ports) 1B21:2142
  Port 4: Device 046D:C216 (HID) LS Logitech, Inc. F310 Gamepad [DirectInput Mode]

Controller 1: USBEHCD$
Root Hub 1 (2 ports) 8086:1C2D
  Port 1:  Hub 3 (6 ports) 8087:0024 (HS hub with single TT) Intel Corp. Integrated Rate Matching Hub
    Port 3: Device 046D:C534 (HID)-(Keyboard)(HID)-(Mouse) FS Logitech, Inc. Unifying Receiver
    Port 4: Device 0951:1666 (MSD)-(SCSI)-(BO) HS Kingston Technology DataTraveler 100 G3/G4/SE9 G2/50

Controller 2: USBEHC2$
Root Hub 2 (2 ports) 8086:1C26
  Port 1:  Hub 4 (8 ports) 8087:0024 (HS hub with single TT) Intel Corp. Integrated Rate Matching Hub

which does seem to show enough of the bus hierarchy. Unluckily that is likely directly reading the drivers.
As for usbcalls, I've been using the one installed with YUM/RPM. Tried the one that ships with the Arca Noae drivers but it is quite different with almost none of the exports matching, different calling convention too. Guess ideally would be to basically rewrite the libusb/hid.c from hidapi to use the system usbcalls, big job likely beyond my abilities. Another idea is to call the system usbcalls from the YUM/RPM one.
Missing exports using the system usbcalls,
Code: [Select]
Error! E2028: _libusb_get_port_numbers is an undefined reference
Error! E2028: _libusb_get_bus_number is an undefined reference
Error! E2028: _libusb_alloc_transfer is an undefined reference
Error! E2028: _libusb_submit_transfer is an undefined reference
Error! E2028: _libusb_handle_events is an undefined reference
Error! E2028: _libusb_cancel_transfer is an undefined reference
Error! E2028: _libusb_handle_events_completed is an undefined reference
Error! E2028: _libusb_init is an undefined reference
Error! E2028: _libusb_exit is an undefined reference
Error! E2028: _libusb_get_device_list is an undefined reference
Error! E2028: _libusb_get_active_config_descriptor is an undefined reference
Error! E2028: _libusb_open is an undefined reference
Error! E2028: _libusb_get_device is an undefined reference
Error! E2028: _libusb_get_device_descriptor is an undefined reference
Error! E2028: _libusb_kernel_driver_active is an undefined reference
Error! E2028: _libusb_claim_interface is an undefined reference
Error! E2028: _libusb_free_config_descriptor is an undefined reference
Error! E2028: _libusb_free_device_list is an undefined reference
Error! E2028: _libusb_detach_kernel_driver is an undefined reference
Error! E2028: _libusb_close is an undefined reference
Error! E2028: _libusb_interrupt_transfer is an undefined reference
Error! E2028: _libusb_control_transfer is an undefined reference
Error! E2028: _libusb_free_transfer is an undefined reference
Error! E2028: _libusb_release_interface is an undefined reference
Error! E2028: _libusb_attach_kernel_driver is an undefined reference
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Lars on November 27, 2021, 12:09:34 am
As to controller,hub,device info: I assume you are quoting what the testlog from AN returns.
For debugging purposes, David added an interface to USBD.SYS to completely query all USB devices, including hubs. Since USBD.SYS of course knows about all USB devices, including USB hubs.

But USBCALLS (and USBRESMG) does not have access to that interface.

Anyway, libusb is using USBCALLS to implement its functionality, so that is the proper way to go. Because that is what usbhid obviously uses.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Rich Walsh on November 27, 2021, 09:22:43 am
As to controller,hub,device info: I assume you are quoting what the testlog from AN returns.
For debugging purposes, David added an interface to USBD.SYS to completely query all USB devices, including hubs. Since USBD.SYS of course knows about all USB devices, including USB hubs. But USBCALLS (and USBRESMG) does not have access to that interface.

For years now, the AN version of USBRESMG/USBCALLS has offered this API:

Code: [Select]
  APIRET APIENTRY UsbQueryDeviceInfo( ULONG ulDevNumber, ULONG *pulBufLen, UCHAR *pucData);
which returns this struct:

Code: [Select]
typedef struct {
  UCHAR              ctrlID;              // (00) controller ID
  UCHAR              deviceAddress;       // (01) USB device address
  UCHAR              bConfigurationValue; // (02) USB device configuration value
  UCHAR              bInterfaceNumber;    // (03) 0 based index in interface array for this item
  UCHAR              SpeedDevice;         // (04) 0 for full speed device, 1 - low speed device  2 - high speed device
  UCHAR              portNum;             // (05) port number to which device is attached
  USHORT             parentHubIndex;      // (06) index in hub table to parent hub, -1 for root hub device
  ULONG              rmDevHandle;         // (08) Resource Manager device handle
} GETDEVINFODATA;

I thought you and David had synchronized your distros.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Lars on November 27, 2021, 10:19:42 am
That struct returns the parent hub index a device is attached to as "parentHubIndex". But there is no public way to query the device index of that hub device. (query the device index from the hub index) And therefore you cannot build up the hierarchy.
It would not be awfully difficult to extend the functionality but now we have quite some code out in the field that makes use of USBCALLS. We could add another function that can query the device index for a given hub index. Then an application could of course build up the hierarchy.

EDIT: and sine the struct does not contain the device index but rather the real device address and rmDevHandle, then that new function should better return device address and rmDevHandle.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Lars on November 27, 2021, 10:36:51 am
I just tested: libusb uses "Usbquerydeviceinfo" to query the devices. And "lsusb" uses libusb to show the devices list. It will only show non-hub devices (that is: only "end-user" devices).
Unless David has added something. But that of course will never be publicly visible. He'll always roll his own ball.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Jochen Schäfer on December 07, 2021, 11:19:36 am
A little status update: I have enabled HIDAPI support in SDL2 and it's functions are called, but testjoystick doesn't recognizes my USB joystick, yet.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Lars on December 07, 2021, 04:14:17 pm
By now, I have finished work on libusb (hopefully). I'll ask BWW to create an updated RPM. You might want to try the updated version and see if that helps. Proper support of "libusb_get_port_numbers" is still a problem (what error message did you get when trying out hidapi ?)
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Jochen Schäfer on December 07, 2021, 09:04:24 pm
lsusb shows the joystick, but SDL2 doesn‘t. Since I don’t use hidapi directly, it have no error message.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Dave Yeo on December 08, 2021, 01:17:11 am
lsusb shows the joystick, but SDL2 doesn‘t. Since I don’t use hidapi directly, it have no error message.

Did you compile it yourself or use the one I compiled? Anyways here's the last version I compiled, used a different wcsdup() based on https://github.com/bitwiseworks/libc/issues/118 (https://github.com/bitwiseworks/libc/issues/118) and hacked to not use iconv(). Test program and diff included.
Edit: fix typo
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Jochen Schäfer on December 08, 2021, 08:58:40 am
lsusb shows the joystick, but SDL2 doesn‘t. Since I don’t use hidapi directly, it have no error message.

Did you compile it yourself or use the one I compiled? Anyways here's the last version I compiled, used a different wcsdup() based on https://github.com/bitwiseworks/libc/issues/118 (https://github.com/bitwiseworks/libc/issues/118) and hacked to not use iconv(). Test program and diff included.
Edit: fix typo
No, I used the version included in SDL2 with your wcsdup implementation. I'm now trying to compile the included hidapi, and test with that.

EDIT: I used hidtest from your version, but it says it cannot open the device.

BTW: Why do we have a lot wcs function,but not wcsdup?
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on December 08, 2021, 03:11:52 pm
Hi Jochen

lsusb shows the joystick, but SDL2 doesn‘t. Since I don’t use hidapi directly, it have no error message.

Did you compile it yourself or use the one I compiled? Anyways here's the last version I compiled, used a different wcsdup() based on https://github.com/bitwiseworks/libc/issues/118 (https://github.com/bitwiseworks/libc/issues/118) and hacked to not use iconv(). Test program and diff included.
Edit: fix typo
No, I used the version included in SDL2 with your wcsdup implementation. I'm now trying to compile the included hidapi, and test with that.

EDIT: I used hidtest from your version, but it says it cannot open the device.

BTW: Why do we have a lot wcs function,but not wcsdup?

Have you posted the updated hidapi? Didn't see it attached to any of the posts at the moment, and might want to see if it can see my joystick.

Haven't been following this much, as I've been busy at the moment fixing a sick printer - got a Printer Error 59.99 on my HP3500, which means tearing down the entire printer, to replace about 5 cents of worn padding on a solenoid. Takes about 12 hours ............ tedious work.

I recommend HP service manuals to anyone brave enough to undertake things like this _ very detailed.

Best!

M
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Dave Yeo on December 08, 2021, 04:35:17 pm
EDIT: I used hidtest from your version, but it says it cannot open the device.

BTW: Why do we have a lot wcs function,but not wcsdup?

Guess it is the PATH problem and needing to get all the ports. Hopefully Lars's updated libusb will help.
We've always been missing a lot of the wide character functions, Bitwise has added most but hadn't added wcsdup(). Sylvan must have seen this thread and opened the above referenced issue about it, so slowly we're getting all of them.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Jochen Schäfer on December 08, 2021, 04:48:24 pm
Hi Jochen

[...]
Have you posted the updated hidapi? Didn't see it attached to any of the posts at the moment, and might want to see if it can see my joystick.

No, it's part of SDL2, so I have to try understand the code and tinker around with it, first. Perhaps, the new libusb helps. We will see.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on December 08, 2021, 07:45:08 pm

No, it's part of SDL2, so I have to try understand the code and tinker around with it, first. Perhaps, the new libusb helps. We will see.

Understood.

Will watch with interest where things go from here with interest and Best!

M
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Jochen Schäfer on December 09, 2021, 12:01:20 pm
We've always been missing a lot of the wide character functions, Bitwise has added most but hadn't added wcsdup(). Sylvan must have seen this thread and opened the above referenced issue about it, so slowly we're getting all of them.

To keep everyone informed: I just made a pull request for a wcsdup implementation.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Jochen Schäfer on December 10, 2021, 04:14:03 pm
By now, I have finished work on libusb (hopefully). I'll ask BWW to create an updated RPM. You might want to try the updated version and see if that helps. Proper support of "libusb_get_port_numbers" is still a problem (what error message did you get when trying out hidapi ?)
Where do I get your version from to build it myself?
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on December 10, 2021, 04:24:53 pm
Hi Jochen

By now, I have finished work on libusb (hopefully). I'll ask BWW to create an updated RPM. You might want to try the updated version and see if that helps. Proper support of "libusb_get_port_numbers" is still a problem (what error message did you get when trying out hidapi ?)
Where do I get your version from to build it myself?

Dave's build of HIDAPI was attached to one of his earlier posts. I downloaded it there and tried it previously. Don't know where he derived the source code from.

Also don't know if Dave has an update to that.

Best!

Mark

Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Lars on December 10, 2021, 04:52:19 pm
By now, I have finished work on libusb (hopefully). I'll ask BWW to create an updated RPM. You might want to try the updated version and see if that helps. Proper support of "libusb_get_port_numbers" is still a problem (what error message did you get when trying out hidapi ?)
Where do I get your version from to build it myself?

It's here:
https://github.com/bitwiseworks/libusb1-os2

but there is still work to do (something's not quite right when you end a process with Ctrl-C). Nonetheless, you might want to try it.

Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Jochen Schäfer on December 10, 2021, 06:23:17 pm

It's here:
https://github.com/bitwiseworks/libusb1-os2

but there is still work to do (something's not quite right when you end a process with Ctrl-C). Nonetheless, you might want to try it.
Thank you, I wil try it out.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Dave Yeo on December 10, 2021, 06:52:41 pm
By now, I have finished work on libusb (hopefully). I'll ask BWW to create an updated RPM. You might want to try the updated version and see if that helps. Proper support of "libusb_get_port_numbers" is still a problem (what error message did you get when trying out hidapi ?)
Where do I get your version from to build it myself?

It's here:
https://github.com/bitwiseworks/libusb1-os2

but there is still work to do (something's not quite right when you end a process with Ctrl-C). Nonetheless, you might want to try it.

What flags are you using? I succeeded with,
Code: [Select]
sh configure --prefix=h:/tmp/libusb1 CFLAGS=-Iw:/usbdev LDFLAGS="-Zomf -Zbin-files -Zmap -Lw:/usbdev"
Which left me wondering about libcx and -Zhigh-mem
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Dave Yeo on December 10, 2021, 08:10:08 pm
Anyways, dropping in the new usb100.dll gave
Code: [Select]
12-10-2021  09:59:35  SYS2070  PID 2128  TID 0001  Slot 00a6
H:\TMP\HIDAPI\LIB\HIDTEST.EXE
HIDAPI0->USB100._clock_gettime
127

So I rebuilt hidapi, some wrestling to link to usbcalls (see libcx is also linked in by the pkgconfig script). Things have improved as the PATH error is gone but still unable to open the device.
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: 1-3:1.0
  serial_number: (null)
  Manufacturer: Logitech
  Product:      USB Receiver
  Release:      2901
  Interface:    0
  Usage (page): 0x0 (0x0)

Device Found
  type: 046d c534
  path: 1-3:1.1
  serial_number: (null)
  Manufacturer: Logitech
  Product:      USB Receiver
  Release:      2901
  Interface:    1
  Usage (page): 0x0 (0x0)

Device Found
  type: 046d c216
  path: 0-4:1.0
  serial_number: (null)
  Manufacturer: Logitech
  Product:      Logitech Dual Action
  Release:      300
  Interface:    0
  Usage (page): 0x0 (0x0)

unable to open device

Edit: notice the serial number is still null, perhaps the problem, perhaps caused by working around iconv.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Jochen Schäfer on December 10, 2021, 08:17:32 pm
You have to change the hardcoded device id for the hid_open call, so that it points to one of the connected devices.

But I cannot configure libusb, because it seems my system cannot link usbcalls.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Dave Yeo on December 10, 2021, 08:34:08 pm
Code: [Select]
emximp -o usbcalls.def usbcalls.dll
emximp -o usbcalls.a usbcalls.def

Will create the import library.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Jochen Schäfer on December 10, 2021, 09:16:42 pm
Thank you, that did the job.
I keep forgetting the emximp incantation all the time ;-)

Compiled HIDAPI. Now I see the usb path in the device summary, but the test still can't write to the joystick.
Because I have no experience with USB programming, I have to ask, whether this can happen with some USB devices or should it always be posible to send feature reports?
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Dave Yeo on December 11, 2021, 03:06:53 am
You have to change the hardcoded device id for the hid_open call, so that it points to one of the connected devices.

Does seem to work after changing the device id. Here I pressed a button.
Code: [Select]
Device Found
  type: 046d c216
  path: 1-4:1.0
  serial_number: (null)
  Manufacturer: Logitech
  Product:      Logitech Dual Action
  Release:      300
  Interface:    0
  Usage (page): 0x0 (0x0)

Manufacturer String: Logitech
Product String: Logitech Dual Action
Serial Number String: (1033)
Indexed String 1: Logitech
Feature Report
   00
waiting...
Data read:
   80 7f 80 7f 08 00 04 fc

Thanks Lars, your libusb seems to be working better compared to the last.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Lars on December 11, 2021, 12:29:42 pm
Thanks, I am still ironing out some bugs, in particular related to iso transfers. Just checked in again.

As to logging: if you specify "SET LIBUSB_DEBUG=4" on the commandline before running your app, then usb100.dll will dump a whole lof of logging info to stderr.

That might give a clue as to what goes wrong, if any.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Lars on December 11, 2021, 01:09:12 pm
1) as to running configure, I was given this shell script (content of file conf.txt):

export CFLAGS='-Zomf -Wno-attributes'
export CXXFLAGS='-Zomf -Wno-attributes'
export LDFLAGS='-Zhigh-mem -Zomf -lcx'

../git/configure --disable-static \
  --program-prefix= --prefix=/@unixroot/usr --exec-prefix=/@unixroot/usr \
  --bindir=/@unixroot/usr/bin --sbindir=/@unixroot/usr/sbin \
  --sysconfdir=/@unixroot/etc --datadir=/@unixroot/usr/share \
  --includedir=/@unixroot/usr/include --libdir=/@unixroot/usr/lib \
  --libexecdir=/@unixroot/usr/libexec --localstatedir=/@unixroot/var \
  --sharedstatedir=/@unixroot/usr/com --mandir=/@unixroot/usr/share/man \
  --infodir=/@unixroot/usr/share/info

I had to do a "sh conf.txt" in the root of my build directory, after that, I could do a "make" or "make install".

2) as to usbcalls import library: if you install RPM package "usbcalls-devel" from the NETLABS release repo, the import library is in there (in .A as well as in .LIB format)
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Lars on December 11, 2021, 01:14:08 pm
Anyways, dropping in the new usb100.dll gave
Code: [Select]
12-10-2021  09:59:35  SYS2070  PID 2128  TID 0001  Slot 00a6
H:\TMP\HIDAPI\LIB\HIDTEST.EXE
HIDAPI0->USB100._clock_gettime
127

So I rebuilt hidapi, some wrestling to link to usbcalls (see libcx is also linked in by the pkgconfig script). Things have improved as the PATH error is gone but still unable to open the device.
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: 1-3:1.0
  serial_number: (null)
  Manufacturer: Logitech
  Product:      USB Receiver
  Release:      2901
  Interface:    0
  Usage (page): 0x0 (0x0)

Device Found
  type: 046d c534
  path: 1-3:1.1
  serial_number: (null)
  Manufacturer: Logitech
  Product:      USB Receiver
  Release:      2901
  Interface:    1
  Usage (page): 0x0 (0x0)

Device Found
  type: 046d c216
  path: 0-4:1.0
  serial_number: (null)
  Manufacturer: Logitech
  Product:      Logitech Dual Action
  Release:      300
  Interface:    0
  Usage (page): 0x0 (0x0)

unable to open device

Edit: notice the serial number is still null, perhaps the problem, perhaps caused by working around iconv.

"serial number": the "serial number" as well as "Manufacturer" and "Product" are string descriptors, the id of which are given in the device descriptor. But if the string descriptor id is 0, then no string (descriptor) is saved in the device. About all manufacturers bother to set the "Manufacturer" and the "Product" string, but not the "serial number" string (even though it's possible that even Windows is using that to distinguish 2 instances of the very same device).
In short: nothing to worry about.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Dave Yeo on December 11, 2021, 05:11:44 pm
OK, thanks. The -no-attributes option is handy for stopping the visibility attribute warnings, have to remember that. I see configure also adds -lcx to the LIBS.
I was using the USBDEV package that can be installed with the Arca Noae USB package. It does raise the question of if and how compatible they are. It does have this in usbcalls.txt, "Applications built using this USBCALLS toolkit will only work if a compatible
USBCALLS.DLL and USBRESMG.SYS are installed and running." Something to test I guess.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Lars on December 11, 2021, 05:45:36 pm
The interface of the AN USBCALLS and my USBCALLS is exactly the same and therefore the import library is also the very same.
And therefore, if I build usb100.dll, you can run that on any AN system.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Jochen Schäfer on December 11, 2021, 07:04:58 pm
I tried further analyze the write errors from hidtest:
1.) It tries to write a feature report with number 0x02. The call to libusb_control_transfer gives me a return value of -1 (Input/Output value).
2.) Later, it writes to the device. The call to libusb_control_transfer also gives me a return value of -1.

When I press button or turn the stick, the read data gives me different data values. So that works at least.

@Lars: If you want to compile hidapi yourself, I have forked hidapi and applied Dave's diff and committed them. You find my repo here: https://github.com/josch1710/hidapi.

Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Dave Yeo on December 12, 2021, 05:11:45 am
2) as to usbcalls import library: if you install RPM package "usbcalls-devel" from the NETLABS release repo, the import library is in there (in .A as well as in .LIB format)

YUM insists on installing libusbcalls-devel 12.10-1.oc00 from arcanoae-rel even when trying to override it. Not going to try too hard with --force or such.
Edit: I reverted back to the USBDEV package due to sys2070's as mentioned above.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Dave Yeo on December 12, 2021, 08:36:40 am
So I found https://github.com/todbot/hidapitester (https://github.com/todbot/hidapitester)
Compiled it and using this command line,
Code: [Select]
hidapitester.exe --vidpid 046D/C216 -l 64 --open --read-input-forevermy joy-pad seems to work. Lots of other stuff can be done apparently, even adjusting the LED's on those expensive keyboards.
I'll simply attach the whole source including usb100.dll. The makefile needs adjusting if you are rebuilding. Simplest was to use an intree build of hidapi.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Dave Yeo on December 12, 2021, 09:04:14 am
Playing around with my sons cheap expensive keyboard and this command line,
Code: [Select]
hidapitester.exe --vidpid 04D9/A0CD -l 64 --open --read-input-foreverkeyscans seem to work until I played with the fnc key, then it stopped working and eventually returned -1 byte and closed the device. Keyboard needs unplugging and plugging back in to come back to life.
For those following along, HID stands for human interface device and includes keyboards, mice and joysticks, which all seem to have similar behaviour when it comes to drivers.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Martin Iturbide on December 12, 2021, 04:48:39 pm
Hi

FYI. In case some code can be reused:
- GAMEDD2_2002-07-24.zip (https://hobbes.nmsu.edu/download/pub/os2/system/drivers/misc/GAMEDD2_2002-07-24.zip) and GamePort (https://github.com/OS2World/DRV-Gameport2). Has the source code for JOY_PORT.EXE, a joystick test command line.
- JoySupport (https://github.com/OS2World/DEV-DRV-JoySupport). Spiceware code to  make using the joysticks as easy as possible.
- JoyDemo (https://github.com/OS2World/DEV-DRV-JoyDemo). SpiceWare sample source code for reading the joystick ports under OS/2.

Regards
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on December 12, 2021, 11:11:11 pm
Heh Dave!

So I found https://github.com/todbot/hidapitester (https://github.com/todbot/hidapitester)
Compiled it and using this command line,
Code: [Select]
hidapitester.exe --vidpid 046D/C216 -l 64 --open --read-input-forevermy joy-pad seems to work. Lots of other stuff can be done apparently, even adjusting the LED's on those expensive keyboards.
I'll simply attach the whole source including usb100.dll. The makefile needs adjusting if you are rebuilding. Simplest was to use an intree build of hidapi.

The added adjustments may be even more valuable to us than the game functionality.. I have Both a Corsair K70 and K95 keyboard that has the ability to adjust the backlighting so at night the keyboard is quite spectacular and you can easily type in pitch black - the colours are also slow enough that the special effects aren't annoying, like a couple of keyboards I've had with that functionality.

However, if we can script or key code that would be very useful - my K95 has 6 extra gaming keys (G1-G6), and I understand from Ivan that a previous incarnation of the K95 actually had 18 Function keys on the left side. He's been trying to find a way to use those keys for other purposes outside the gaming realm, but has not been able to succeed. I noted in one of your other posts that the keyscans locked the board, butr perhaps with the advances being made that can be overcome.

I will download the test program and try it but not today - Grey Cup afternoon today, and I used to be from Winnipeg, so Go Bombers Go!

M
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Dave Yeo on December 13, 2021, 02:23:02 am
Yes, the possibilities are many if the interface ever works correctly. https://www.usb.org/sites/default/files/hut1_21_0.pdf (https://www.usb.org/sites/default/files/hut1_21_0.pdf), a 319 page PDF gives some idea of the devices that can be controlled. I see there's even a Python interface to hidapi. Keyboard, touchpads and such are the obvious and what Arca Noae might be interested in.
Right now the hidapitester doesn't seem to be returning the usage field, or rather returning 0x0.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Lars on December 13, 2021, 08:36:14 am
I tried further analyze the write errors from hidtest:
1.) It tries to write a feature report with number 0x02. The call to libusb_control_transfer gives me a return value of -1 (Input/Output value).
2.) Later, it writes to the device. The call to libusb_control_transfer also gives me a return value of -1.

When I press button or turn the stick, the read data gives me different data values. So that works at least.

@Lars: If you want to compile hidapi yourself, I have forked hidapi and applied Dave's diff and committed them. You find my repo here: https://github.com/josch1710/hidapi.

Hi Jochen,

I'd be happy if you'd send me the built version and a test app that calls hidapi. Or if you could enable LIBUSB_DEBUG=4 and dump stderr to a file. I simply do not have the time to build yet another library and libusb is still work in progress.
hidapi and a test app would help me in verifying that libusb will do ok also for that secondary library (I am currently interacting with libuvc exclusively).
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Jochen Schäfer on December 13, 2021, 08:40:07 am
So I had some success with the HIDAPI interface to SDL2. It seems like HIDAPI only supports some common game controller like Xbox or PS4 controllers, at least when used via libusb. I plugged in my PS4 controller via USB and it shows up on testjoystick.
I think, I will push the changes upstream, so that we have at least that support.

@Lars, I can do that. I have attached a build of hidapitester with the needed HIDAPI dll. hidapitester -h gives you the parameters. Cf Dave's post with the link to the Github page of hidapitester for more informations.

EDIT: The PS4 game controller works as joystick on PrBoom.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on December 13, 2021, 03:45:48 pm
Hi Dave!

Yes, the possibilities are many if the interface ever works correctly. https://www.usb.org/sites/default/files/hut1_21_0.pdf (https://www.usb.org/sites/default/files/hut1_21_0.pdf), a 319 page PDF gives some idea of the devices that can be controlled. I see there's even a Python interface to hidapi. Keyboard, touchpads and such are the obvious and what Arca Noae might be interested in.
Right now the hidapitester doesn't seem to be returning the usage field, or rather returning 0x0.

Downloaded that technical paper you linked and had a quick skim and it is indeed a treasure trove - looks like a great detailed standardized reference guide to addressing a myriad of HID USB devices and usage functions, programming wise, as well as addressing how "Unknown devices" are treated.

I'm going to have a more detailed look at it this afternoon, to see if anything interesting jumps out and report back. I see that Jochen also posted an updated HIDAPI tester, so will see if I can use it with a number of my devices.

M
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Dave Yeo on December 13, 2021, 04:45:23 pm
@Lars, the hidapitester build I uploaded here also works as a test program, it is statically linked to hidapi.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Lars on December 14, 2021, 07:39:17 am
Ok thanks, I'll download all that and have a try.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Lars on December 16, 2021, 08:03:59 am
ok, I now tested hidapitester (with my latest usb100.dll) with a:

[C:\hidapitester]hidapitester --list
054C/0CE6: Sony Interactive Entertainment - Wireless Controller

When I do a:
[C:\hidapitester]hidapitester --vidpid 54c:ce6 -t 1500 --open --read-input-forever
Opening device, vid/pid: 0x054C/0x0CE6
Reading 64-byte input report 0, 1500 msec timeout...read 64 bytes:
 01 7E 7E 7E 81 00 00 CA 08 00 00 00 3A 03 22 95 F9 FF F9 FF FF FF 80 00 26 1F DD 07 D9 0F 76 34
 FD 90 20 D0 00 8A 42 D6 23 5F 09 09 00 00 00 00 00 E7 99 76 34 28 08 00 CB CD FB 46 B6 52 46 0D
Reading 64-byte input report 0, 1500 msec timeout...read 64 bytes:
 01 7F 7E 7E 81 00 00 CB 08 00 00 00 3B 03 22 95 FE FF FB FF FE FF C8 FF A6 1E 69 09 C2 C2 C8 42
 00 90 20 D0 00 8A 42 D6 23 5F 09 09 00 00 00 00 00 19 EC 1A 51 28 08 00 31 3D D5 3B 34 44 48 46
Reading 64-byte input report 0, 1500 msec timeout...read 64 bytes:
 01 7F 7E 7E 81 00 00 CC 08 00 00 00 3C 03 22 95 FD FF FB FF FE FF AB FF AF 1E 5F 09 14 8F 1B 51
 00 90 20 D0 00 8A 42 D6 23 5F 09 09 00 00 00 00 00 36 34 1C 51 28 08 00 42 44 C6 9A 2F F7 4C 37
Reading 64-byte input report 0, 1500 msec timeout...read 64 bytes:
 01 7F 7E 7E 81 00 00 CD 08 00 00 00 3D 03 22 95 FF FF F9 FF FB FF A9 FF B4 1E 57 09 A8 4D 1D 51
 00 90 20 D0 00 8A 42 D6 23 5F 09 09 00 00 00 00 00 B6 66 1E 51 28 08 00 9B DD 74 72 F1 B3 C2 98


and it keeps going on forever. However, how would I now see an individual user action like pressing a button ? The HID report keeps pouring in with a fairly high rate.

Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Dave Yeo on December 16, 2021, 08:40:22 am
Change the timeout, -t 50000 seems to work well here to see the various button and joystick changes.
Code: [Select]
Opening device, vid/pid: 0x046D/0xC216
Reading 64-byte input report 0, 50000 msec timeout...read 8 bytes:
 80 7F 7F 80 08 00 04 FC 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Reading 64-byte input report 0, 50000 msec timeout...read 8 bytes:
 80 7F 7F 80 28 00 04 FC 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Reading 64-byte input report 0, 50000 msec timeout...read 8 bytes:
 80 7F 7F 80 08 00 04 FC 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Reading 64-byte input report 0, 50000 msec timeout...read 8 bytes:
 80 7F 7F 80 88 00 04 FC 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Reading 64-byte input report 0, 50000 msec timeout...read 8 bytes:
 80 7F 7F 80 08 00 04 FC 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Reading 64-byte input report 0, 50000 msec timeout...read 8 bytes:
 80 7F 7F 80 18 00 04 FC 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

5th byte seems to be buttons, 6th byte the stick. It is a PC joypad.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Lars on December 16, 2021, 12:12:43 pm
ah, thanks. I had misunderstood what "timeout" was supposed to mean in this context. Now I understand.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on December 16, 2021, 04:52:44 pm
Hi Dave and Lars!

5th byte seems to be buttons, 6th byte the stick. It is a PC joypad.

When Wim and I were fooling around with his USB control driver, using his output program generated the following:

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

Don't know if the hex code output definitions he mentioned above (for B, H, X, Y, Z and S) would be in the same order but thought I would bring it to your attention, in case it might help.

Also Dave, in that technical white paper you linked to on USB Usage Data, Section 4 and specifically Section 4.1 defines standard usages for Joysticks and Gamepads, while section 8 and most specifically Table 8.1 gives standardized usage data related to PC Game controllers.  According to Section 3.5.3 of the paper:

Typical system software will search for application collections tagged with either a Joystick or a Game Pad Usage. When found, the Usages generated by these collections will be treated as standard system joystick (gaming device) input. Devices that use these declarations will have their output routed to separate destinations, allowing multiple-player applications.

The rest of section 3 may be interesting to you and Lars as well.

Don't know if any of that helps understanding the programming, as its all "hex" to me, but if there's one thing I can do is read technical - been doing that for over 40 years and Best, Gentlemen!

Mark
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Lars on December 16, 2021, 05:58:52 pm
What byte means what actually depends on the HID report descriptor. ("burned" into the USB device). That is basically a structure that describes the hid report data structure in a defined way (a little bit like a DTD would do for XML).
In short: there is no hard and fast meaning for a specfic bit/byte.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Lars on January 12, 2022, 09:03:49 pm
By now, I finally finished libusb (and also libuvc). Additionally, BWW has now built hidapi.
All 3 packages can now be installed from netlabs-exp.

Dave, can you build hidapitester.exe and link to hidapi dynamically ? That would allow me to test the hidapi->libusb chain.
I did test with your static build of "hidapitester.exe" but I don't know how many "hacks" you needed to get hidapitester running properly.

Cheers,
Lars
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Dave Yeo on January 12, 2022, 11:09:30 pm
By now, I finally finished libusb (and also libuvc). Additionally, BWW has now built hidapi.
All 3 packages can now be installed from netlabs-exp.

Dave, can you build hidapitester.exe and link to hidapi dynamically ? That would allow me to test the hidapi->libusb chain.
I did test with your static build of "hidapitester.exe" but I don't know how many "hacks" you needed to get hidapitester running properly.

Cheers,
Lars

Hi Lars, no I can't easily build hidapitester to dynamically link as it is coded to just use the object fiie, "$(HIDAPI_DIR)/libusb/hid.o"
I'll install the 3 packages and think on it. Actually might be easy, need to test.
Here's the hidapitester patch, basically just added an OS/2 section to the makefile,
Code: [Select]
diff --git a/Makefile b/Makefile
index dad535e..cd952ec 100644
--- a/Makefile
+++ b/Makefile
@@ -19,6 +19,9 @@ endif
 ifeq "$(UNAME)" "Linux"
        OS=linux
 endif
+ifeq "$(UNAME)" "OS/2"
+       OS=os2
+endif

 # deal with stupid Windows not having 'cc'
 ifeq (default,$(origin CC))
@@ -54,6 +57,18 @@ EXE=

 endif

+############ OS/2 (libusb)
+ifeq "$(OS)" "os2"
+
+CFLAGS+=-Zomf -Zmap -I../hidapi/hidapi
+# Edit the libs line to reflect your environment
+# If fully installed, "-lusb-1.00 -lpthread"
+LIBS = h:/tmp/libusb1/lib/usb-1.00_dll.a -lpthread
+OBJS = $(HIDAPI_DIR)/libusb/hid.o
+EXE=.exe
+
+endif
+

 ############# common
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Dave Yeo on January 12, 2022, 11:35:09 pm
OK, that was easier then expected. Attached, note that for testing purposes the Zhigh-mem cflag is commented out. I prefer to add it after making sure things work, along with including <os2safe.h>.
Very lightly tested.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Dave Yeo on January 13, 2022, 03:32:02 am
Hmm, more testing, hidapitester seems broken, even reverting to the original static makefile using my copy of hidapi (untouched) has the same result, namely --list doesn't output anything.
Hmm, recompiling my local copy of hidapi and running hidtest has the same problem, no devices listed.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Dave Yeo on January 13, 2022, 04:43:12 am
Seems the YUM/RPM version of USB100.dll is broken. Doing a git pull on your (Lars) repository and then building it and putting the DLL in the program directory works much better, though not perfect.
Code: [Select]
K:\work\hidapitester>hidapitester.exe --list
046D/C534: (null) - (null)
046D/C534: (null) - (null)
046D/C216: (null) - (null)
Code: [Select]
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: 1-3:1.0
  serial_number: (null)
  Manufacturer: Logitech
  Product:      USB Receiver
  Release:      2901
  Interface:    0
  Usage (page): 0x0 (0x0)

Device Found
  type: 046d c534
  path: 1-3:1.1
  serial_number: (null)
  Manufacturer: Logitech
  Product:      USB Receiver
  Release:      2901
  Interface:    1
  Usage (page): 0x0 (0x0)

Device Found
  type: 046d c216
  path: 1-4:1.0
  serial_number: (null)
  Manufacturer: Logitech
  Product:      Logitech Dual Action
  Release:      300
  Interface:    0
  Usage (page): 0x0 (0x0)

Manufacturer String: Logitech
Product String: Logitech Dual Action
Serial Number String: (1033)
Indexed String 1: Logitech
Unable to get a feature report.
hid_error is not implemented yetwaiting...
waiting...
...
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Lars on January 13, 2022, 07:29:40 am
That's odd because BWW has been building from exactly "my" version (the BWW repo) and I have used your hidapitester and that worked just fine.
Can you make sure that you have usb100.dll and USBCALLS.dll on your system only once and that they are the expected version?
Please note that I am using my USB drivers. That might make a difference as a few things had to be fixed in USBCALLS.dll as well as in the HC drivers.
As a test, can you test with my stack (after checking that the rest is ok) ?
If that works I will try and convince AN to pick up the changes that I did for USBCALLS and the HC drivers.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Lars on January 13, 2022, 07:32:29 am
As to my USB stack: I need to release a new stack first...
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Lars on January 13, 2022, 07:53:35 am
Wait a sec, this is about hidapi: can you send your patched hid.c file? I can then merge that into the BWW repo.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Dave Yeo on January 13, 2022, 08:25:34 am
Hi Lars, pulling and building your USB100.dll and putting it in the program directories, things work. As for what I have installed (W: is boot volume and Unixroot). This is a netlabs-rel install besides the libs and dev packages you mentioned, which2 -la shows all the libs on LIBPATH.
I can test with your stack tomorrow, bedtime here.
No patches applied to hid.c
Code: [Select]
K:\work\hidapi\libusb>which2 -la usb100.dll
w:/usr/lib/usb100.dll

K:\work\hidapi\libusb>which2 -la usbcalls.dll
w:/os2/dll/USBCALLS.DLL

Edit, removed stuff I previously posted, SM crashed when posting :)
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Dave Yeo on January 13, 2022, 08:30:38 am
Whoops, committed patches are attached. Jochen commited my first patch.

Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Dave Yeo on January 13, 2022, 08:42:08 am
DLL versions I'm using,
Code: [Select]
[K:\work\hidapi\libusb]bldlevel w:\usr\lib\usb100.dll
Build Level Display Facility Version 6.12.675 Sep 25 2001
(C) Copyright IBM Corporation 1993-2001
Signature:       @#bww bitwise works GmbH:1.0.24#@##1## 12 Jan 2022 18:44:44
 ECS26154618::::0::@@usb-1.0
Vendor:          bww bitwise works GmbH
Revision:        1.00.24
Date/Time:       12 Jan 2022 18:44:44
Build Machine:   ECS26154618
File Version:    1.0
Description:     usb-1.0

[K:\work\hidapi\libusb]bldlevel w:\os2\dll\USBCALLS.dll
Build Level Display Facility Version 6.12.675 Sep 25 2001
(C) Copyright IBM Corporation 1993-2001
Signature:       @#Arca Noae LLC:12.10#@##1## 19 Nov 2021 14:53:38     DAZAR1
 ::::::@@USBCALLS DLL for OS/2 (c) 2021 Arca Noae LLC
Vendor:          Arca Noae LLC
Revision:        12.10
Date/Time:       19 Nov 2021 14:53:38
Build Machine:   DAZAR1
File Version:    12.10
Description:     USBCALLS DLL for OS/2 (c) 2021 Arca Noae LLC
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Lars on January 13, 2022, 08:59:55 am
Ok, then it is most likely hidapi itself (the BWW repo is pulled straight from the official repo) or you using the AN USB stack (Wim and me have been testing with my USB stack).
I tried to be compatible with the AN USB stack but that one is closed source, I therefore don't have a clue of what they are doing.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Lars on January 13, 2022, 09:05:01 am
About usb100.dll: I don't understand why pulling the stuff from the BWW repo and building yourself works better than what is put in Netlabs. The only thing that Silvan did was to build it, likely with optimization.
Remember the NEW libusb is in Netlabs EXP and not (yet) in Netlabs REL !

Edit: sorry, did not read all postings, you are using the correct DLLs.

Still don't understand. My own built libusb DLL works as good as the one from Netlabs repo. I cannot spot any functional difference.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Lars on January 13, 2022, 10:40:42 am
Whoops, committed patches are attached. Jochen commited my first patch.

Where did Jochen commit your first patch?
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Dave Yeo on January 13, 2022, 06:39:59 pm
https://github.com/josch1710/hidapi (https://github.com/josch1710/hidapi)
I'll try booting to my netlabs-exp partition later and test there. Maybe a reboot is needed as I can't think of why things would be different here then there.
What architecture are you using? Here, libusb1 is Pentium4 and the Yum installed usbcalls-dev is i686. It shouldn't matter but you never know.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Dave Yeo on January 13, 2022, 07:20:54 pm
Rebooted to my netlabs.exp install, after upgrading and installing hidapi, things work as expected. Now to figure out what is different.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Lars on January 13, 2022, 07:31:17 pm
https://github.com/josch1710/hidapi (https://github.com/josch1710/hidapi)
I'll try booting to my netlabs-exp partition later and test there. Maybe a reboot is needed as I can't think of why things would be different here then there.
What architecture are you using? Here, libusb1 is Pentium4 and the Yum installed usbcalls-dev is i686. It shouldn't matter but you never know.

libusb: pentium 4
usbcalls-devel: n/a as I am using my stuff from the USB stack build tree ("leftovers", so to say)

But at least for usbcalls-devel, it should not matter. It's just a bunch of text files and 2 import libraries whose format is not dependant on processor architecture.

By the way: the "usbcalls" package might be the culprit. Unless you are using AN, the dependencies try to install a USBCALLS (20140416-1) that is by far older than what comes with AN or with my USB stack. Just stumbled over this problem. What I did was to just delete \usr\lib\usbcalls.dll which will reinstate the proper file in \os2\dll.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Silvan Scherrer on January 13, 2022, 07:42:50 pm
Rebooted to my netlabs.exp install, after upgrading and installing hidapi, things work as expected. Now to figure out what is different.
which hidapi version do you have? as I just uploaded the last available one 0.11.2
it includes your fixes as well. even done a bit different

regards
Silvan
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Lars on January 13, 2022, 08:24:01 pm
Just to state: I just pulled the latest hidapi stuff from rpm.netlabs.org and installed the RPMs manually.
It now works exactly as the static build from Dave. I rebuilt "hidapitester" with some changes to the makefile to link to hidapi dynamically. I also built with "-Zhigh-mem" as I know that the whole chain (libusb, usbcalls) works just well with high memory.

Regards,
Lars
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Dave Yeo on January 14, 2022, 06:06:23 am
Should have looked in popuplog.os2. Problem is the pthread library being newer in netlabs-exp.
Code: [Select]
01-13-2022  20:34:18  SYS2070  PID 0065  TID 0001  Slot 0081
K:\WORK\HIDAPITESTER\HIDAPITESTER.EXE
USB100->PTHR01._pthread_condattr_init
127
Threw me off as I expected something like,
Code: [Select]
[K:\work\hidapitester]hidapitester  --list
A non-recoverable error occurred.  The process ended.
Which is the result after I upgraded USBCALLS.DLL to 12.11. No trp, no entry in popuplog.

Edit: Above was with netlabs-rel. Upgrading usbcalls.dll on a netlabs-exp install things do work. The only USBCALLS.DLL installed here is in \os2\dll.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Lars on January 14, 2022, 10:17:32 am
Should have looked in popuplog.os2. Problem is the pthread library being newer in netlabs-exp.
Code: [Select]
01-13-2022  20:34:18  SYS2070  PID 0065  TID 0001  Slot 0081
K:\WORK\HIDAPITESTER\HIDAPITESTER.EXE
USB100->PTHR01._pthread_condattr_init
127
Threw me off as I expected something like,
Code: [Select]
[K:\work\hidapitester]hidapitester  --list
A non-recoverable error occurred.  The process ended.
Which is the result after I upgraded USBCALLS.DLL to 12.11. No trp, no entry in popuplog.

Edit: Above was with netlabs-rel. Upgrading usbcalls.dll on a netlabs-exp install things do work. The only USBCALLS.DLL installed here is in \os2\dll.

Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Dave Yeo on January 14, 2022, 04:50:01 pm
Configure likely found the new function in pthreads, which I don't want to update on the one install as if distributing software, it is a good idea if it works with netlabs-rel.
As for testing the new usbcalls, it is good to try it to see if there are issues to report.
It is interesting that it changed the failure on the netlabs-rel install.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Lars on January 14, 2022, 11:10:20 pm
So what are you trying to prove? That hidapi is not working properly? Or libusb? Or USBCALL version 12.11?
Just to make things clear: I am not actively using OS/2 any more. And I am not going to put any effort into something that is not approached systematically.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Dave Yeo on January 15, 2022, 12:03:32 am
Just that the usbcalls update doesn't break anything
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Lars on January 15, 2022, 10:50:27 am
What if any was changed from USBCALLS/USBRESMG version 12.10 to version 12.11?
If would be helpful if AN or you would share that secret with us. Otherwise, on the long run, it will become impossible to implement anything using USBCALLS .
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Dave Yeo on January 15, 2022, 05:57:12 pm
The HID descriptor parser has changed. Don't know where it is implemented. For usbresmg, a typo fix. Other changes probably wouldn't affect things.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Lars on January 15, 2022, 09:06:23 pm
USBKBD.SYS and USB MOUSE.SYS contain a HID descriptor parser.
There is nothing like that in USBCALLS.DLL or USBRESMG.SYS, at least not in my version.
If they did add something, I'll be looking forward for them to publish the interface.
I guess they added functionality so that the whole USB bus hierarchy can be queried. It's all drifting apart.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Martin Iturbide on February 05, 2022, 05:17:40 pm
Hi

I want to try an SDL ported game with an USB gamepad, but I found it hard to follow all the work on this thread.

Can I try "prboom-plus-2.6um-alpha1.zip" with an USB gamepad? Are all the need/updated libraries on the Netlabs RPM so it can work with an USB gamepad?

Regards
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Dave Yeo on February 05, 2022, 06:54:52 pm
As far as I know, it hasn't been implemented yet.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on February 05, 2022, 08:06:47 pm
Good Morning Guys!

Been an interesting year so far - between dealing with weather and politicians (I'm not quite sure which was worse, as neither are predictable) I had a rather busy January.

I have looked in on this thread from time to time in the interim, and I commend Dave, Lars, Jochen, Bitworks and Silvan, and the others who have been trying to press all this forward.

The development types have done a lot of yeomans work - the question now is how can we user types help in alpha and beta testing of whats been done? Thats where we need some input.

As I see it we're at the state where the testers need some detail from the developers on:

1) What needs to be installed to do the testing?
2) How do we do it? (YUM/RPM, downloading certain files, how to install, etc.)
3) What tests do you want run, and what info needs to be generated, and how?
4) What equipment do you want tested (joysticks? gamepads? other USB items like cameras of other USB devices found?)
5) Generally, how do you want the tests run?
6) What do you want us to find out at this stage (and hopefully going forward)

I know some testing has been done with "hidapitester" (don't know where that was pulled from or who created it), but whatever tools we need to test need a little explanation as to how they work and what to do. If you want testing in a games environment, I think we need to know what needs to be set up, possibly in CONFIG.SYS or other places in addition to adding the DLL libraries as well as which OS environment do you wanted it tested in (currently I'm thinking DOS under ArcaOS or OS/2, or native ARCAOS or OS/2).

As mentioned , I'm not a developer, but I can help and am volunteering in compiling 1) to 5) into a post which summarizes how we do this - I have followed this thread, but as Martin has inferred, its difficult to follow, and I don't think I could get all the relevant items together coherently without some guidance by the guys who have been doing the modifications and programming, as to what needs to be put down in writing to make this work.

So if you can post some of the steps here I will attempt to put it all together (or to email me privately - I have no email on OS2World).

Perhaps, Martin, if your listening in, and if I can put together something useful, we can get it up as a development or testing Wiki to give people something to reference on a single page, instead of users trying to find the post (or multiple posts) that has the info throughout the thread

Just wanted to contribute to this in the way I am skilled at - namely methods engineering. I expect if we have sufficient people testing (including me), there will be changes needed as we go along - but at least we have a structured way to move forward.

Thoughts on this anyone? And Best!

Mark
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Dave Yeo on February 06, 2022, 01:42:45 am
Hi Mark,
As far as I know, Josh hasn't made any advancements with this. Looking at his Github, he has been getting the test suite to work and hasn't committed anything joystick related.
The hope was that it would just work once hidapi was enabled and building. Currently here hidapi just returns a series of numbers, some of which change when the joystick is operated, those numbers need to be translated into buttons and x/y axis etc. It is also possible hidapi and/or libusb needs more updates.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Lars on February 06, 2022, 02:20:53 am
The API can be found here:

https://github.com/libusb/hidapi/blob/master/hidapi/hidapi.h

To me, hidapi looks like a very thin layer on top of libusb. It just allows to send or receive feature reports and to receive input reports. Feature reports seem to be for control or to receive settings.
However, interpreting the contents of an input report requires a HID parser. The HID parser uses the information in the HID report descriptor (burned into the device, can be read from the device just like any other descriptor) to find out what bit means what.
So, the hidapi is available (from BWW github) or from Josh but the "intelligence" is provided by the parser that is not part of hidapi.
Maybe the application that Martin suggested contains the necessary parser to actually make up something of the data that it receives via USB. That would be my hope, at least.

Here is some hopefully simple explanation of what a HID report descriptor is:
https://eleccelerator.com/tutorial-about-usb-hid-report-descriptors/
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Dave Yeo on February 06, 2022, 03:38:05 am
I was hoping that the files under src\joystick\hidapi such as SDL_hidapijoystick.c would do the parsing. SDL2 also contains it's own hidapi, currently patched for OS/2 by the looks of it.
Guess could try building it. configure --help has,
Code: [Select]
--enable-hidapi         use HIDAPI for low level joystick drivers
                        [[default=yes]]
--enable-hidapi-libusb  use libusb for low level joystick drivers
                        [[default=maybe]]
Have to boot to a system where the latest libusb along with the latest pthreads is installed.
I'll see if it builds and perhaps start another thread.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Lars on February 06, 2022, 04:25:45 am
Ah, ok, yes, so SDL does not implement a full blown HID parser but it knows the input packet format for a couple of known devices.Yes, that is what is needed.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Martin Iturbide on February 06, 2022, 05:44:35 pm
Hi Mark.
Perhaps, Martin, if your listening in, and if I can put together something useful, we can get it up as a development or testing Wiki to give people something to reference on a single page, instead of users trying to find the post (or multiple posts) that has the info throughout the thread
Just let me know what do you have in mind. We can use the OS2World wiki. Since  you register some years ago, I think you have access to the wiki with the same UserID and password. Feel free to write me a private message on this forum, or write to my gmail (martiniturbide -at- gmail.com).

Regards

Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Jochen Schäfer on February 06, 2022, 06:51:39 pm
As I stated before, the HIDAPI part of SDL2 only works with game controller at the moment. My PS4 controller works just fine.
I don't know what the road map for USB joysticks is, but I find that having game  controller support is a first step.
But at the moment, I'm more worried about the problem SDL2-os2 has with relative mouse mode, because that's the issue with the PrBoom port.
I'm at that problem, but I have only so much time, with all the other ports and  hobbies going on, so please be patient ;-)

Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on February 06, 2022, 07:46:32 pm
Hi Dave!

Hi Mark,
As far as I know, Josh hasn't made any advancements with this. Looking at his Github, he has been getting the test suite to work and hasn't committed anything joystick related.
The hope was that it would just work once hidapi was enabled and building. Currently here hidapi just returns a series of numbers, some of which change when the joystick is operated, those numbers need to be translated into buttons and x/y axis etc. It is also possible hidapi and/or libusb needs more updates.

Actually a series of numbers similar to a calibration program does tell us something to start - namely that the device is being recognized by the OS, which is a good start - if devices are not being recognized, at least we know which ones, and can use that as a baseline, for testing purposes. As updates and modifications advance at least those simple advances are one way to measure success.

The tests I was doing for Wim are an example of that - but as a tester, I need to know what needs to be installed and running to understand how I can generate data that may be used by the developers at various levels to determine how to proceed. And it does help to have a reference for any tools like hidapitester, so that everyone knows what needs to be done with the tool and how to do it.

Very few here as developers have time at the moment to document that, but I happen to at the moment - so if I can first get an idea as to the set-up needed to undertake some alpha testing and what you gentlemen may need, I can help out with this in a small way, hopefully.

Best!

Mark



Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on February 06, 2022, 08:07:55 pm
Hi Martin!

Just let me know what do you have in mind. We can use the OS2World wiki. Since  you register some years ago, I think you have access to the wiki with the same UserID and password. Feel free to write me a private message on this forum, or write to my gmail (martiniturbide -at- gmail.com).


Just got the idea for doing something like this after perusing roughly 75 pages of Paul Smedley's thread related to UniAud32.sys. Paul has been doing absolutely yeoman's service in updating that driver, and the testers are all very enthusiastic, and now know everything Paul needs to further update and development - however, coming in very late (read years) in those very exciting developments, I found I'm having to piece together from roughly 800 posts on how to test the driver, what data needed to be generated and forwarded to Paul, and how that needed to be accomplished.

I plan to address that issue on my systems soon in future, but I've found I've been taking a lot of notes working through the posts, so that I would be able to undertake my own hardware tests on two systems using Paul's updated UniAud32 driver.

This USB support issue is a much more complex project in that its not just a driver involved, but libraries and various other items at various levels and layers which may need to be integrated to successfully test not only game controller/pad support, but also as an extension possibly other HID device support. This is the reason I'm suggesting that a Development / Testing Wiki related to this project may be of some use to help coordinate at these efforts coherently. I'm sure we all have notes we've been jotting down on things we've learned on the subjects we each have of interest - I'm just suggesting pooling the various items together into a testing "how-to" may help us all push things forward on this project.

Best!

Mark
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on March 06, 2022, 06:51:35 pm
As far as I know, it hasn't been implemented yet.

Hi Dave!

Hope the year is going well for you. I have an appellation for every year, and I'm starting to dub this one the "Year of Strange"

Had a question for you about your version of hidapitester.

Was going to do some testing this weekend and this week. I've installed the new experimental libraries that were in the ANPM repositiories and was wondering if your build of hidapitester was compiled to use information solely in your directories, or whether it would use the experimental DLL's installed by ANPM.

I was curious as to what devices may be seen by your build of the tester, in addition to any gaming equipment it may find.

Went silent for a month, as February was very busy.

While the Coutts border occupation by protestors was strictly an RCMP operation, we had to open the Provincial Emergency Operations Centre and man it yet again, to coordinate communications between enforcement services and provincial authorities, so busy at that for a couple of weeks, then all the paperwork and follow-up critiques, briefings and reports. Interesting times, Sir and Best!

M
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Dave Yeo on March 06, 2022, 08:09:45 pm
Hi Mark, this whole decade is turning out weird, strange and horrible.
That version of hdiapitester should work with the DLLs installed by YUM/RPM, if not you'll find a sys2070 in popuplog and I can always rebuild. You may need the usbcalls.dll from Arca Noae.
Unluckily things seem incomplete and I don;t have the knowledge to fix them so have been patiently hoping someone more knowledgeable gets things working better.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on March 06, 2022, 09:57:30 pm
Heh Dave!

Your knowledge is far more extensive than mine in these quarters - my knowledge, as mentioned is skilled and expert in a different quarter .........

And I'm hoping it is not needed much more this year. But that is my hope, no my expectation.

A fine rest of the weekend and week to you Sir and Best!

M

Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on March 11, 2022, 11:01:45 pm
Heh Guys!

I started doing some testing related to USB devices including the game controllers I have available and had two questions today, about HIDAPI:

1) I've downloaded the experimental version of HIDAPI that was posted accessible through a repository available for download via ANPM, as well as USB1 and a couple of multimedia libraries, as per the announcement on OS2World a couple of weeks ago. I was wondering if anyone has found any other dependencies that are required for HIDAPI testing purposes?

2) I'm currently using Dave Yeo's version of Hidapitester, and have been using the --list functions extensively, to have a look at what USB equipment is being recognized so I understand its use to start. However, I also wanted to run a couple of tests on my controllers, to see if the the buttons are functional and recognized. Is there some command line syntax I can use in Hidapitester to generate a continuous hex output report as I press certain buttons, or while I move the joystick?

In the current --list functions the following items are reported:

[D:\]hidapitester --list

1EA7/1005: BTL - Gaming Mouse
1EA7/1005: BTL - Gaming Mouse
0A81/0205: CHESEN - PS2 to USB Converter
0A81/0205: CHESEN - PS2 to USB Converter
0583/2031: Padix Co. Ltd. - 4-axis,4button joystick w/view finder

lsusb reports the following for the same system:

Protocol spec without prior Class and Subclass spec at line 23281

Bus 001 Device 001: ID 046d:08b5 Logitech, Inc. QuickCam Sphere
Bus 001 Device 002: ID 1ea7:1005 SHARKOON Technologies GmbH
Bus 001 Device 003: ID 058f:6362 Alcor Micro Corp. Flash Card Reader/Writer
Bus 001 Device 004: ID 0a81:0205 Chesen Electronics Corp. PS/2 Keyboard+Mouse Adapter
Bus 001 Device 005: ID 0583:2031 Padix Co., Ltd (Rockfire) RM-203 USB Nest [mode 2]

Is there a reason why hidapitester would report two of the devices twice? Also, as both a camera and a flash card reader are reported with lsusb but not under hidapitester, would these items not be seen or addressed by HIDAPI?

Best of the day and weekend to you!

Mark
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Dave Yeo on March 12, 2022, 04:46:06 am
Hi Mark, this works for my joystick, change the vidpid to yours,
Code: [Select]
hidapitester --vidpid 046D/C216 -l 64 -t 1500 --open --read-input-foreverI see hex values changing when pressing buttons etc. Could play with the -t (time) parameter.
Your mouse may be actually dual function like your keyboard and mouse thingy. Lots of devices are actually multiple devices such as some gaming mice also registering as a keyboard so some buttons can report key presses.
The flash card reader and camera are not HID (human interface device) devices, but MSD (mass storage device) or similar for the camera. Completely different class of device.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on March 12, 2022, 07:53:47 pm
Hi Mark, this works for my joystick, change the vidpid to yours,
Code: [Select]
hidapitester --vidpid 046D/C216 -l 64 -t 1500 --open --read-input-foreverI see hex values changing when pressing buttons etc. Could play with the -t (time) parameter.
Your mouse may be actually dual function like your keyboard and mouse thingy. Lots of devices are actually multiple devices such as some gaming mice also registering as a keyboard so some buttons can report key presses.
The flash card reader and camera are not HID (human interface device) devices, but MSD (mass storage device) or similar for the camera. Completely different class of device.

Heh Again Dave!

The mouse listed is marketed as the Aula Ghost Shark Gaming Mouse and is programmable - it has both standard mouse functions (right and left mouse keys, and and roller/click function) in addition to 4 other programmable buttons (in windows all are programmable) - interestingly those 4 buttons didn't seem to function before now correspond to 3 keyboard letters (c,w,s) and opening of a file save window. I don't know if that is a function of HIDAPI or not - I would have to disable the API as a test and see if that could be reproduced without the library installed.

As to the Chesen PS/2 to USB converter I'm not sure what device it is referring to - it is not related in any way to the logilink adapter where the joystick is attached, as it has a different PID and it corresponds to the joystick, which disappears if unplugged from USB.

I'll try the command line syntax you provided, substituting the PID values for my devices and see what happens.

Thanks for the tip and Best!

M
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Wim Brul on March 17, 2022, 06:16:00 pm
Martin Iturbide was so kind to send me some usb game controllers for me to experiment with. What I have done so far (still very experimental):

I created GAMEPAD.SYS (new driver) which talks to modified GAMEDD.SYS (replacement).
I created xevents.cmd which uses USBECD.SYS to obtain events from those controllers.
This xevents.cmd (written in rexx) sends transformed events to GAMEPAD.SYS and so on.
At the end these events arrive in GAMEVDD.SYS what I have seen happening right now.

I can play some games with my C=64 emulator for OS/2 using those controllers. I can play OS/2 game MAKMAN and DOS game WOLF3D using those controllers.
Martin Iturbide did some testing with his own usb game controllers as well. He suggested to go public so others can test and provide their comments. So here it is.

@Mark: for your Padix RM-203 there are 2 REXX scripts to try out:

1) I modified oinput.cmd which now only reports changed input events.
2) I created xevents.cmd to send transformed events into GAMEPAD.SYS.

I already did some ad hoc mapping of various controls into just 4 axis and 4 buttons.
The big challenge is to come up with proper mapping for each usb game controller.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Martin Iturbide on March 17, 2022, 08:57:12 pm
Thank you very much Wim.

This is a video I created some time ago testing the drivers with an USB Gamepad.
https://youtu.be/QAP0pEUwpx0 (https://youtu.be/QAP0pEUwpx0)

Just to clarify, these drivers are to make USB gamepad works with OS/2 games that uses the "gamedd.sys" driver and DOS games under the DOS VDM sessions (gamevdd.sys).

It does not overlaps with the efforts to make a USB Gamepad driver to work on SDL ported games. I hope it can be complementary at the end.

Please test it out and provide feedback, let's see how far we can get with this.

Regards
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Jochen Schäfer on March 18, 2022, 09:00:25 am
It does not overlaps with the efforts to make a USB Gamepad driver to work on SDL ported games. I hope it can be complementary at the end.
In the now available SDL version 2.0.18, USB HID support for game controllers was enabled. Also native joystick support is reintroduced.
If I understand this correctly, we get native joystick support with this driver. If so, I will test the driver with Dosbox next week.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Martin Iturbide on March 18, 2022, 02:07:19 pm
It does not overlaps with the efforts to make a USB Gamepad driver to work on SDL ported games. I hope it can be complementary at the end.
In the now available SDL version 2.0.18, USB HID support for game controllers was enabled. Also native joystick support is reintroduced.
If I understand this correctly, we get native joystick support with this driver. If so, I will test the driver with Dosbox next week.

Thanks Jochen. I also want to test that. I will be looking forward to the DOSBox update.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on March 18, 2022, 04:23:02 pm
Martin Iturbide was so kind to send me some usb game controllers for me to experiment with. What I have done so far (still very experimental):

I created GAMEPAD.SYS (new driver) which talks to modified GAMEDD.SYS (replacement).
I created xevents.cmd which uses USBECD.SYS to obtain events from those controllers.
This xevents.cmd (written in rexx) sends transformed events to GAMEPAD.SYS and so on.
At the end these events arrive in GAMEVDD.SYS what I have seen happening right now.

I can play some games with my C=64 emulator for OS/2 using those controllers. I can play OS/2 game MAKMAN and DOS game WOLF3D using those controllers.
Martin Iturbide did some testing with his own usb game controllers as well. He suggested to go public so others can test and provide their comments. So here it is.

@Mark: for your Padix RM-203 there are 2 REXX scripts to try out:

1) I modified oinput.cmd which now only reports changed input events.
2) I created xevents.cmd to send transformed events into GAMEPAD.SYS.

I already did some ad hoc mapping of various controls into just 4 axis and 4 buttons.
The big challenge is to come up with proper mapping for each usb game controller.

Hi Wim!

Sounds like you've been doing a HUGE amount of work. Thanks for all the efforts.

Two questions:

Are the REXX scripts your describing for me in the package you attached, and

Are there any installation instructions that come with the packages?

If not I will see if I can come up with something after doing my tests, as a guide for testing.

But thanks for all the work sir and hopefully we can get some feedback to you soon!

Best!

Mark

Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Jochen Schäfer on March 18, 2022, 05:12:10 pm
Thanks Jochen. I also want to test that. I will be looking forward to the DOSBox update.
If the driver works like I think it would, there is no update to Dosbox or SDL1 necesarry. ;-)
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Wim Brul on March 18, 2022, 06:12:30 pm
Hallo Mark,

Quote
Are the REXX scripts your describing for me in the package you attached, and
Are there any installation instructions that come with the packages?
Sub directory RM203  contains oinput.cmd and xevents.cmd for your device. That directory also contains testing.txt with installation and test instructions. 

Wim
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Dave Yeo on March 18, 2022, 07:11:27 pm
I already did some ad hoc mapping of various controls into just 4 axis and 4 buttons.
The big challenge is to come up with proper mapping for each usb game controller.

In theory you can query the (HID) device for a feature report. Here's mine for a "046D/C216: Logitech - Logitech Dual Action" joypad,
Code: [Select]
K:\work\hidapitester>idapitester.exe --vidpid 046D:C216 --open --read-feature 0
Opening device, vid/pid: 0x046D/0xC216
Reading 64-byte feature report, report_id 0...read -1 bytes:
 00 FA 00 00 00 D8 55 03 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00
 00 00 00 00 00 09 02 29 00 01 01 00 80 34 00 00 00 74 00 00 00 50 01 03 20 B8 A7 03 20 00 00 00
Closing device

Unluckily it doesn't look straight forward, here's the official document on it, https://www.usb.org/sites/default/files/hut1_2.pdf (https://www.usb.org/sites/default/files/hut1_2.pdf)
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on March 19, 2022, 06:41:23 pm
Hi Wim!

Hallo Mark,

Quote
Are the REXX scripts your describing for me in the package you attached, and
Are there any installation instructions that come with the packages?
Sub directory RM203  contains oinput.cmd and xevents.cmd for your device. That directory also contains testing.txt with installation and test instructions. 

Wim

Will have a look today (Saturday) and see whats there in the package.

Couldn't do that yesterday as I was about 200 km south of the Arctic Circle, at a corporate clients site, using their computers to check my e-mails and sites.

But I'm quite excited about this - hope to have some positive reports to relate soon!

A fine weekend to you Sir and Best!

M
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on March 20, 2022, 01:06:53 am
Hi Wim!

Hope your having a fine weekend!

Hallo Mark,

Quote
Are the REXX scripts your describing for me in the package you attached, and
Are there any installation instructions that come with the packages?
Sub directory RM203  contains oinput.cmd and xevents.cmd for your device. That directory also contains testing.txt with installation and test instructions. 

Wim

As to my current tests

Test environment:

ArcaOS v5.0.7

Equipment tested:

Thrustmaster Pro Joystick attached to Logilink (Padix) Game Port to USB connector in Mode 2 of 4 (reports as 4 axis, 4 button joystick with view finder, under Hidapitester --list)

Installation (USBECD)

Undertaken previously as per instructions Part A - A1 to A2

Verbose boot reports USBECD present and active using the parameters outlined

Test 1 - Buttons

Oinput.cmd worked perfectly. However adding command oinput.cmd > Button.log hung the process until control-c was pressed, so could not generate log. Tried syntax oinput.cmd >button.log. Same result.

Took a screen shot of results instead.

Screen shot Button Test 1 - 4 Buttons (attached)

First Hex set    - Thrustmaster at rest (no buttons pressed)
Second set   - Trigger pressed
Third set   - Trigger released
Fourth Set   - Red button beside Hat pressed
Fifth Set            - Red button beside Hat released
Sixth set            - Red button left side pressed
Seventh set   - Red button left side released
Eighth set   - Red button bottom front pressed
Ninth set   - Red button bottom front released

I have generated a second screen shot, Button Test 1 - Hat (attached) as the Joystick has a viewfinder (Hat) as well.

First Hex set    - Thrustmaster Hat at rest (hat centre position)
Second set   - Hat pressed upwards
Third set   - Hat released
Fourth Set   - Hat pressed downwards
Fifth Set   - Hat released
Sixth set   - Hat pressed left
Seventh set   - Hat released
Eighth set   - Hat pressed right
Ninth set   - Hat released

As mentioned the LOG instructions are not working - do you have any idea why?

Haven't had time today to send a picture of the joystick indicating which button is which - will try to do that tomorrow and Best!

M
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Wim Brul on March 20, 2022, 10:18:34 am
Hi Mark,

I played tennis yesterday for one hour. Good for my health and fun to do.
Quote
Oinput.cmd worked perfectly. However adding command oinput.cmd > Button.log hung the process until control-c was pressed, so could not generate log. Tried syntax oinput.cmd >button.log. Same result.
.
As mentioned the LOG instructions are not working - do you have any idea why?
It seems to me that oinput.cmd > button.log is not working up to your expectation. What you do with the controls is not shown but written to the log instead.

I have no idea what the Thrustmaster Pro Joystick looks like i.e. how many buttons it has and where these are located.
Do you have a picture and description of what controls it has  and how you would use those controls?

Thanks for your efforts sofar!

Wim
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Martin Iturbide on March 20, 2022, 02:00:28 pm
Hi Wim

The joystick is not longer working for me on Makman and DOS GAMES. (Using gamepad-20220317.zip)
I'm using the Huskee adapter with the PS2 gamepad. oinput.cmd and xevent.cmd are working fine, they show me the button strokes, so I guess "gamepad.sys" is working fine too.

I seems to have some problem with teh GAMEDD.SYS and GAMEVDD.SYS talking to the "gamepad.sys", I guess.
Is there something else I can try to find out where my issue can be?

My config.sys:
Quote
DEVICE=X:\OS2\BOOT\USBECD.SYS /D:0C12:0005:0001 /N:$HUSKEE$ /V
Quote
DEVICE=X:\OS2\MDOS\GAMEDD.SYS
DEVICE=X:\OS2\MDOS\GAMEPAD.SYS
DEVICE=X:\OS2\MDOS\GAMEVDD.SYS

Regards

Note: Should we open a new forum thread for USB gamepad testing?
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Wim Brul on March 20, 2022, 03:40:47 pm
Hi Wim

The joystick is not longer working for me on Makman and DOS GAMES. (Using gamepad-20220317.zip)
I'm using the Huskee adapter with the PS2 gamepad. oinput.cmd and xevent.cmd are working fine, they show me the button strokes, so I guess "gamepad.sys" is working fine too.

I seems to have some problem with teh GAMEDD.SYS and GAMEVDD.SYS talking to the "gamepad.sys", I guess.
Is there something else I can try to find out where my issue can be?

Hi Martin,

What did you try? You could try and use the drivers contained in huskee-20211226.zip  which worked on your system before.
Perhaps you need to press the select button? Perhaps you changed something else on your test system?
For dos games setting GAME_DIRECT_ACCESS must be OFF.

Wim
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Martin Iturbide on March 20, 2022, 04:22:35 pm
Hi Wim

I reverted to "huskee-20211226.zip".
- oinput.cmd and xevent.cmd are still working fine. I also noticed that on xevents, the "triangle" button is not providing any action, while on oinput it is working. (EC500000810308008080FFFF10000000)
- It is not working on MakMan and it is not working on DOS Worlfstein (I got to the "Calibrate Joystick" screen and it does not detect any action).
- For DOS Wolfstein, GAME_DIRECT_ACCESS is OFF

I just noticed that Makman used to work with my other gamepad (the one that looks like a NES controller) and I never tested the Huskee on Makman or DOS, because oinput.cmd and xevent.cmd  where working.

Regards
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on March 20, 2022, 07:14:29 pm
Hi Wim!

Hi Mark,

I played tennis yesterday for one hour. Good for my health and fun to do.
Quote
Oinput.cmd worked perfectly. However adding command oinput.cmd > Button.log hung the process until control-c was pressed, so could not generate log. Tried syntax oinput.cmd >button.log. Same result.
.
As mentioned the LOG instructions are not working - do you have any idea why?
It seems to me that oinput.cmd > button.log is not working up to your expectation. What you do with the controls is not shown but written to the log instead.

I have no idea what the Thrustmaster Pro Joystick looks like i.e. how many buttons it has and where these are located.
Do you have a picture and description of what controls it has  and how you would use those controls?

Thanks for your efforts sofar!

Wim

A Happy Vernal Equinox to you - unfortunately after four days of +10 C temps, we are in the teeth of a winter storm on what is supposed to be the first day of Spring - 10 to 20 cm expected here so no tennis today - then should be up to 15 C by Wednesday - just yet another day is this Year of Strange.

Perhaps I misunderstood your instructions, as when I added the syntax > button.log to oinput .cmd it looked like the command line output hung and no output was being generated. Will try again this afternoon when I'm tired watching yet more blowing snow <sic>.

I have attached an annotated photo of the Thrustmaster Joystick below as reference if you are interested (for others looking for the hex output I posted and am referencing below, refer to attachments in my previous post).

Screen shot Button Test 1 - 4 Buttons (attached)

First Hex set    - Thrustmaster at rest (no buttons pressed)
Second set   - Trigger pressed (#1 on the photo)
Third set   - Trigger released
Fourth Set   - Red button beside Hat pressed (#2 on the photo)
Fifth Set            - Red button beside Hat released
Sixth set            - Red button left side pressed (#3 on the photo)
Seventh set   - Red button left side released
Eighth set   - Red button bottom front pressed (#4 on the Phot0)
Ninth set   - Red button bottom front released

The second set of date was generated by the moveable hat at the top of the joystick which in most flight games is used to view various directions in flight.

The joystick is all metal and very durable - it is based on an actual joystick of the HOTAS type (Hands on Throttle and Stick) and actually was the configuration used first on the US F-4 Phantom fighter. It is one of the joysticks which should be recognized immediately by many of the DOS based flight games, so we will see.

Best to you Sir as always!

M

Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Dave Yeo on March 20, 2022, 09:19:31 pm
Hi Mark, at least no snow here.
Try piping through tee, something like,
Code: [Select]
oinput.cmd 2>&1 | tee oinput.log
This will capture both stdout and stderr and split the output so it displays and goes into the log.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on March 20, 2022, 09:38:02 pm
Hi Wim!


It seems to me that oinput.cmd > button.log is not working up to your expectation. What you do with the controls is not shown but written to the log instead.


Okay, I understand whats happening now after your explanation and rereading your testing.txt.

I generated three files, Wim, which I found in the root directory for the operating system partition after completing the tests. They are attached as:

buttonred.log
hat.log
stick.log

The first two essentially are the same as the JPG screenshots I took previously. The third log has the stick data as follows: (I will describe position by standard compass direction - north being forward)

Initial Hex row - stick is centered at rest
First position - stick in north position then centered
Second position - stick pulled south then centered
Third position - stick positioned to the west then centered
Fourth position - stick positioned to the east then centered
Fifth position - stick positioned to the northwest then centered
Sixth position - stick positioned to the northeast then centered
Seventh position - stick positioned to the southeast then centered
Eighth position - stick positioned to the southwest then centered

Let me know if you wanted any further tests related to Part A.

I will proceed to Part B shortly, after I install your drivers and reboot.

Best!

Mark


Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on March 20, 2022, 09:47:23 pm
Heh Dave!

Hi Mark, at least no snow here.
Try piping through tee, something like,
Code: [Select]
oinput.cmd 2>&1 | tee oinput.log
This will capture both stdout and stderr and split the output so it displays and goes into the log.

We just got rid of all the snow on the roads porches and pads and all the ice I chopped, and suddenly we're having a stormy temper tantrum on the first day of Spring - blowing like hell, visibility zero and covering up all my efforts with 10-20 cm of snow, at least for today.

I had enough of that up in Norman Wells last week - can't seem to get rid of it (Grrrrr.....)

Finally got what Wim was saying and posted the logs he requested (didn't realize it was a redirect as no info was seen on the command line - get it now after finding the logs in my root directory) - will install the DD's next and see what happens ....... !

M
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on March 20, 2022, 10:50:50 pm
Hi Wim!


It seems to me that oinput.cmd > button.log is not working up to your expectation. What you do with the controls is not shown but written to the log instead.

I have no idea what the Thrustmaster Pro Joystick looks like i.e. how many buttons it has and where these are located.
Do you have a picture and description of what controls it has  and how you would use those controls?

Thanks for your efforts so far!

Wim

Moved on to Part B of the testing you requested.

Installed the three drivers you provided in D:\OS2\MDOS\ which is one of my operating system partitions. In the CONFIG.SYS I placed the drivers below the statement for your USBECD.SYS which I assumed was a necessary perquisite to using the drivers.

Running xevents.cmd the following happened:

1) pressing each of the 4 red buttons in turn generated no return hex data (ie. it seems none of them were recognized).

2) pressing the HAT controller in each of the 4 directions I indicated previously generated a return hex line in the command window, both when pressed and when released.

3) pushing and pulling the stick in each of the directions indicated previously generated a return hex line in the command window.

I undertook each of steps 1) to 3) above five times to verify the results. At one point I thought I may have received feedback from one of the red buttons, but I put it down to jiggling the stick slightly while pressing the button, as I could not reproduce the one result noted.

I realize now I did not explain the use of all the buttons - the hat as mentioned is usually used to view in various directions. The trigger is self explanatory. Usually the button beside the hat is used for weapons selection, and the two other buttons can perform a variety of programmable functions, based on the game being played. If it is a game not to do with a warplane, the various buttons may have other functions - as the Thrustmaster was very prevalent as a joystick in the DOS era, most DOS menus requiring a joystick had menu choices which coded to use the 4 buttons and hat in various creative ways).

Hope that helps out for the moment, Wim - as always don't hesitate to let me know if I can provide anything further and Best!

Mark
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Wim Brul on March 21, 2022, 12:41:27 pm
Hi Mark,

Quote
Running xevents.cmd the following happened:

1) pressing each of the 4 red buttons in turn generated no return hex data (ie. it seems none of them were recognized).

Oops, my mistake. You will have to modify xevents.cmd line 98 as follows:

From: "button = c2d(substr(oiBuffer,8+0,1))" into "button = c2d(substr(oiBuffer,8+1,1))"

Good luck!

Wim
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on March 21, 2022, 03:23:33 pm
Hi Wim!

Starting the day here - snow storm over and expecting first 7 C today then 10 C and a high of 15 C on Wednesday, so on Spring plus 1 we're getting back on course.


Oops, my mistake. You will have to modify xevents.cmd line 98 as follows:

From: "button = c2d(substr(oiBuffer,8+0,1))" into "button = c2d(substr(oiBuffer,8+1,1))"

Good luck!

Wim

Yup as you mentioned one slight change to line 98 fixed the problem - Philosophically, its amazing to think that 1"s and 0"s run our world, and having "one" instead of the other could result in a disaster <sic>.

Have to shovel yet again as probably 10 cm of heavy wet snow on the ground at the moment - will try to continue part B of the testing later today.

Best of the start of the week to you!

M
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on March 22, 2022, 01:35:05 am
Hi All!

Haven't had time today to do much testing, as I had to deal with our weather related issues after the snow storm here (where it is a balmy 10 C at the moment - CRAZY).

However I was thinking about the testing of the drivers Wim supplied and thought of a number of questions related to same:
(addressed these to a number of likely people with answers but others can jump in)

2Wim - Wim, will your current drivers work natively under ArcaOS as well? (ie. if there is a native ArcaOS game that uses a joystick, could the joystick be used with the drivers, as you've programmed them currently?)

2Martin - Martin - Do you know of a native ArcaOS game that would use a game controller (Have Galactic Civilizations, but not installed at the moment - can't recall if that had a controller option - or possibly Trials of Battle?)

2Jochen - Is there anything that is needed to do specifically under the current version of DOSBOX, other than modifying DOSBOX.conf to recognize the Joystick? Or is that currently possible under your latest version? Any additional specific library dependencies? I have both SDL 1.2.15-5 and SDL2 2.0.18-1 installed as well as the experimental release of HIDAPI and USB1 packages, if needed.

I'm currently relearning how to use a program template to play DOS based games after modifying the DOS settings - been a while as I pretty well use DOSBOX exclusively. If someone can suggest a DOS game that has worked (eg. Wolfenstein, which I think Wim mentioned) along with the DOS settings used. If so I will try to duplicate that result as a first step.

Thought I might as well hit all the bases in the testing process before I take a stab at this. Success or failure could be because I either have not set things up correctly, or there are issues with the drivers in beta, so I want to ensure iI eliminate the tester as a factor before I report back.

Best to all!

M

Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Jochen Schäfer on March 22, 2022, 11:22:28 am
2Jochen - Is there anything that is needed to do specifically under the current version of DOSBOX, other than modifying DOSBOX.conf to recognize the Joystick? Or is that currently possible under your latest version? Any additional specific library dependencies? I have both SDL 1.2.15-5 and SDL2 2.0.18-1 installed as well as the experimental release of HIDAPI and USB1 packages, if needed.
If you download the WPI, then you get notified of missing dependencies.
If Wim's driver shows up as native OS/2 joystick, it should work with Dosbox, because the native OS/2 api for joysticks is supported.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Wim Brul on March 22, 2022, 05:37:26 pm
Quote
2Wim - Wim, will your current drivers work natively under ArcaOS as well? (ie. if there is a native ArcaOS game that uses a joystick, could the joystick be used with the drivers, as you've programmed them currently?)
Yes Mark, in an ideal world, it will work as long as the native ArcaOS game uses the GAME$ device for its joystick access. Right now it is still very experimental.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on March 22, 2022, 11:31:09 pm
Hi Wim!

Quote
2Wim - Wim, will your current drivers work natively under ArcaOS as well? (ie. if there is a native ArcaOS game that uses a joystick, could the joystick be used with the drivers, as you've programmed them currently?)
Yes Mark, in an ideal world, it will work as long as the native ArcaOS game uses the GAME$ device for its joystick access. Right now it is still very experimental.

Busy day today.

Just one follow-up question - was the GAME$ device what was used previously in the original incarnation of GAMEDD.SYS? I ask because obviously if I can find a native OS/2 program that used the original GAMEDD.SYS to access a Joystick, I assume it should conform to your native driver as well.

M
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on March 22, 2022, 11:41:53 pm
Hi Jochen!

If you download the WPI, then you get notified of missing dependencies.
If Wim's driver shows up as native OS/2 joystick, it should work with Dosbox, because the native OS/2 api for joysticks is supported.

I believe that I installed DOSBOX 0.72 the last time in late 2020.

Has there been any changes that would affect this testing since then?

Obviously, if another WPI install has not occurred since then I would not be aware of any changes in dependencies (BTW that's indeed a nice touch, Jochen, and very conscientious - I wish all packages I've installed in the past would have those same dependencies defined up front).

Best!

M

Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on March 23, 2022, 01:28:42 am
Hi Wim!

Yes Mark, in an ideal world, it will work as long as the native ArcaOS game uses the GAME$ device for its joystick access. Right now it is still very experimental.

Did some preliminary experiments using a DOS program - an attack helicopter flight program called Comanche 2. I was able to get the correct DOS settings to get it to work as a virtual DOS program without DOSBOX.

Running xevents.cmd at the same time as opening a fullscreen version of the program, I attempted to start a training mission. Opening the control options I switched the controls to the Thrustmaster System and attempted to calibrate the joystick, using the instructions presented. In all cases I could not produce any feedback from the joystick within the program. I've attached the xevents.log for your review.

I pressed first buttons 1-4, then the hat and then moved the joystick to all four compass points. In all cases no changes were noted within the DOS program. I then exited to review the log generated.

The log indicated that the joystick was identified by xevents.cmd and was generating output hex lines while I had Comanche 2 open, but it looks like nothing was being passed at all to the virtual DOS session. I will try a number of other programs, if I can get them running through the virtual DOS framework in ARCAOS, as opposed to DOSBOX, but I suspect I will achieve the same result. I would suggest that the DD driver is not passing the information we are seeing in xevents on to the operating system.

I would like to test the gamedd.sys natively in OS/2 but have run into some snags.

I do have a copy of Brad Wardells OS/2 game Trials of Battle (it only was released as v1.0), and have installed it, as it is supposed to have the ability to pass Joystick information to the program, but I suspect as it was optimized for DIVE and DART at the time of release, that it is having some problems with my newer systems, as the program hard locks after a minute or two when attempting to enter a battle. There may be a solution or fix that I've seen previously, adding a line to CONFIG.SYS, but it escapes me at the moment. Testing in the native operating system would go a long way to seeing where the problem may seem to lie.

Anyway, off for my evening exercise ride - let me know if there is anything else I can provide and Best!

Mark

Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Wim Brul on March 23, 2022, 04:34:16 pm
Hi Mark.
Quote
Just one follow-up question - was the GAME$ device what was used previously in the original incarnation of GAMEDD.SYS? I ask because obviously if I can find a native OS/2 program that used the original GAMEDD.SYS to access a Joystick, I assume it should conform to your native driver as well.
Yes. The original one as in joystick.zip from IBM.

Quote
The log indicated that the joystick was identified by xevents.cmd and was generating output hex lines while I had Comanche 2 open, but it looks like nothing was being passed at all to the virtual DOS session. I will try a number of other programs, if I can get them running through the virtual DOS framework in ARCAOS, as opposed to DOSBOX, but I suspect I will achieve the same result. I would suggest that the DD driver is not passing the information we are seeing in xevents on to the operating system.
Perhaps it is necessary to swap the joystick axis in xevents.cmd. Make lines 94 thru 97 be as follows:

Ax = substr(oiBuffer,8+6,1)||x2c(00)
Ay = substr(oiBuffer,8+7,1)||x2c(00)
Bx = substr(oiBuffer,8+4,1)||x2c(00)
By = substr(oiBuffer,8+5,1)||x2c(00)

Wim
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on March 24, 2022, 01:11:33 am
Hi Wim!

Changed the axis statements in xevents.cmd, as requested, and had the same result - the xevents log had information in it, but nothing was passed on to the virtual DOS session, as far as I can determine - I am curious - do the results in xevents affect the device drivers themselves, or just monitor what is happening?

I suspect its the device drivers are not addressing the programs - I think usbecs is finding the joystick but it  is not passing on the info to first the native operating system, then the virtual operating system, through first the native and then the virtual device drivers.

Is there someway to test that, and Best!

M
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Wim Brul on March 24, 2022, 05:40:30 pm
Hi Mark,
Quote
- I am curious - do the results in xevents affect the device drivers themselves, or just monitor what is happening?
Strictly speaking, the results reported and logged by xevents.cmd reflect what it is about to write to the gamepad.sys driver. No error means success!

Quote
I suspect its the device drivers are not addressing the programs - I think usbecs is finding the joystick but it  is not passing on the info to first the native operating system, then the virtual operating system, through first the native and then the virtual device drivers. Is there someway to test that, and Best!
I don't think so. I have used JOYS_DOS.EXE from GAMEDD2.ZIP which is a DOS executable to test gamepad/joystick functionality and that works.
Perhaps the best way for you to proceed is getting DOSBOX_WOLF3D.ZIP and install that. I am able to run that DOS game over here.
For that particular game I used GAME_DIRECT_ACCESS = OFF and GAME_DIGITAL_RESPONSE = OFF settings.

Wim
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on March 24, 2022, 06:13:19 pm
Hi Wim!


I don't think so. I have used JOYS_DOS.EXE from GAMEDD2.ZIP which is a DOS executable to test gamepad/joystick functionality and that works.
Perhaps the best way for you to proceed is getting DOSBOX_WOLF3D.ZIP and install that. I am able to run that DOS game over here.
For that particular game I used GAME_DIRECT_ACCESS = OFF and GAME_DIGITAL_RESPONSE = OFF settings.

Wim

I think my next step will be to try to duplicate your results.

I downloaeded a copy of DOSBOX_WOLF3D.ZIP and am looked for a copy of GAMEDD2.ZIP to try the same test, but I suspect with the Hobbes reorg Martin is doing it may be unavailable at the moment, as Hobbes doesn't come up with anything  - I will also check my archives as well as, being a packrat, I may have a copy of it somewhere here.

Give me a couple of days and I will see what further data I can come up with.

M
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Martin Iturbide on March 24, 2022, 06:59:06 pm
... and am looked for a copy of GAMEDD2.ZIP to try the same test
Hi

The GAMEDD are here in hobbes (https://hobbes.nmsu.edu/?dir=%2F&stype=all&sort=type_name&search=GAMEDD).

Regards
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on March 29, 2022, 02:44:14 am
Hi All!

Have not been idle for the last few days, but want to check my testing results.

Bottom line - I have got DOS based games to recognize the joystick, but had to adjust a number of DOS settings to get some results, with Wim's drivers - still evaluating what exactly is going on. But as with everything experimental, order and method prevails (ala Agatha Christie's Hercules Poirot) - want to run a number of tests in the next few days first.

2Wim - one new question - looking at the documentation in the gamedd2 package that I downloaded from Hobbes - is your version of gamedd.sys based on that package, and do the possible switches that are itemized in the .TXT file in that package apply to your gamedd.sys driver?

May or not be important to my testing, but thought I'd check and Best!

Mark

Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Wim Brul on March 29, 2022, 10:56:46 am
Hi Mark,
Quote
2Wim - one new question - looking at the documentation in the gamedd2 package that I downloaded from Hobbes - is your version of gamedd.sys based on that package, and do the possible switches that are itemized in the .TXT file in that package apply to your gamedd.sys driver?
No, not at all. My version of gamedd.sys originates from joystick source code present in IBM Device Driver Kit (DDK) for OS/2.
Apart from modifications to interface with my new gamepad.sys device driver I had to add missing bios joystick functionality.

Wim
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Lars on March 29, 2022, 05:55:56 pm
How does this all relate to :
https://github.com/OS2World/DRV-USBLib/tree/master/drivers/src/usbjoy

Is the gamepad a USB device ? If yes, should we not modify those USB joystick drivers to interface with GAMEDD.SYS ? That's at least how it was solved for the USB mouse:
we have USBMOUSE.SYS and that interfaces with AMOUSE.SYS / MOUSE.SYS.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on March 29, 2022, 11:52:52 pm
Hi Wim (and Lars)

Hi Mark,
Quote
2Wim - one new question - looking at the documentation in the gamedd2 package that I downloaded from Hobbes - is your version of gamedd.sys based on that package, and do the possible switches that are itemized in the .TXT file in that package apply to your gamedd.sys driver?
No, not at all. My version of gamedd.sys originates from joystick source code present in IBM Device Driver Kit (DDK) for OS/2.
Apart from modifications to interface with my new gamepad.sys device driver I had to add missing bios joystick functionality.

Wim

As this is a legacy joystick (Thrustmaster Mk.2 - gameport connection with a Logilink gameport to USB adapter) I was curious as to what would happen (or not) if I added the switch /TM to the gamedd.sys line (this switch is supposed to report a Thrustmaster joystick or equivalent as per the GAMEDD2.ZIP text file). The joystick, after I sorted out the DOS game settings, is behaving rather strangely, which could be related to the programming of the device driver, or could be due to the settings I'm using. I was trying to sort that out before reporting anything - I'm also trying to see what I get with a couple of other DOS game programs but, as I normally have those programs working perfectly in DOSBOX (minus the joystick - ie. mouse and keyboard) I need to determine the right settings in an ArcaOS DOS session and want to see if what is happening is consistent in other programs as well, before reporting back.

2Lars - as this is not a native USB device (ie. a rather clever jury rig by Padix, based on connecting an old game controller) I'm wanting to see what is happening with it first and why, hence my quation to Wim - I'm rather tempted at the moment to buy a current USB based Joystick, if such exist, for comparison purposes but will see what happens here first.

Best to the both of your gentlemen!

Mark
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on April 02, 2022, 08:54:50 pm
Hi All!

Its been a very busy couple of weeks, as tax season both personal and corporate is upon me at the moment in Canada, as well as transferring my websites to a new service provider. But I can say that I have been doing a lot of testing of Wim's drivers for game controllers in between. I can report some success in the process, and would like to share what I have found so far. 

Bottom line if you need a summary at the start: Wim Brul has made a significant contribution to moving game controller use forward under ArcaOS and other legacy OS's before it, with USB, however I suspect there is still things to do. Here's what I found so far, using a legacy Joystick (Thrustmaster Mk. II).

My testing focused on three areas at the moment:

1) Seeing if the current drivers could be used in a virtual DOS session, natively under ArcaOS (all my main systems are currently using v5.0.7)

2) Seeing if the drivers could be used with my joystick under the most current version of DOSBOX ported by Jochen for ArcaOS / eCS / OS/2 (an SDL based emulation).

3) Seeing if the drivers would allow me to use the joystick with a native OS/2 game (to my knowledge very few and far between, especially games that had game controller support)

For 1) above, using the joystick under a Virtual DOS Session

I will not go into all the testing details provided by Wim as this post is long enough already - if you would like to see his very detailed instructions, please download GAMEPAD-2022-03-17.zip, which Wim attached to one of his previous posts in this thread. I am currently putting together a testing guide based on what Wim has produced in the past, and additional items I've discovered during my current testing, which I hope to have available in the next few days. 

After confirming that things worked properly with first Wim's usbecd.sys and then the drivers which Wim kindly produced for us, for my Thrustmaster Joystick, I got two programs working in a virtual DOS session as follows:

Comanche 2 by Novalogic (1995) - an attack helicopter flight simulator of the never produced US AH-66 Comanche helicopter. Novalogic produced four separate versions of this software program, but I chose this one, as I have worked with it in the past, and also have had a copy of this running perfectly on DOSBOX. It also specifically supports the Thrustmaster Flight Control system as one of the built-in options.

Castle Wolfenstein 3D - One of the first of ID's many successful "shoot'em up" games, same era as Comanche 2. I chose getting this game running for testing as:

1) I understand Wim had tested his drivers on it with game pad controller(s) provided by Martin Iturbide, and was able to use them successfully

2) The program actually provides visual indications as to whether the program is detecting certain equipment, including joysticks and sound cards.

My original testing was not producing any results (controls not recognized), until I realized one thing, and then correctly set the second thing (ie. DOS session settings):

FIRST - assuming the device drivers are installed properly, it is VERY important to have xevents.cmd running in the background, while playing the game (can be enabled through a windowed ArcaOS command prompt) - otherwise the game will not recognize the joystick is there at all

SECOND - at least for my Joystick the DOS Session Settings GAME_DIGITAL_RESPONSE and GAME_DIRECT_ACCESS must both be set to OFF.

With the settings identified above, for COMANCHE 2 first, I was able to calibrate the joystick (a necessary step in COMANCHE 2, each time I played), and got the joystick to be recognized during flight tests.

If GAME_DIGITAL_RESPONSE was enabled, I could calibrate, but no buttons were recognized in flight and the stick would only work if I pulled back on the joystick, essentially backing up the helicopter in flight. With GAME_DIRECT_ACCESS enabled, I could not even calibrate the joystick, as no control functions were recognized at all.

With the correct settings I was able to both fly and complete a simple mission. However:

1) No buttons on the joystick were recognized other than the trigger button (there are four buttons in all - don't know if they define the first button as 0 or 1). The trigger could lose focus and suddenly not fire the weapon selected, and would require the key with the same function on the keyboard to be used, to reengage the joystick.

2) The hat (viewfinder) could not be used at the top of the joystick (in one case which I could not reproduce, the hat did give directional view control, but then locked the game, and I could not reproduce this again).

2Wim -  if you recall we reversed the lines governing axis control in xevents.cmd to see if that was the problem related to the program not seeing the joystick - I went back to the original xevents.cmd, as I found with the modified version, the hat in COMANCHE was actually sending the directional control signals, normally generated by moving the joystick. OOOPS

3) While the joystick could be moved and used successfully, directionally, to guide the aircraft, it would often lose focus (ie. the joystick would suddenly not turn or move the aircraft, or would continue to turn or move the aircraft endlessly, based on the last stick position). Using the same control function on the keyboard for a second or two would reengage the joystick but it could lose focus again at any time.

As to Castle Wolfenstein I was able, first, to get it loaded but in a rather ugly fashion - it does run well, with the DOS session settings I'm using, but you seem to have to push a random number of buttons during loading to get the starting screens to display on screen - if someone has a sure fire set of DOS session settings to get it loading nicely, please let me know!

As to sound for both COMANCHE and WOLF3D in a viretual DOS session I'm still puzzling over what SET BLASTER settings to use successfully in AUTOEXEC.BAT for both, if such can be done. Any suggestions welcome.

When Wolfenstein loads the first screen it indicates, with the settings described previously, that a joystick is present. Calibrating the joystick was a bit difficult, as the program didn't seem to recognize some button presses, but I eventually was able to calibrate the joystick and got both the trigger button (identified as button 0 in the program) and button 1 (which I mapped to open doors) to work. Wolfenstein did not identify either of buttons 2 or 3 although it indicates that buttons 0-3 can be used).

Running the program with those settings I was able to play the game, but found very similar to COMANCHE 2 that the joystick could lose focus, directionally and required the key strokes on the keyboard to occur, to get the joystick to function correctly again.

Buttons 0 and 1 (based on WOLF3D's definitions) remained the same, and did not lose focus.

Once the joystick calibration occurred in Wolfenstein, I have not needed to calibrate again thankfully.

All for now in this post - tests for the other items in another post and Best!

M
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on April 02, 2022, 09:02:42 pm
Hello again!

As to testing DOSBOX with Wim's drivers ...........

Not as long a post as the previous.

I used the same two games for comparison purposes for device driver testing purposes:

1) Comanche 2
2) Castle Wolfenstein 3D

I could have used a large number of DOS games as I currently have 65 separate legacy DOS games working under DOSBOX thanks to Jochen's and others efforts, but I wanted to use the same two games for comparison purposes, as the two games above both work perfectly under ArcaOS DOSBOX, other than not being able to use a joystick or other game controllers in the past.

DOSBOX for ArcaOS has the ability to support game controllers through file DOS.conf which includes a section related to game controllers reproduced below

[joystick]
#  joysticktype: Type of joystick to emulate: auto (default), none,
#                  2axis (supports two joysticks),
#                  4axis (supports one joystick, first joystick used),
#                  4axis_2 (supports one joystick, second joystick used),
#                  fcs (Thrustmaster), ch (CH Flightstick).
#                  none disables joystick emulation.
#                  auto chooses emulation depending on real joystick(s).
#                  (Remember to reset dosbox's mapperfile if you saved it earlier)
#                  Possible values: auto, 2axis, 4axis, 4axis_2, fcs, ch, none.
#                  timed: enable timed intervals for axis. Experiment with this option, if your joystick drifts (away).
#                  autofire: continuously fires as long as you keep the button pressed.
#                  buttonwrap: enable button wrapping at the number of emulated buttons.

joysticktype  = auto
timed         = true
autofire      = false
buttonwrap    = false

The default joystick type as above is "auto". Enabling xevents.cmd, I was unable to get DOSBOX to recognize the joystick in either program using the default setting.

However, changing "auto" to either "fcs" or "4axis", DOSBOX did seem to detect the joystick - however, attempting to calibrate the joystick in either COMANCHE 2 or WOLF3D, it did not seem to recognize any of the buttons, joystick movements or the hat, so I was unable to use a joystick under DOSBOX, currently.

I was able to determine that WOLF3D seems to find the joystick based on visual clues in the start windows. Set to "auto", in DOS.conf, a yellow light does not appear by the joystick in the WOLF3D start screen, whereas with either "fcs" or "4axis" as the setting, it does. I was able to get to the calibration window and tried to calibrate the joystick, but DOSBOX did not seem to recognize any of the buttons on the joystick, which is a necessary step to complete the calibration.

So, DOSBOX, while finding the joystick, still was not able to use it. If anyone has any ideas why, I'm certainly willing to test further and Best!

M
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on April 02, 2022, 09:08:04 pm
Hi All Again!

The last of my testing posts.

This relates to testing Joystick Support under native ArcaOS

As to the last of my current test regime, I really have little to report specifically related to being able to test Wims game controller device drivers.

I have access to two possible OS/2 based games which seemed likely candidates for testing:

1) Trials of Battle (a native OS/2 program developed by Stardock Systems in their OS/2 heyday, which is a battle game using tank like vehicles to fight in either single player mode or multiplayer via network)

2) QuakeOS2 (a version of the popular Quake game of the time which was ported in the 90's when advocates were urging IBM to develop OS/2 as a gaming platform, in addition to a commercial one)

In the first case I have a commercial version of the program, which I purchased when it was released. Reinstalling the program, which requires the disk to remain in a CD drive, I was able to successfuly start it, but, on entering a battle, the system locks hard and requires a reboot after about 20 seconds.

Trials of Battle was released at just about the time IBM decided to pull further development support of OS/2, so Brad Wardell was not pleased, and this program never got past v1.0 and was quickly terminated by Stardock. It relies heavily on both DIVE and DART in its programming, so that may be the problem related to those lock-ups.

If anyone has got Trials of Battle working properly under ArcaOS, let me know what you did and I will attempt to duplicate. Any other suggestions welcome as well.

The QuakeOS2 port as I understand it used the Linux version as its base and the EMX runtime. Looking in my archives I found a copy of a very early port, but have been unable to get it running. If there is a working copy of QuakeOS2 out there again let me know and I will try that as well.

Otherwise I'm out of ideas as to how to test the joystick natively under the operating system, Guys. If anyone has any suggestions as to another program that may work under ArcaOS, let me know.

All for now - hope this testing I've done helps to advance the cause of getting these game controllers working properly, and I think we need to give Wim Brul, as always, a big round of thanks for all his efforts in this regard.

Best to all this weekend!

Mark
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on April 03, 2022, 07:05:50 pm
Hi All!


SECOND - at least for my Joystick the DOS Session Settings GAME_DIGITAL_RESPONSE and GAME_DIRECT_ACCESS must both be set to OFF.


I was puzzled as to what these settings actually do  when I was playing with them, as the built-in DOS session setting list under ArcaOS for these provides no explanations as to their function.

Doing a little research I found a detailed  explanation as to their function at the EDM/2 site which I thought I'd share, for anyone interested:

http://www.edm2.com/index.php/Input/Output_Device_Driver_Reference/Joystick_Device_Driver

________________________

GAME_DIRECT_ACCESS

OFF    The default setting. This prevents the DOS program from talking directly to the game port and thus allows the joystick device driver to do its work.

ON     This setting essentially disables the device driver by giving the DOS program direct access to the game port. You should only enable this setting if you are having problems with control of a DOS game and suspect that the joystick device driver may be at fault. This is also useful for testing the difference between having the device driver enabled and disabled for a particular game.

Based on current testing, this setting should always be OFF, unless you want to test game function without your game controller device involved.

________________________

GAME_DIGITAL_RESPONSE
 
ON    The default setting. When this option is enabled, the device driver reports information back to the DOS program in such a way as to make your joystick look digital even if it is analog.

OFF   Analog joysticks will look like analog joysticks.

The joystick I am using, the legacy Thrustmaster Mk II is analog in nature, so it made sense that the OFF setting would be preferred, based on the explanation above.

If you are using a USB based joystick or game pad (the majority of which are digital in nature) I would suggest to set this setting to ON first, if your doing testing. If strange responses to your game controller occur, try this setting on OFF and see what happens.

Best!

Mark
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Martin Iturbide on April 04, 2022, 09:38:15 pm
Hi

I found my issue with MakMan.

- ArcaOS 5.0.4
- USB gamepad PCSIGP  081#:##01:0106
- gamepad-20220317.zip  Installed
- oinput.cmd and xevents.cmd showing feedback while pressing the gamepad buttons

Makman was working, with an older test release, as Jostick B, and stopped working for me with the latest release. But it was because I was missing something important from the instrucctions.
"I have to keep "xevents.cmd" running on the background". When "xevents.cmd" keeps running in the command line the USB gamepad works with Makman as joypad B.

Now, I have some issue with Wolf3D (DOS VDM).
- I keep running "xevent.cmd" the background
- Now when I run Wolf3d and ask me to press a key, I can press the gamepad button and will continue (means the USB Gamepad is being recognized in some way by the DOS game).
When I go to the WolF3D menu and select "Jostick", it asks me to caligrabrate the joystick. Now the buttons works, First it ask me to press "Upper Left + Button 0", and Later "Lower Righ + Button 1", it works ,but when I finish the Joystick "yellow light" does not turn on and I keep on the same configuration loop.

I need to further test other DOS VDM software.

Regards
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Martin Iturbide on April 04, 2022, 10:00:42 pm
Hi

Just checking online. This DOS Joystick Testing utilities works with my VDM DOS session with my USB game pad ("xevents.cmd" running on the background).

Check it out: (DOS_Joystick_Testing_Utilities.zip (https://www.vogons.org/download/file.php?id=7643))

Here it is a quick video I made with my phone: https://youtu.be/tw1VOcdxnHc (https://youtu.be/tw1VOcdxnHc)

Regards
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on April 04, 2022, 11:26:31 pm
Heh Martin!

Hi

I found my issue with MakMan.

- ArcaOS 5.0.4
- USB gamepad PCSIGP  081#:##01:0106
- gamepad-20220317.zip  Installed
- oinput.cmd and xevents.cmd showing feedback while pressing the gamepad buttons

Makman was working, with an older test release, as Jostick B, and stopped working for me with the latest release. But it was because I was missing something important from the instrucctions.
"I have to keep "xevents.cmd" running on the background". When "xevents.cmd" keeps running in the command line the USB gamepad works with Makman as joypad B.

Now, I have some issue with Wolf3D (DOS VDM).
- I keep running "xevent.cmd" the background
- Now when I run Wolf3d and ask me to press a key, I can press the gamepad button and will continue (means the USB Gamepad is being recognized in some way by the DOS game).
When I go to the WolF3D menu and select "Jostick", it asks me to caligrabrate the joystick. Now the buttons works, First it ask me to press "Upper Left + Button 0", and Later "Lower Righ + Button 1", it works ,but when I finish the Joystick "yellow light" does not turn on and I keep on the same configuration loop.

I need to further test other DOS VDM software.

Regards

Out of curiosity what other DOS game related settings are you using to run WOLF3D (other than GAME_DIRECT_ACCESS and GAME_DIGITAL_RESPONSE)?

As I said the VDM I set up has some start-up problems - I haven't had time to play with the other settings to see what I can do to solve it.

As to your button problem for calibration, was GAME_DIGITAL_RESPONSE set to ON or OFF at the time? That may make a difference as to whether the button response was acting correctly during calibration. You might want to try the opposite setting to what it currently is, to see if that makes any difference. Also there is an OPTIONS setting further down that menu, where you can change the button settings - you may wish to see if you can do that, which may also indicate whether your game pad is being seen.

When I did the calibration routine it took a number of presses to get the joystick to be recognized, both shifting it (the joystick) to top left and pressing button 0 (the trigger) and then shifting it to bottom right (and then pressing button 1) - once I was able to complete calibration, I haven't had to do it again.

Best!

M
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Martin Iturbide on April 05, 2022, 02:56:44 pm
Hi Mark
Out of curiosity what other DOS game related settings are you using to run WOLF3D (other than GAME_DIRECT_ACCESS and GAME_DIGITAL_RESPONSE)?
I have:
- GAME_DIRECT_ACCESS - OFF
- GAME_DIGITAL_RESPONSE - ON
I think both are the default.

If I change  GAME_DIGITAL_RESPONSE  to OFF I don't see a difference. But I'm guessing that is some issue with Wolf3D or how do I interpret joystick calibration should work. I got good results with the Joystick testing tool I found (https://www.vogons.org/download/file.php?id=7643) and the default DOS VDM settings.

I need some more time to try other games. I will try to find some DOS DOOM and see what happens.

Regards
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on April 05, 2022, 06:43:34 pm
Hi Martin!

I have:
- GAME_DIRECT_ACCESS - OFF
- GAME_DIGITAL_RESPONSE - ON
I think both are the default.

If I change  GAME_DIGITAL_RESPONSE  to OFF I don't see a difference. But I'm guessing that is some issue with Wolf3D or how do I interpret joystick calibration should work. I got good results with the Joystick testing tool I found (https://www.vogons.org/download/file.php?id=7643) and the default DOS VDM settings.

I need some more time to try other games. I will try to find some DOS DOOM and see what happens.

Regards

I was curious about something.

In the CONTROLS section of my version of WOLF3D, I have both a JOYSTICK button, which if pressed goes into the calibration sequence you described, for a joystick.

However, two menu items below that it has a button setting entitled "GRAVIS GAME PAD ENABLED".

Do you have that setting, and if so have you tried that with your Game Pad?

M

P.S. BTW I completed a DRAFT of a Game Controller Testing Guide, in PDF, which I have attached below. Its really a first cut at documenting some standardized way to do this testing,  and answering a few questions I have asked, myself, as I've been going through this process - it may be too early to have something like this for use by others, but if you want to have a look and see if you think it would be useful, with any comments, that would be great!

Best!

M Too
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Martin Iturbide on April 05, 2022, 10:21:01 pm
Hi

I found an issue. I was running Quake 1.01 on DOS VMD. (DOS Quake, not OS/2). It recogniced the gamepad (button 1 and button 2 only, I can not make the axis work yet).
If I unplugged suddenly the USB gamepad, I get this OS/2 trap on USBEHCD.
Workarround: Do not unplugg the gamepad  ;D

Let me know if the trap also happens on other systems, and also whatever data is needed to try to debug this.

Regards
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Martin Iturbide on April 05, 2022, 11:39:36 pm
In the CONTROLS section of my version of WOLF3D, I have both a JOYSTICK button, which if pressed goes into the calibration sequence you described, for a joystick.

However, two menu items below that it has a button setting entitled "GRAVIS GAME PAD ENABLED".

Do you have that setting, and if so have you tried that with your Game Pad?
When I run Wolfenstein, on the first screen I see the joystick in "yellow". I can press a button on the USB gamepad to continue. (picture 001)
But when I go to "Control - Joystick Enable" I do the calibration but the "yellow light" does not show up (picture 002)
If I go to "Customize Control" it jumps from "Mouse" to "Keyboard" and do not let me change anything on "Joystick".

I'm still not sure if it something I'm doing wrong.

P.S. BTW I completed a DRAFT of a Game Controller Testing Guide, in PDF, which I have attached below. Its really a first cut at documenting some standardized way to do this testing,  and answering a few questions I have asked, myself, as I've been going through this process - it may be too early to have something like this for use by others, but if you want to have a look and see if you think it would be useful, with any comments, that would be great!
I had read the document and it is very good. It describes in a very good fashion how to do the USB gamepad testing.
I can also publish it on the OS2World wiki if you want to.  As I next step I want to learn more about tweaking the "xevents.cmd" to map the buttons.

Regards
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Dave Yeo on April 06, 2022, 02:01:22 am
I found an issue. I was running Quake 1.01 on DOS VMD. (DOS Quake, not OS/2). It recogniced the gamepad (button 1 and button 2 only, I can not make the axis work yet).
If I unplugged suddenly the USB gamepad, I get this OS/2 trap on USBEHCD.
Workarround: Do not unplugg the gamepad  ;D

Let me know if the trap also happens on other systems, and also whatever data is needed to try to debug this.


Looks like something to open an issue up with, assuming you're using the Arca Noae USB stack
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Wim Brul on April 06, 2022, 11:27:51 am
Hi Martin,
Quote
Now when I run Wolf3d and ask me to press a key, I can press the gamepad button and will continue (means the USB Gamepad is being recognized in some way by the DOS game).
When I go to the WolF3D menu and select "Jostick", it asks me to calibrate the joystick. Now the buttons works, First it ask me to press "Upper Left + Button 0", and Later "Lower Righ + Button 1", it works ,but when I finish the Joystick "yellow light" does not turn on and I keep on the same configuration loop.
I tried and reproduced your wolf3d calibration problem. You need to press select button once and then do the calibration. That will work. Apparently you became victim of xevent.cmd builtin joystick axis swap function. In hindsight I think it is better to remove that function altogether. Will do so in the future. You could use TMScope Setup Utility (thank you for finding) to see what your gamepad delivers. See tms0.png for hardware setup, tms1.png for upper-left position, tms2.png for lower-right position.

Regards, Wim.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Martin Iturbide on April 06, 2022, 02:51:03 pm
Hi Martin,
Quote
Now when I run Wolf3d and ask me to press a key, I can press the gamepad button and will continue (means the USB Gamepad is being recognized in some way by the DOS game).
When I go to the WolF3D menu and select "Jostick", it asks me to calibrate the joystick. Now the buttons works, First it ask me to press "Upper Left + Button 0", and Later "Lower Righ + Button 1", it works ,but when I finish the Joystick "yellow light" does not turn on and I keep on the same configuration loop.
I tried and reproduced your wolf3d calibration problem. You need to press select button once and then do the calibration. That will work. Apparently you became victim of xevent.cmd builtin joystick axis swap function. In hindsight I think it is better to remove that function altogether. Will do so in the future. You could use TMScope Setup Utility (thank you for finding) to see what your gamepad delivers. See tms0.png for hardware setup, tms1.png for upper-left position, tms2.png for lower-right position.

Regards, Wim.

It worked. Thanks Wim
I didn't know that the "select" button did that axis change. I should suspect about that by looking on the xevents output log.
Now Wolf3D is working fine with the USB Gamepad.

I think my next steps will be to try the Huskee PSX adapter with the Playstation controller.

Regards
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Wim Brul on April 06, 2022, 05:56:45 pm
Hi Lars,

How does this all relate to :
https://github.com/OS2World/DRV-USBLib/tree/master/drivers/src/usbjoy
Markus Montkowski created USBJOY.SYS (USB Joystick Client) and GENGAME.SYS (Gamedevice Manager) back in 2001 and it's source ended up in the above repository. This is yet another way to have gamepad/joystick support in our favorite operating system. It obsoletes GAMEVDD.SYS and replaces GAMEDD.SYS such that GAME$ provides enhanced fuctionality to OS/2 applications while maintaining backward compatibility. This is the good news. The bad news is that in its currend state it does not work at all.

Quote
Is the gamepad a USB device ? If yes, should we not modify those USB joystick drivers to interface with GAMEDD.SYS ? That's at least how it was solved for the USB mouse:
we have USBMOUSE.SYS and that interfaces with AMOUSE.SYS / MOUSE.SYS.
Yes, this is about USB gamepad/joystick devices. But I am not so sure what should be done. Perhaps it is better to start with cloning the currently working USBKBD.SYS into a new USBJOY.SYS rather than trying to fix that not working ancient version. And then the question arises: does it has to interface to my new GAMEDD.SYS or to GENGAME.SYS and go all that way? I think there is a lot of work involved. May be too much...

Regards, Wim.         


Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on April 06, 2022, 06:42:11 pm
Hi Wim!


I tried and reproduced your wolf3d calibration problem. You need to press select button once and then do the calibration. That will work. Apparently you became victim of xevent.cmd builtin joystick axis swap function. In hindsight I think it is better to remove that function altogether. Will do so in the future. You could use TMScope Setup Utility (thank you for finding) to see what your gamepad delivers. See tms0.png for hardware setup, tms1.png for upper-left position, tms2.png for lower-right position.

Regards, Wim.

I'm glad Martin found TMScope - I actually remember the utility back many years past, as it was designed by Thrustmaster, as a calibration utility specifically for the stick I am using.

As you may have already read in my previous posts from Sunday past, I included my testing results on both Comanche 2 and Castle Wolfenstein 3D from a couple of days ago. I have now got TMScope working in both a VDM and in a DOSBOX session.

Interestingly I am seeing the same behaviors I observed in both programs running TMScope.

In the DOS VDM, after using TMScope to test a few of the controls, the joystick seems to lose focus - I can push a couple of buttons, or move the joystick, or activate the hat a few times and then none of the Joystick inputs function. Using reset TMS I was able to get the controls functioning again, once, but then had to use the mouse pointer to exit the program and reenter.

As to DOSBOX, I have got TMScope functioning and if I have a a look at the SET HARDWARE screen it reports a "Top Gun USB" joystick present, so it is seeing the joystick, but again I am unable to get DOSBOX to recognize any of the joystick inputs.

So I don't know if the focus problem in a DOS VDM is somehow related to xevents or not. I was also curious, Wim - are all the versions of xevents.cmd in each of the folders you provided the same, or is the game pad version different from the one provided for my joystick?

But I think using TMScope for first testing of device inputs is a good standardized way of first seeing if inputs are being recognized under a  DOS VDM.

Best Sir as always!

M

Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on April 06, 2022, 06:59:06 pm
Hi Martin!


P.S. BTW I completed a DRAFT of a Game Controller Testing Guide, in PDF, which I have attached below. Its really a first cut at documenting some standardized way to do this testing,  and answering a few questions I have asked, myself, as I've been going through this process - it may be too early to have something like this for use by others, but if you want to have a look and see if you think it would be useful, with any comments, that would be great!
I had read the document and it is very good. It describes in a very good fashion how to do the USB gamepad testing.
I can also publish it on the OS2World wiki if you want to.  As I next step I want to learn more about tweaking the "xevents.cmd" to map the buttons.

Regards

I actually was specifically thinking having a Wiki on this would be a good idea, as well as a place to house test versions of Wim's set of drivers for download.

If you want to upload the current version of my testing guide, by all means - given you have found TMScope v1.12 (which I had forgotten about, as it was developed by Thrustmaster originally for the joystick I have here). Perhaps that can be placed somewhere for download as well.

I think it would be a subject to add to the next version (v1.1) of the testing guide - as it does represent a good standard way to first test any game pad / joystick to see it a DOS VDM accepts the inputs and as a method of calibration prior to running a game.

Best as always, Sir!

M
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Wim Brul on April 06, 2022, 09:54:34 pm
Hi Mark,

Quote
In the DOS VDM, after using TMScope to test a few of the controls, the joystick seems to lose focus - I can push a couple of buttons, or move the joystick, or activate the hat a few times and then none of the Joystick inputs function. Using reset TMS I was able to get the controls functioning again, once, but then had to use the mouse pointer to exit the program and reenter.
I don't understand what you mean by "Using reset TMS". There is no button for that on TMScope display. What did you actually do to get the controls functioning again?

Quote
As to DOSBOX, I have got TMScope functioning and if I have a a look at the SET HARDWARE screen it reports a "Top Gun USB" joystick present, so it is seeing the joystick, but again I am unable to get DOSBOX to recognize any of the joystick inputs.
It is my understanding that the SET HARDWARE screen does not show which joystick is present. It merely shows how it has been setup. I have it currently setup as Std Joystick and 2nd Joystick. Therefore it thinks it has 2 joysticks attached to the game port and displays data accordingly.

Quote
So I don't know if the focus problem in a DOS VDM is somehow related to xevents or not. I was also curious, Wim - are all the versions of xevents.cmd in each of the folders you provided the same, or is the game pad version different from the one provided for my joystick?
Somehow you are not getting a steady stream of joystick events into e.g. TMScope. What you can do: Start xevents.cmd and run TmsScope. When you don't get input data anymore, keep using the joystick for another 30 seconds. Use Ctrl+C to cancel xevents.cmd and note the time that you did that. Append xevents.log for me to inspect. I am curious to see what happened during those 30 seconds. And no, not all versions of xevents.cmd are equal. Yours does not have the swap axis functionality. You were doing that yourself.

Happy motoring, Wim.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on April 06, 2022, 11:42:26 pm
Heh Wim


I don't understand what you mean by "Using reset TMS". There is no button for that on TMScope display. What did you actually do to get the controls functioning again?


Apologies, Wim - the button I pressed to get that is the top button on the left and it is called "Recal TMS"

Quote
It is my understanding that the SET HARDWARE screen does not show which joystick is present. It merely shows how it has been setup. I have it currently setup as Std Joystick and 2nd Joystick. Therefore it thinks it has 2 joysticks attached to the game port and displays data accordingly.

OOOOPS, you are correct Sir - Read the help screens first Mark.

As I said it has been a while since I used TMScope.

However I am curious - did you when you entered SET HARDWARE see the first item checked - just asking as I'm trying to determine whether a joystick in DOSBOX is being seen or not.


Quote
So I don't know if the focus problem in a DOS VDM is somehow related to xevents or not. I was also curious, Wim - are all the versions of xevents.cmd in each of the folders you provided the same, or is the game pad version different from the one provided for my joystick?

Somehow you are not getting a steady stream of joystick events into e.g. TMScope. What you can do: Start xevents.cmd and run TmsScope. When you don't get input data anymore, keep using the joystick for another 30 seconds. Use Ctrl+C to cancel xevents.cmd and note the time that you did that. Append xevents.log for me to inspect. I am curious to see what happened during those 30 seconds. And no, not all versions of xevents.cmd are equal. Yours does not have the swap axis functionality. You were doing that yourself.

Happy motoring, Wim.

xevents attached - representing a single session.

By my reckoning, the session lasted about 1 minute and 34 seconds before the joystick lost focus this time and I continued moving the stick and using both buttons and hat for an additional 30 or so seconds before terminating first TMScope and then Ctrl-C to terminate XEVENTS.

Tried the same experiment 5 times - the time before the joystick lost focus varied from 20 seconds to one minute and 36 seconds.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Wim Brul on April 07, 2022, 05:30:26 pm
Hi Mark,

Quote
However I am curious - did you when you entered SET HARDWARE see the first item checked - just asking as I'm trying to determine whether a joystick in DOSBOX is being seen or not.
No, I did not. When you uncheck all items and then use SAVE CONFIG then that is what you get the next time you strart TMScope. This information cannot be used to determine whether or not a joystick in DOSBOX is being seen.

Quote
xevents attached - representing a single session. By my reckoning, the session lasted about 1 minute and 34 seconds before the joystick lost focus this time and I continued moving the stick and using both buttons and hat for an additional 30 or so seconds before terminating first TMScope and then Ctrl-C to terminate XEVENTS.
Thank you for that. Unfortunately it did not help me to draw any conclusion. I have no clue what is going on. So I have 2 more questions:

1. What does "lost focus" actually mean? I think it means that how hard you try, you do not see any changes on TMScope display occurring. In other words, you first see -RAW DATA- changing, and then after a while you see -RAW DATA- not changing anymore, and that is the so called "lost focus"? Please confirm.

2. When TMScope is in the "lost focus" situation, and you switch away from that session so you can see the xevents command window, do you still see live events occurring in that window when you manipulate your joystick? I am asking because I want to pinpoint where to look next.

Cheers, Wim.

Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on April 09, 2022, 08:51:41 pm
Hi Wim!


1. What does "lost focus" actually mean? I think it means that how hard you try, you do not see any changes on TMScope display occurring. In other words, you first see -RAW DATA- changing, and then after a while you see -RAW DATA- not changing anymore, and that is the so called "lost focus"? Please confirm.

2. When TMScope is in the "lost focus" situation, and you switch away from that session so you can see the xevents command window, do you still see live events occurring in that window when you manipulate your joystick? I am asking because I want to pinpoint where to look next.

Cheers, Wim.

In answer to 1) lose focus means that,. after a period of time no further inputs are noted on the various graphics displays, including the RAW DATA (IOW TMScope's graphics displays does not display RAW DATA,, no lighting of the button graphics or changes to the hat display when buttons or hat are pressed or manipulated, no cursor movement on the window that displays when the joystick is moved, etc.).

However, the mouse (TMScope aircraft cursor) can still move in the TMScope window, click buttons and perform normal functions.

I only mention this because similar behaviour occurred in testing when I ran Comanche 2 and in Wolfenstein as well - in the middle of flight, suddenly the Joystick inputs would not work - however, pressing the analogous buttons on the keyboard (which controlled flight direction, trigger control, etc.) restored joystick control and again the joystick buttons and stick would function correctly. The same occurred (Keyboard / Joystick wise) with Wolfenstein 3D.

In answer to 2)  when focus is lost, switching back to the desktop and checking, XEVENTS, inputs are still being recorded for all 4 buttons, hat and joystick movements.

I have ordered a new solely USB based Thrustmaster Flight joystick as one was available for a good price on Amazon. As that is not a legacy joystick being run through the Logilink Gameport to USB converter I should be able to see whether the same behaviour is present with that stick or whether it is endemic to the legacy joystick only, assuming I can use the same XEVENTS.CMD file for both - please advise if not.

Best of the weekend to you, Sir!

M
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on April 09, 2022, 09:36:28 pm
Hi Again Wim!


1. What does "lost focus" actually mean? I think it means that how hard you try, you do not see any changes on TMScope display occurring. In other words, you first see -RAW DATA- changing, and then after a while you see -RAW DATA- not changing anymore, and that is the so called "lost focus"? Please confirm.

Cheers, Wim.

Interestingly, I had one more item to add today.

I decided to go back, and run Comanche 2 again, as I haven't run it for about a week and a half.

When I started the mission, I was only able to access the trigger (fire) button and joystick movement - however, when the joystick lost focus again I used the keyboard to establish control again ........... and after that I was able to use the hat to look directionally, use all four buttons for various control functions as well as the flight directional control of the joystick movement.

The joystick lost focus again a few times but I was still able to use all joystick control functions again after touching any of the control buttons on the keyboard.

Like all other things in modern computers, the Corsair gaming keyboard is USB based, so I'm not sure if this adds any additional information but thought I would mention it and Best!

Mark



Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Martin Iturbide on April 09, 2022, 11:42:59 pm
I found an issue. I was running Quake 1.01 on DOS VMD. (DOS Quake, not OS/2). It recogniced the gamepad (button 1 and button 2 only, I can not make the axis work yet).
If I unplugged suddenly the USB gamepad, I get this OS/2 trap on USBEHCD.
Workarround: Do not unplugg the gamepad  ;D

Let me know if the trap also happens on other systems, and also whatever data is needed to try to debug this.


Looks like something to open an issue up with, assuming you're using the Arca Noae USB stack

Hi

If someone else can please confirm that if they unplugged the USB gamepad (with xevents.cmd running in the background) in a DOS VDM session while running a Joystick supported game, and it get a USBEHCD trap, I will open the ticket.

Regards
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Wim Brul on April 10, 2022, 08:27:08 pm
Hi Mark,

Quote
I have ordered a new solely USB based Thrustmaster Flight joystick as one was available for a good price on Amazon. As that is not a legacy joystick being run through the Logilink Gameport to USB converter I should be able to see whether the same behaviour is present with that stick or whether it is endemic to the legacy joystick only, assuming I can use the same XEVENTS.CMD file for both - please advise if not.
You cannot use the same XEVENTS.CMD for both. For starters, their idVendor, idProduct and bcdDevice  will be different. And their input report will be different too. I advice you to use LSUSB to find out that information.

Quote
When I started the mission, I was only able to access the trigger (fire) button and joystick movement - however, when the joystick lost focus again I used the keyboard to establish control again ........... and after that I was able to use the hat to look directionally, use all four buttons for various control functions as well as the flight directional control of the joystick movement.
I am puzzled. False positive? Perhaps Mode switch on Link USB 2.0 to Gameport Adapter is not working reliably? Flaky ThrustMaster, cable?

Wim.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on April 10, 2022, 09:11:56 pm
Hi Martin!

I found an issue. I was running Quake 1.01 on DOS VMD. (DOS Quake, not OS/2). It recogniced the gamepad (button 1 and button 2 only, I can not make the axis work yet).
If I unplugged suddenly the USB gamepad, I get this OS/2 trap on USBEHCD.
Workarround: Do not unplugg the gamepad  ;D

Let me know if the trap also happens on other systems, and also whatever data is needed to try to debug this.


Looks like something to open an issue up with, assuming you're using the Arca Noae USB stack

Hi

If someone else can please confirm that if they unplugged the USB gamepad (with xevents.cmd running in the background) in a DOS VDM session while running a Joystick supported game, and it get a USBEHCD trap, I will open the ticket.

Regards

As you know I'm not testing a game pad, but I thought I'd try the same experiemtn with the joystick and my logilink connection.

Starting xevents in the background and running a Comanche 2 mission, then unplugging the USB connection, the DOS VDM continues to run with no Trap, and closing the VDM and examining the XEVENTS window, I get the pictured window attached below:

SYS0031: A device attached to the system is not functioning

get gamepad packet failed
<xevents.cmd> stopped

Plugging in the joystick again and running xevents again, restores the joystick control, either alone or in a DOS VDM.

Granted the following three variables may be different for you:

1) I'm not using a game pad
2) I'm running a different game in a DOS VDM
3) As Wim has written previously, you are using a different XEVENTS.CMD for your gamepad than the one I am using for the joystick

But at least this shows not all game controllers are causing the Trap and Best!

M


Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on April 11, 2022, 07:12:47 pm
Hi Wim!

Hi Mark,

Quote
I have ordered a new solely USB based Thrustmaster Flight joystick as one was available for a good price on Amazon. As that is not a legacy joystick being run through the Logilink Gameport to USB converter I should be able to see whether the same behaviour is present with that stick or whether it is endemic to the legacy joystick only, assuming I can use the same XEVENTS.CMD file for both - please advise if not.
You cannot use the same XEVENTS.CMD for both. For starters, their idVendor, idProduct and bcdDevice  will be different. And their input report will be different too. I advice you to use LSUSB to find out that information.

I was actually taking that into account. Perhaps you misunderstood the question.

Obviously I would have to set up a new USBECD line in config.sys with the idVendor, idProduct and bcdDevice for the new joystick. And I assume, looking at the xevents.cmd, edit references there to also reflect the new joystick parameters above.

So if that is done, and as your REXX CMD file was written specifically for a joystick, I assume that it still could be used for testing a different joystick - correct? Or is there also lines that would need to be modified related to the Logilink mode switches?

Quote
When I started the mission, I was only able to access the trigger (fire) button and joystick movement - however, when the joystick lost focus again I used the keyboard to establish control again ........... and after that I was able to use the hat to look directionally, use all four buttons for various control functions as well as the flight directional control of the joystick movement.

I am puzzled. False positive? Perhaps Mode switch on Link USB 2.0 to Gameport Adapter is not working reliably? Flaky ThrustMaster, cable?


I don't think I'm getting a false positive, Wim as the effect is reproducible, for testing purposes, and I agree it could be possibly related to either the Logilink adapter or cable but the joystick has worked perfectly well in that configuration running gaming programs under Windows 7 in the past.

Perhaps there is another answer.

I 'm wondering if it may be related to USB polling rate?

Both my Corsair keyboards (one a K70 and the other a K95) are modern USB keyboards which are very good for regular applications, but are designed and engineered for gaming purposes first, where response time is important. I haven't looked up the specs yet but I suspect they may poll faster than most keyboards. As the joystick is very old and also being connected in a non standard way, does that sound plausible?

I assume running xevents and noting, right in the window on the desktop, the various responses, that would not be affected by the keyboard polling rate, but, in a DOS VDM, the keyboard may be "hijacking" control from the joystick regularly, hence the effect I'm referring to as "loss of focus".

I'm a hardware geek, but I'm not an engineer so I'm not sure how I could test that hypothesis - I'm also assuming that there is nothing that could be done with your REXX xevents program that could compensate for that (or in the device drivers?).

Its one of the reasons I want to try a modern version of joystick, that is specifically USB in nature - as it is a gaming controller of the now, perhaps it will mesh perfectly, polling rate wise, with the keyboard rate - I like my children sharing and playing nicely in their games ............ even if they are having a war <grin>.

Best of the start of the week, Sir!

M
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Wim Brul on April 19, 2022, 07:29:54 pm
Hi Mark,
Quote
I 'm wondering if it may be related to USB polling rate?

Both my Corsair keyboards (one a K70 and the other a K95) are modern USB keyboards which are very good for regular applications, but are designed and engineered for gaming purposes first, where response time is important. I haven't looked up the specs yet but I suspect they may poll faster than most keyboards. As the joystick is very old and also being connected in a non standard way, does that sound plausible?

I assume running xevents and noting, right in the window on the desktop, the various responses, that would not be affected by the keyboard polling rate, but, in a DOS VDM, the keyboard may be "hijacking" control from the joystick regularly, hence the effect I'm referring to as "loss of focus".

I'm a hardware geek, but I'm not an engineer so I'm not sure how I could test that hypothesis - I'm also assuming that there is nothing that could be done with your REXX xevents program that could compensate for that (or in the device drivers?).
I tried and reproduced the "loss of focus" problem on my desktop computer. It appears that xevents.cmd needs to run at fixed high priority.

So you need to modify your xevents.cmd as follows:

1. Insert the following line just after line 1:

rc=RxFuncAdd('SysGetMessage','RexxUtil','SysSetPriority')
rc=RxFuncAdd('SysSetPriority','RexxUtil','SysSetPriority')

2. Insert the following 2 lines just before the "do forever" line
 
/* set time critical priority */
rc=SysSetPriority(3,31)

Best regards,
Wim.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Lars on April 20, 2022, 10:31:25 am
Hi Wim,
I suspect that you mean;
rc=RxFuncAdd('SysSetPriority','RexxUtil','SysSetPriority')

???
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Wim Brul on April 20, 2022, 11:31:52 am
Hallo Lars,
Hi Wim,
I suspect that you mean;
rc=RxFuncAdd('SysSetPriority','RexxUtil','SysSetPriority')

???
Yes. Just found out the hard way myself this morning. Thanks.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on April 20, 2022, 06:09:03 pm
Good Morning Wim!
(and to Lars as well)

Hi Mark,
Quote
I 'm wondering if it may be related to USB polling rate?

Both my Corsair keyboards (one a K70 and the other a K95) are modern USB keyboards which are very good for regular applications, but are designed and engineered for gaming purposes first, where response time is important. I haven't looked up the specs yet but I suspect they may poll faster than most keyboards. As the joystick is very old and also being connected in a non standard way, does that sound plausible?

I assume running xevents and noting, right in the window on the desktop, the various responses, that would not be affected by the keyboard polling rate, but, in a DOS VDM, the keyboard may be "hijacking" control from the joystick regularly, hence the effect I'm referring to as "loss of focus".

I'm a hardware geek, but I'm not an engineer so I'm not sure how I could test that hypothesis - I'm also assuming that there is nothing that could be done with your REXX xevents program that could compensate for that (or in the device drivers?).
I tried and reproduced the "loss of focus" problem on my desktop computer. It appears that xevents.cmd needs to run at fixed high priority.

So you need to modify your xevents.cmd as follows:

1. Insert the following line just after line 1:

rc=RxFuncAdd('SysGetMessage','RexxUtil','SysSetPriority')
rc=RxFuncAdd('SysSetPriority','RexxUtil','SysSetPriority')

2. Insert the following 2 lines just before the "do forever" line
 
/* set time critical priority */
rc=SysSetPriority(3,31)

Best regards,
Wim.

Just catching up on posts and e-mails this morning, gentlemen - been an interesting Easter week leadup and weekend, between domain transfers, a severe illness in the family (awaiting to see what will happen), two massive snowstorms and finally a birth - first grandchild to an old friend, on Easter Day.

It gives our Easter reflection on the meaning of both death and re-birth a whole new perspective ............. !

I think I will approach this in two ways, for testing purposes based on your very thoughtful comments:

1) I will make the modifications both of you provided to test my current Joystick, and provide feedback as soon as possible.

2) The additional new joystick has not arrived yet, but I will attempt to modify the current xevents.cmd to be able to test that with the current REXX file, as well as testing the new xevents configuration - I'm still curious as to whether a new USB based Joystick of similar configuration would experience the same "loss of focus" issue as previously described. And it might provide us further data.

Will let you know what I find out soon, and if I have any questions.

Best!

Mark



Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on April 21, 2022, 03:26:32 am
Hi Wim!

Hallo Lars,
Hi Wim,
I suspect that you mean;
rc=RxFuncAdd('SysSetPriority','RexxUtil','SysSetPriority')

???
Yes. Just found out the hard way myself this morning. Thanks.

Created xevents2.cmd this morning with the modifications you requested - I noted that both you and Lars had the same statement in your posts, so I assume that you modified the original post to reflect Lars's suggestion.

In summary based on about an hours testing:

1) The change I noted the most on Comanche 2, running xevents2, was that the program immediately recognized ALL controls on the Joystick, including all four buttons, the hat controls and joystick movements, right from the start - loss of focus was still noted but much less than previous, so polling may be a factor - I ran 5 training missions, and was able to complete them rather easily, but probably needed to use the keyboard about once every 1-2 minutes to get the Joystick to respond - not a lock but whatever the last command was that was issued by the joystick (a yawl one side or the other, down throttle, button activation or other) required me to engage the keyboard to get joystick control working again.

2) Playing Wolfenstein I can only get two buttons to work, but this is the same as previously (Have configured B0 = Fire and B1 = Open, although it says it at least supports additional B2) and movement using the joystick works most of the time - have had to use the keyboard to re-focus the joystick about once every 3-4 minutes, to re-engage the joystick. Not really much of a problem, as, realistically, Wolfenstein is probably played best with just the keyboard.

3) Still need to see how long TMScope will remained focused with xevents2 - a job for another day.

I've attached the edited xevents2.cmd below, if you want to see if the edits were done correctly and Best!

M
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on April 21, 2022, 07:33:21 pm
Hi Wim!

Hi Mark,
Quote
I 'm wondering if it may be related to USB polling rate?

Both my Corsair keyboards (one a K70 and the other a K95) are modern USB keyboards which are very good for regular applications, but are designed and engineered for gaming purposes first, where response time is important. I haven't looked up the specs yet but I suspect they may poll faster than most keyboards. As the joystick is very old and also being connected in a non standard way, does that sound plausible?

I assume running xevents and noting, right in the window on the desktop, the various responses, that would not be affected by the keyboard polling rate, but, in a DOS VDM, the keyboard may be "hijacking" control from the joystick regularly, hence the effect I'm referring to as "loss of focus".

I'm a hardware geek, but I'm not an engineer so I'm not sure how I could test that hypothesis - I'm also assuming that there is nothing that could be done with your REXX xevents program that could compensate for that (or in the device drivers?).
I tried and reproduced the "loss of focus" problem on my desktop computer. It appears that xevents.cmd needs to run at fixed high priority.


Had a few minutes this morning, so spent about 20 minutes playing with TMScope and the joystick - I tried both xevents2 and the original xevents to see if any differences were notable.

With xevents2, playing with the various joystick controls with the display up, I did not lose focus for about 5 minutes, then the inputs didn't work - hitting any key on my K70 keyboard resulted in the joystick again sending inputs to the TMScope display. Twice, using the mouse to operate the display buttons on the right hand side resulted in the joystick providing no input to TMScope, which was again fixed by pressing any button on the keyboard.

Switching back to xevents and running the same tests, the loss of focus seemed to occur faster and be more frequent - I was able again to recover hitting any key on the K70 - this may be just subjective, but it seemed with the original xevents, recovery, so that the joystick was again supplying input, seemed a little most sluggish, but that just may be my impression.

So, xevents2, with your modifications, seem to work much better with all the tests I've run, on 3 DOS programs - the "loss of focus" still occurs, but much less frequently.

I don't know how TMScope is measuring the "Port Speed" in the upper left hand corner of the TMScope display, but when I do that measurement (by pressing the button present on the right hand side, with the mouse), the port speed is reported as two notches up on the scale, instead of the 5 reported when the program starts (the default position), so it may indicate that the Logilink switch port input rate is quite low - but again that is just a subjective assessment, as the reported post speed is not being reported as a hard number, calculated scientifically - Until I get the USB based joystick I have nothing for comparison purposes.

I also did do some research on Corsair keyboard polling rates, and it was quite interesting.

They keep producing constantly updated versions of the same model keyboard, so you have to examine carefully, which ones they are referring to. Professional gaming seems to have exploded as a sporting competition, and looking at the current 2021 era Corsairs K-70 RGB Pro and K-70 RGB TKL (a smaller tournament grade keyboard where TKL stands for "ten keys less"), polling rates are running with advanced AXON technology at up to 8000 Hz (0.125 ms access time), in many cases programmable.

Those seem to be the big brothers to my K-70 RGB (which was purchased in 2020), which is polling, according to specs at 1000 Hz (1 ms access time) default, as opposed to normal keyboards in the 125 Hz range. My Corsair K-95 purchased in 2021 is similar. Both keyboards are completely similar in layout, with the addition of 6 programmable macro keys on the left on the K-95, and a less mechanical feel to the K-95 keys.

Its my understanding that PS/2 based keyboards and equipment were interrupt based not polling based, so I expect the joysticks of that era were similar - don't know how the Logilink game port to USB adapter translates that, but I expect response and access, like most workaround technology, would be slower. I'm sure you. Lars and others here would know far more about the subject than I do.

That completes my testing report for now- please advise if you would like me to test anything further Wim, based on the  current equipment I have - I have not included any xevents.log files as I don't think they will tell you anything not referred to above - examining them after a DOS session indicates that the joystick is functioning correctly mechanically, and sending xevents reports at all times, with the current drivers - it is just the loss of focus problem that seems to be occurring here - my results may not be typical, because of the equipment I am using for testing - more testers may be needed to get a good idea of how your drivers are functioning generally.

Best as always!

Mark
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on April 26, 2022, 04:30:13 pm
Hi Wim!

Got the new USB Joystick yesterday - it is a Thrustmaster T.Flight Stick X, and seems to be a hybrid between a  HOTAS Joystick, and a Game Pad,  with the typical 4 buttons, Hat, Trigger mechanism and movement with the Joystick and 6 additional buttons on the base, as well as a slider control. It is programmable in addition to having pre-set settings. It is designed for use with both a PC and a PS/3 system (using a slider switch at the front). I'm still assessing the intricacies of this Joystick, and may need to do so under Windows for more detailed tests of the equipment.

As a preliminary to undertaking these ArcaOS tests, I added an additional line for USBECD in Config.sys, rebooted, then plugged the USB connector in and ran USBRead to obtain the following Vendor ID's:

044F:B106:0100

So the complete line I then added to Config.sys was:

DEVICE=D:\OS2\BOOT\USBECD.SYS /D:044F:B106:0100 /N:$FLIGHT$ /V

Rebooting, I then created two new xevents files:

xeventsF1 - based on the newest xevents (xevents2) I sent you a few days ago, containing the modifications to run at fixed high priority.

xeventsF2 - based on the original xevents, with the slight modifications we made previously.

I've attached copies of both to this post.

The changes I made in both were:

Line 9   - Changed to ddNameI='$FLIGHT$'
Line 13 - Changed to info='DEVICE=?:\OS2\BOOT\USBECD.SYS /D:044F:B106:0100 /N:'ddNameI

Based on the results of the current tests with the new Joystick, you may see other changes that need to be made - scanning through the rest of the .CMD files, I thought that may be sufficient but perhaps not.

I ran the first test just starting xeventsF1 and pressing the various buttons and hat and adjusting the Joystick aspect. What came back as output in the window was the following:

Packet=00F0FF808080FF00,Huh?
Packet=00F0FF808080FF00,Huh?
Packet=00F0FF808080FF00,Huh?
Packet=00F0FF808080FF00,Huh?
etc.

actual xevents.log attached.

As the normal data output packets returned by the previous Joystick are more like:

Ax=4A00, Ay=5600, Bx=FF00, By=6F00, Buts=F000
Ax=4A00, Ay=5600, Bx=FF00, By=6F00, Buts=E000
Ax=4A00, Ay=5600, Bx=FF00, By=6F00, Buts=F000

I can only assume that xevents could see output, but is not interpreting the output correctly for some reason.

The current log sent contains output from the new joystick, mostly - the normal data output packets in there occurred when I ran the older joystick through a couple of tests to verify the differences - both are plugged into my test system at tthe moment, but, as the two sets of xevents.cmd files contain different equipment specific ID's, I assumed they would not interfere with one another if only a specific xevents joystick profile is run.

Trying TMScope, I was unable to get the displays to recognize any inputs from the new Joystick, which is connected as per usual now, with a standard USB connector.

Two other things were also noted:

1) all the buttons on the new Joystick generated a packet output in xeventsF1 (including the extra six on the base and slider), and

2) even with the joystick at rest, and no buttons being pressed, a new packet was being generated in xeventsF1 every four seconds of so (something that was not seen ever with the older Joystick). I'm not sure if that can be interpreted as the USB Joystick polling or not.

I also could not get either of the test DOS games to recognize the new Joystick at the moment, probably based on the output noted previously.

I did not note much difference from above running xeventsF2 (the modified older xevents with no prioity modifications), so I'm not sure if fixed high priority is an issue or necessary with a modern joystick or not.

Will send pictures of the new joystick at some point so you can see the layout - busy with a few other matters at the moment, but will reply to any comments or queries you may have as soon as possible.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on April 26, 2022, 05:12:59 pm
Pictures of the new Joystick attached.

Mark
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Wim Brul on April 26, 2022, 09:53:21 pm
Hi Mark,

Quote
Got the new USB Joystick yesterday - it is a Thrustmaster T.Flight Stick X, and seems to be a hybrid between a  HOTAS Joystick, and a Game Pad,  with the typical 4 buttons, Hat, Trigger mechanism and movement with the Joystick and 6 additional buttons on the base, as well as a slider control. It is programmable in addition to having pre-set settings. It is designed for use with both a PC and a PS/3 system (using a slider switch at the front). I'm still assessing the intricacies of this Joystick, and may need to do so under Windows for more detailed tests of the equipment.
Nice. Let us see if we can get this to work. You did already successfully do the first necessary steps. You wrote earlier:

Quote
I've attached the edited xevents2.cmd below, if you want to see if the edits were done correctly and Best!
Unfortunately line 2 was replaced whereas line 2 had to be inserted. Applies to xeventsF1.cmd too. See below.

Quote
Based on the results of the current tests with the new Joystick, you may see other changes that need to be made - scanning through the rest of the .CMD files, I thought that may be sufficient but perhaps not.
Looked into xevents.log and prepared xeventsF1a.cmd and xeventsF2a.cmd to be used for now.

I also prepared oinputF1a.cmd for you to use to find out what input record is produced for what user action. So you will have to push each button in succession and report back the results like you did before. Same for moving the joystick and slider and so on. You know the drill.

Moreover I need you to attach the lsusb report. Use "lsusb -d:044f:b106 -v > 044fb106.txt" to get that.

Best regards, Wim.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on April 27, 2022, 03:49:50 am
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
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on April 27, 2022, 03:59:20 am
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
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Wim Brul on April 27, 2022, 10:18:55 am
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.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on April 27, 2022, 04:34:10 pm
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
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on April 27, 2022, 11:27:03 pm
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
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Wim Brul on April 29, 2022, 11:56:48 am
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.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on April 29, 2022, 06:31:14 pm
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

Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on April 29, 2022, 07:59:27 pm
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

Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Wim Brul on May 05, 2022, 08:01:31 pm
Hi Mark,

Quote
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.

Quote
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.

Quote
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.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on May 06, 2022, 06:59:40 pm

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?

Quote

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

Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Jochen Schäfer on May 07, 2022, 11:08:13 am
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
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on May 07, 2022, 04:23:38 pm
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
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Wim Brul on May 07, 2022, 06:24:45 pm
Hi Mark,

Quote
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.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on May 07, 2022, 11:58:24 pm
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
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on May 08, 2022, 12:38:44 am
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
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Wim Brul on May 10, 2022, 12:44:24 am
Hi Mark, you wrote earlier:
Quote
I'm also curious as to whether you ever attempted to run Wolfenstein 3D under DOSBOX?
No Mark, I did not until today, when I felt the time was right to install DOSBox, and see for myself what's (not) going on...

And Jochen Schäfer wrote:
Quote
SDL 1, which is used by DOSBOX, has native joystick support, so in theory Wim's USB drivers should be available in SDL 1.   
Jochen is right. It ought to work. So I did some tracing and looked into SDL_os2joystick.c to discover the culprit:

GAMEDD.SYS is missing GAME_PORT_RESET and GAME_PORT_GET functions. Without these no joysticks are detected.
The good news is that once I added those functions it all started to work (at least on my laptop that is). Will append later.

Regards, Wim.

Edit: And here it is. Only GAMEDD.SYM/GAMEDD.SYS and TRC00E8.TFF have been changed.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on May 10, 2022, 04:09:07 am
Hi Wim!


SDL 1, which is used by DOSBOX, has native joystick support, so in theory Wim's USB drivers should be available in SDL 1.   



Jochen is right. It ought to work. So I did some tracing and looked into SDL_os2joystick.c to discover the culprit:

GAMEDD.SYS is missing GAME_PORT_RESET and GAME_PORT_GET functions. Without these no joysticks are detected.

The good news is that once I added those functions it all started to work (at least on my laptop that is). Will append later.

Regards, Wim.

That is actually quite exciting, as I've tried a number of DOSBOX programs (5) including Wolfenstein and also TMScope and could get no feedback despite enabling DOSBOX Joystick support.

I have roughly 60 DOS programs installed under DOSBOX, of which 15 or so have joystick / gamepad support, so it would give a much larger range of programs to test.

Jochen has done a lot of good work related to ArcaOS, as the problem installing DOS programs normally under OS2 / eCS / ArcaOS at the moment is getting everything DOS based to work, with a myriad of native DOS VM settings, as well as the SET BLASTER parameter, if you want to try enabling sound - if we can get controller support working under DOSBOX, it is much easier for widespread testing.

As I've said previously, my direct VM DOS Wolfenstein installation is buggy but does work eventually, but the analogous DOSBOX installation works flawlessly immediately (including sound) - its just the game controller functions not working at the moment.

Let me know, Wim, if there is something you'd like me to test and Best!

M
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on May 10, 2022, 06:34:20 pm
Hi Wim!

Quote

Jochen is right. It ought to work. So I did some tracing and looked into SDL_os2joystick.c to discover the culprit:

GAMEDD.SYS is missing GAME_PORT_RESET and GAME_PORT_GET functions. Without these no joysticks are detected.

The good news is that once I added those functions it all started to work (at least on my laptop that is). Will append later.

Regards, Wim.

Edit: And here it is. Only GAMEDD.SYM/GAMEDD.SYS and TRC00E8.TFF have been changed.

And ............ WE HAVE A WINNER !!!!!!

Installing the GAMEDD.SYS and GAMEDD.SYM as well as TRC00E8.TTF from you latest gamepad package (gamepad-20220510.zip) I now have game controller function in DOSBOX (at least joystick wise - Martin or others will have to confirm gamepad function)

I have tested both the original Thrustmaster Joystick on the Logilink box, Mode 2, and the new Thrustmaster T.Flight, using the original xevents.cmd (for the former) and xeventsf1c.cmd (for the latter), and both are recognized by the DOSBOX installed TMScope - not perfectly, but at least functional, so good on you, Wim - excellent work!

When I say not perfect, I found the following:

1) Again hat function is not present, running TMScope under DOSBOX, for either joystick, so I assume something is still missing there

2) I noted on the X-1 and Y-1 axis control display, pushing either joystick to the east and south, the travel indicted on TMScope is a lot less (about half) the travel noted on the display pushing the joysticks north and west (the cursor went to the maximum travel on those sides of the the display). I will explain why that may be important below

3) Perhaps I have not tested enough so far, but under DOSBOX after 5-10 minutes I did not see the Loss of Focus problem I reported earlier, so the environment under which you are playing a DOS game (ie. direct DOS VM under ArcaOS / eCS / OS2 or under DOSBOX) may be important to that issue.

Running Wolfenstein 3D, using either joystick, I was able first to calibrate the joystick (very easily in fact) and, enabling the Gravis GamePad button, as you discovered, was able to customize buttons B0-B3).

The one item I noted there from preliminary testing was the following:

4) Attempting to turn either east, or backing up south using the joystick did not work - I could move forward (north on the joysticks) and towards the west easily. So the X1 - Y1 axis problem I noted in 2) above may have some bearing on that.

Trying Comanche 2:

I was able to calibrate both Joysticks, but when I went to run the game, sight directional control, normally provided by the hat, caused the display to sight towards the left (west) to start. Moving the joystick variously either moved me in different flight directions, or changed sight directions (north, south, etc.) randomly, so there may be some confusion occurring between joystick input, perhaps between the hat inputs and the X1-Y1 axis inputs in some way (xevents does report outputs going out from both joysticks).

Its good that I can test various programs, as that issue would not be seen under Wolfenstein, due to its simple control arrangement (essentially just 4 buttons and the X-1 / Y-1 control movemennts).

With the ability to use DOSBOX as well, I plan to do testing on a wider variety of games in future, as well as exploring the mapping of the extra buttons on the newer Thrustmaster joystick. I also plan to do more testing to confirm whether the Loss of Focus problem is strictly a native DOS VM problem or whether it can be reproduced under DOSBOX. Please advise if there are any other tests you would like carried out, Wim - perhaps xevents logs may be able to define whats going on although I would have to carefully log the timing of the games while I proceed.

But in summary, Sir (and for others others looking in) I can confirm DOSBOX control of game controllers, at least with the joysticks tested, is now possible as well as under a DOS VM, so hats off to you again Wim - excellent work - only wish I could at least buy you a glass or pint of your favourite libation for your efforts and Best!

M


Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on May 11, 2022, 07:53:09 pm
Hi Wim!

Quote

GAMEDD.SYS is missing GAME_PORT_RESET and GAME_PORT_GET functions. Without these no joysticks are detected.
The good news is that once I added those functions it all started to work (at least on my laptop that is). Will append later.

Regards, Wim.


Had a chance to do some more testing today under DOSBOX.

I now am testing 4 separate programs, including 3 games - Wolfenstein, Star Wars: Dark Forces and Comanche 2.

I will make one correction to what I reported yesterday related to item 4)

Quote

4) Attempting to turn either east, or backing up south using the joystick did not work - I could move forward (north on the joysticks) and towards the west easily. So the X1 - Y1 axis problem I noted in 2) above may have some bearing on that.


Having more games to test also allows me to test what has happen previously under different conditions and circumstances.

I was able to move both east and south under Dark Forces, after calibration there, so I went back to Wolfenstein and recalibrated, and both east and south movement is now possible with both joysticks, in both Wolfenstein and Dark Forces, so what I said previously may be a moot point.

The T.Flight joystick is noticeably faster than the older one, sometimes making certain movements a little fast, but I know the T.Flight has a manual adjustment dial under the bottom, which can increase tension, so I will try that first, and see if movement can be slowed down that way. The Mk.2 Thrustmaster (my original one) is operating just perfectly in Dark Forces, at a reasonable speed, so I don't think at least under DOSBOX much adjustment of input speed is really needed.

In my first tests with Dark Forces, it maps only 2 buttons in addition to joystick movement, and, unlike some of the other games, does not allow a choice of joystick type. I also noted that I did not adjust the "auto" switch to "fcs" in the DOSBOX conf file to start, and the DOSBOX start-up screen seems to indicate that it automatically thinks 2 joysticks are present, so I will attempt to adjust that and see what happens.

I also played Dark Forces for over 45 minutes without any indication of Loss of Focus and played around with TMScope for over 30 minutes with no freezing requiring input from the keyboard to unlock the joystick, so indeed it might be different between environments. The joystick(s) are both playing nicely with both the keyboard and mouse under DOSBOX.

I'm not going to go infinite related to adding more games to play, but I'm currently planning to add two more games to the mix:

Mechwarrior 2 - the Mechwarrior series has a very complex set of controls, and does have customizable settings for Joysticks and recognizes and supports the Thrustmaster Mk. 2 specifically, so I may be able to map at least 4 buttons and the hat to useful gameplay functions.

Wing Commander - a Wolfenstein era game of space flight and battle to allow me to compare joystick flight control between games. I am still looking to see whether I have a game that is flight control customizable for air or spacecraft use.

This has been a very interesting experience, Wim, in beta testing, and you make an excellent teammate in same. I think we're making great progress in this and Best!

M



Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Wim Brul on May 11, 2022, 11:51:47 pm
Hi Mark,

Quote
I was able to move both east and south under Dark Forces, after calibration there, so I went back to Wolfenstein and recalibrated, and both east and south movement is now possible with both joysticks, in both Wolfenstein and Dark Forces, so what I said previously may be a moot point.
Probably not. My experience was that, although Wolfenstein 3D worked after calibration, I still had to recalibrate always first. That was not necessary when running outside DOSBox. So I tweaked gamedd.sys a little bit to remedy that. See attached. Now I don't need to recalibrate anymore and joycheck.exe and TMScope are working satisfactorily too. In dosbox.conf I need to have joysticktype=auto, timed=true and deadzone=0 for that.

Quote
I also played Dark Forces for over 45 minutes without any indication of Loss of Focus and played around with TMScope for over 30 minutes with no freezing requiring input from the keyboard to unlock the joystick, so indeed it might be different between environments. The joystick(s) are both playing nicely with both the keyboard and mouse under DOSBOX.
Makes sense. I have to use Martin Kiewitz's vCOMPAT.SYS with COMPATIBILITY_DPMI_CLI set ON in order to get several games to run.

Quote
This has been a very interesting experience, Wim, in beta testing, and you make an excellent teammate in same. I think we're making great progress in this and Best!
Yes we do. Thank you for that. It is a pleasure working with you.

Regards, Wim.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on May 12, 2022, 02:45:10 am
Hi Wim!

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.

I installed all the files from this gamepad set and rebooted before testing - also got a black screen trap starting up Wolfenstein once each but will have to run it again as I didn't note the message before rebooting. This happens both with xevents.cmd and the Mk. 2 Thrustmaster, and with the T.Flight and xeventsf1c.

TMScope works fine and the joystick travel is vastly improved and balanced to the east and south. Haven't done any other testing at the moment - my evening exercise time awaits .........

Best!

M

Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on May 12, 2022, 05:35:27 am
Hi Wim!

Final message for today here.

After my exercise ride this evening, undertook a complete mission in Star Wars Dark Forces - the developers decided that there would be no save files in between so was busy for about 1.5 hours, completing the mission.

I changed the joystick type to fcs, prior to starting - all it added for either joystick is one button which added a "crouch" function to its mapping, so three buttons enabled as opposed to two.

I used the older Thrustmaster for the mission and it worked perfectly - no Loss of Focus, buttons that did work, worked fine, joystick control was as expected. I had calibrated using the newer stick and experienced no need to recalibrate.

So currently, from my end the two issues using the latest gamepad package are:

1) The rather strange issue related to Wolfenstein trying to exit once the program, has started as per my previous message, and

2) Hat functions on the Thrustmaster joysticks still not being recognized under DOSBOX

Otherwise things seem to be ticking along - you didn't mention why you needed vcompat.sys, otherwise I would test that too (I know I have used it in the past - but can't remember why, under eCS / OS2)

Hope your day is going well - the end of mine this evening and Best!



Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on May 13, 2022, 04:57:39 pm
Hi Wim!

I noted one other thing with the new driver package (gamepad-20220511) this morning

Running TMScope under a DOS VM, Hat functions for the T.Flight would only point north or east when changing the hat position when I first brought it up (south or west hat positions would report as east). Hitting the Recal TMS button, I could then get north east or south, but west output would not be shown on the display. This was with xeventsf1c.

Running the last xevents and the older Mk2 Thrustmaster, hat positions were all registering correctly with the new drivers package, so there may be something different between the two packages related to the hat registration.

Its such fine weather here at the moment that I may be out for most of the weekend as there is yard work to be done after our winter, but will try to see if I can setup Mechwarrior 2 using your drivers under DOSBOX, and try running a training mission or 2.

Best of the weekend to you Sir!

M
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Wim Brul on May 17, 2022, 04:02:40 pm
Hi Mark,

Congratulations with your upcoming birthday. I celebrated mine last Saturday with my family. Clicking my picture reveals my new age.

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.

Happy birthday,

Wim.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Martin Iturbide on May 17, 2022, 07:02:30 pm
Quote
gamepad-20220517.zip

Hi Wim.

I confirm the drivers keep working in my system.
- ArcaOS 5.0.6 with PCSIGP
- Wolfenstein - VDM
- Wolfenstein - DOSBox 2021/01/24
- Makman - OS/2

Regards
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on May 17, 2022, 08:10:53 pm
Hi Mark,

Congratulations with your upcoming birthday. I celebrated mine last Saturday with my family. Clicking my picture reveals my new age.

Happy birthday,

Wim.


Thank-you Sir and many wishes back - it is actually tomorrow (May 18 - which when you read this will most likely be today). My morning today was spent taking our 2 cats for their annual veterinary trip, which as always involved a fair bit of cat-cophany

I always thought EVERYONE got a holiday on their birthday - my birthday has coincided many times with the old queens (Victoria's) birthday celebration which we celebrate as a May long weekend, every year in Canada.

Age is an attitude, Sir - as I mentioned to Paul and Dave in another thread, while we can't do much about health except accept and treat it, as necessary, I find few of the amazingly bright and gifted individuals here who act as if they are a certain age or resigned to be so. You are one of the prime examples of someone who seems unconcerned about the number involved, as long as you can do interesting things like play tennis, keep your programming mind sharp doing interesting projects, and most of all .......... live.

I live with another one of those - my wife Anne is actually twelve years older than me and slightly younger than you - she plays harp, knits, embroiders, gardens and overall enjoys the positives of life - she looks in her 50's and has a similar attitude, despite health issues - I actually look older than her, but keep fit (something that was important at the height of my emergency response days) and have fingers in many pies (it used to be in dams in a crisis - I find pies MUCH more tasty).

Most of all I always try to stay both interested, and interesting - life would be tremendously dull if there weren't a few buttons to press <sic>.

With that in mind - off to see what is in your latest gamepad package and Best!

Mark
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on May 17, 2022, 08:17:13 pm
Heh Martin!

How are things going related to your Dad?

And how is your family doing?

Also where can I find Makman OS/2?

Best!

M
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Sigurd Fastenrath on May 17, 2022, 09:55:02 pm
Hi Mark,

Congratulations with your upcoming birthday. I celebrated mine last Saturday with my family. Clicking my picture reveals my new age.

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.

Happy birthday,

Wim.



Happy birthday to All of you as well! Wim I celebrated my 56 birthday last saturday as well... :D  That is really funny! :)
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Martin Iturbide on May 17, 2022, 11:52:37 pm
How are things going related to your Dad?
Also where can I find Makman OS/2?
Hi

I'm going fine, still some paperwork I need finish.

Makman is very basic and you only use the pad to move the Pacman, and I'm not sure if it is the best sample to use a Joypad with OS/2, it is the one that I found first. But you can get it here (https://www.os2world.com/games/index.php/native-games/action-2/66-makman-2).

Regards
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on May 18, 2022, 03:43:00 am
Hi Martin

How are things going related to your Dad?
Also where can I find Makman OS/2?
Hi

I'm going fine, still some paperwork I need finish.

Makman is very basic and you only use the pad to move the Pacman, and I'm not sure if it is the best sample to use a Joypad with OS/2, it is the one that I found first. But you can get it here (https://www.os2world.com/games/index.php/native-games/action-2/66-makman-2).

Regards

Unfortunately I can't find anything to test thats native OS/2 so thought that would come closest at the moment, Sir - the new joystick has buttons 5-8 at the base, which may provide a similar control experience if not directional control.

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

M
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki 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
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Martin Iturbide 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 (https://hobbes.nmsu.edu/download/pub/dos/util/misc/JoystickTestUtils_1998-04-01.zip)" but instead of DOS, for OS/2 native?

Regards
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki 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 (https://hobbes.nmsu.edu/download/pub/dos/util/misc/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
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki 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
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki 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





Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Dave Yeo 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.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki 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
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Wim Brul 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.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Jochen Schäfer 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
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki 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

Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Wim Brul 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.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki 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
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Dave Yeo 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.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki 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
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Lars 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.

Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Jochen Schäfer on May 21, 2022, 11:00:18 am
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.
Hi Wim.

I don't know when I can get to it, but I will look into it.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on May 21, 2022, 07:49:00 pm
Heh Lars!

Hope your having a fine weekend - the long Victoria Day weekend here.


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.


Thanks for the detailed explanation.

As mentioned I'm not a programmer myself, but I appreciate when someone will explain not just that there is a problem, but what it may be as well as its implications. It also assists greatly in testing at the moment, to analyze  exactly what I did that made it trigger.

In this case I'm simply acting as a tester and reporting anything I may see, that may be of significance or interest, hopefully in a way useful to you, Wim, Jochen or anyone else participating or observing.

However, in my emergency / environmental consulting practice, as well as my senior roles in both government and corporate in my career, I've been a senior project manager leading teams of hundreds - I always appreciated being informed by my staff as to potential roadblocks, pitfalls or problems, and what may need to be done, in a way I can comprehend, as being forewarned allows planning to proceed smoothly. Analysis is key to success, as well as being methodical IMHO.

I've learned a lot in this what I consider a "project" - it is fascinating to look "under the hood" so to speak as to what actually makes up a device driver and how it operates.

Best!

M
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Wim Brul on May 22, 2022, 01:14:30 pm
Hi Jochen,

I don't know when I can get to it, but I will look into it.
Thank you. For starters I tried and modified SDL_os2joystick.c myself. I could send the modified source code to you or append it here. Please advice.

I replaced lines 440 thru 442 with the following:
Code: [Select]
                        joystick->hwdata->transaxes[i].offset = SYS_JoyData[index].axes_med[i];
                        joystick->hwdata->transaxes[i].scale1 = (float)(SDL_JOYSTICK_AXIS_MIN/(SYS_JoyData[index].axes_med[i]-SYS_JoyData[index].axes_min[i]));
                        joystick->hwdata->transaxes[i].scale2 = (float)(SDL_JOYSTICK_AXIS_MAX/(SYS_JoyData[index].axes_max[i]-SYS_JoyData[index].axes_med[i]));

I replaced lines 550 thru 560 with the following:
Code: [Select]
                value = pos[i];
                if (value < transaxes[i].offset)
                {
                        value = (transaxes[i].offset - value) * transaxes[i].scale1;
                        if (value < SDL_JOYSTICK_AXIS_MIN) value = SDL_JOYSTICK_AXIS_MIN;
                }
                else
                {
                        value = (value - transaxes[i].offset) * transaxes[i].scale2;
                        if (value > SDL_JOYSTICK_AXIS_MAX) value = SDL_JOYSTICK_AXIS_MAX;
                }
 
What I am after is that you build an SDL1 test version of DOSBox for us to try out.
I regard this still very experimental, so not yet suitable for an official release.

EDIT1: 20220523 - Updated lines 440 thru 442 with the new code!
EDIT2: 20220523 - Updated line 551 too (with proper code I hope!
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Jochen Schäfer on May 22, 2022, 09:28:27 pm
Thanks Wim.

I will try that code snippets and build a test version.


Bye Jochen
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Wim Brul on May 23, 2022, 09:17:42 am
Hi Jochen,
Thanks Wim.

I will try that code snippets and build a test version.


Bye Jochen
Thank you. NOTE1: I have updated lines 440 thru 442 with the new code rather than the old code. NOTE2: Modified line 551 later on too (with proper code I hope)!

Sorry, but this is nowadays really difficult for me to do.

Regards, Wim.