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.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on May 27, 2022, 04:37:49 pm
Good Morning Guys!

Finally had time for other matters yesterday, so I took another crack at trying to see if I could get joysticks to work on Trials of Battle (TOB).

For the members of the crowd who haven't been around this operating system only forever, after Galactic Civilizations it was one of the few actual games produced solely and specifically for OS/2 by a retail company, for commercial sale. (Galactic Civilizations was ported to Windows later - originally it was designed solely for OS/2)

I had bought a retail copy from Stardock back when it came out in 1995, and still had it in the original box up to a few years ago, when I was trying to clean up my office of all the software and boxes that accumulated over 30 or so years. I stored away the CD but don't recall if it ever came with a manual (if so, it is now missing, so I had no reference points to go by other than sketchy information on the internet, the Read.Me, a review and fuzzy recollections from originally playing the game.

Anyway, I was finally able to determine that all the functions of the game were accessed from the hanger screen, an annotated version of which I've attached to this post. If you move the mouse cursor about, the cursor changes from red to green when there is a hidden menu flyout present.

These are four in number:
(see the picture for the location of the numbers below):

1 - Storage Equipment Inventory
2 - Options Menu
3 - Arena Entrance
4 - System Damage Report and Repair screen

Clicking on the location I've marked (2) brings up the options screen. The second button down on the right side of the menu, when pressed, brings up a flyout where you can choose whether you want to use a joystick or mouse as part of the controls of the game. This is where you can also calibrate the joystick.

While I still have a hard lock-up after a certain length of time, I can report that, running Wim's driver set and the appropriate xevents.cmd for the joystick in question, I now have joystick control in TOB.

The controls allowed are very simple in nature, consisting of Buttons 1 and 2 and movement using the joystick. The menu choices are hard coded, so you can't customize anything. But at least we've found another native OS/2 game that confirms that Wim's efforts are paying off. Big kudos again to you. Sir!

As mentioned I am still getting the hard lock-ups after various periods of time. I will explain what I've tried so far to alleviate that, in another post.

Also, I don't know if any of you have ever gone to Internet Archive (www.archive.org).

I've found a lot of interesting legacy items which have been placed there for posterity. They do have an ISO of the original game disk there, in their CD collection. The disk is required to both install the game and it needs to be present in the system while the game is running.

I don't know, Martin, if you ever have checked with Stardock as to whether the game is considered abandonware now, or not. I have downloaded the ISO from there, burned it and it runs fine - I have returned my original retail copy of TOB to sleep in its storage case.

Have a great weekend, Ladies and Gentlemen and Best!

M
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on May 28, 2022, 03:49:44 am
Heh Again Guys!

As mentioned in my previous post on getting Trials of Battle (TOB) to recognize the Joysticks using Wim's drivers, I also thought I'd address what I've tried and found so far related to using the program itself.

As mentioned previously, under ArcaOS 5.0.7 using the latest Panorama driver, I was getting hard screen lock-ups after a few seconds entering a new battle within the arena. The lock-up is so hard that no input (keyboard, joystick or mouse, no Ctrl-Alt-Del) is accepted, although the mouse still moves on the frozen screen. You essentially have to hit the hardware reset button to reboot and recover.

During my additional exploration of how to run Trials of Battle, I found that hitting either F3 or F4 set TOB to run a windowed session, at least in the hanger screen - in the first case (F3) the window is smaller than when you hit F4 (only part of the hanger screen is seen in the first case, while a miniature version of the hanger screen is observed in the second case - both windows can be dragged and enlarged).

Again after running the game using Panorama in a windowed session, a hard lock of the screen is observed after a few seconds of movement and battle in the arena - this happens with or without enabling Wim's drivers.

As a second test, I removed the Panorama driver in one of my test partitions, and substituted the Scitech SNAP based ArcaOS driver instead and again ran TOB. Video refresh, desktop wise, seemed slower overall, but running TOB full screen or windowed seemed better - in one case, I was able to maneuver for somewhere between 30-60 seconds (did not time it). That was what I used to test Wim's drivers and get the joystick(s) recognized (there is no way in TOB to run both joysticks used by separate players at the same time - the tests were strictly one joystick or the other).

Using the options screen (see the previous post) the game gives you multiple options as to video - low resolution as to high resolution, the ability to remove multiple texture maps, etc. - using SNAP and going to the lowest resolution, unchecking all the texture maps, I was able to run the game, with Wims drivers for about 45 seconds - after that the lock-up occurred again.

Again observations like that need additional people to observe the same thing, but I suspect the following:

1) Problems related to programming purely in DIVE, and the program never being updated from v1.0

2) Potential problems, single processor vs multi-processor systems, as the development of the OS/2 based OS's have progressed in other directions.

If anyone has any bright ideas related to that or other possibilities I'm open to testing them - the problem is that there are so few complex native OS/2 based games that were created. As such, there is little to use for comparison purposes.

I would be interested in any feedback others may have related to how TOB runs on their systems - nothing I've seen indicates that Wims drivers for Joystick / Gamepad are causing the lock-ups - but perhaps there may be some other video or other workarounds that can be tried to get TOB to run smoothly ......... or perhaps its something on my test system solely ....... or perhaps the past is better left in the past, after at least using TOB as proof of concept.

Best of the day and weekend!

M
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Dave Yeo on May 28, 2022, 04:46:32 am
You could try adding DEVICE=X:\OS2\SDDHELP.SYS to your Panorama install with X: being your SNAP install and testing. Not likely to help but who knows.
Your lockup, does CTRL-ALT-F10 twice force a dirty reboot after failing to find a dump partition? Slightly cleaner then hitting the power button.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Lars on May 28, 2022, 03:55:17 pm
Use Panorama, but as a test, disable the screen buffer (it's in the screen settings). If that helps then unfortunately, you will have lousy overall video performance.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on June 01, 2022, 09:36:22 pm
Heh Lars!

Use Panorama, but as a test, disable the screen buffer (it's in the screen settings). If that helps then unfortunately, you will have lousy overall video performance.

I actually tried that previously at Dave's suggestion with Panorama, and got the hard lock-up, but decided to try it again today, as:

1) Finding the Options menu, I was able to switch from default High Resolution to Low Resolution, and

2) I was able to disable all the Texture Maps through the options menu, as a test, to see if that would make a difference.

The answer, disabling the Shadow Buffer is ............. NO, no diffference.

So unless someone else has a copy and can provide some input, I guess our answer is - YES, Wim's drivers are recognized by at least one other native OS/2 program, but no extended additional testing is possible at this time.

But thanks for the suggestion - as always useful and Best!

M

Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on June 02, 2022, 04:55:53 pm
Hi Guys!

As there was no Stanley Cup hockey playoff action last night (our Edmonton Oilers are in Round 3 against Colorado tonight) I had some free time after my ride, and decided to tackle trying to get DOOM to recognize the joysticks under DOSBOX.

I have a copy of both Doom and Ultimate Doom installed under DOSBOX and both run perfectly - however it is not obvious as to HOW to enable controller support, although it is mentioned under F1 in the UDOOM game as one of the control options.

So I went out to Memory-Alpha (my Star Trek reference for the Internet), to find out that I had to run Setup.exe for the program under DOSBOX, where the setting to enable controller functions is located.

I don't know how many others are actually using Jochen's version of DOSBOX for our OS, but I've found it very useful to run the DOSBOX GUI program Dosbox Front on top of it (I'm using v 4.9.5 which runs well on ArcaOS). It brings up a window, with Tabs, which allow you to choose settings for DOSBOX and create a .CMD file to run the DOS game or program.

Quickly setting up the Setup .CMD file, I was able to access it and enable Joystick support and calibrate the joystick (the setup program allows you to enable Joystick OR Mouse support, which is default. You can't seem to do both).

Running UDOOM, I was able to use my older Joystick, for both movement and with all four buttons available. It all worked very well, playing the game for over an hour, no problems noted. I have not tested the other Joystick yet.

I imagine setting up the regular Doom 2 controller support will not be much different, now that I know what to look for.

So currently, I have the following programs working completely with Joysticks, using Wim's experimental drivers under DOSBOX:

- Wolfenstein 3D
- Comanche 2
- Star Wars: Dark Forces
- Mechwarrior 2
- Ultimate Doom

There are some variations in the performance of the two joysticks in some programs, probably due to the Joystick algorithm problems mentioned by Wim, but overall, this has been a very uneventful Beta Test - and a much more fun gaming experience!

Best!

Mark
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Dave Yeo on June 03, 2022, 04:22:20 am
About to test the latest USB stack which has some HID changes and it occurred to me that joystick support should be tested.
So how should I test? eg what to install and run. I should test then update the drivers and retest.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Martin Iturbide on June 03, 2022, 05:21:45 pm
About to test the latest USB stack which has some HID changes and it occurred to me that joystick support should be tested.
So how should I test? eg what to install and run. I should test then update the drivers and retest.
Hi Dave

It is along forum thread and I don't want to go back  :)
Sorry if I'm asking things that you already post.

Picking up from here I'm using
- gamepad-20220317.zip  (https://www.os2world.com/forum/index.php?action=dlattach;topic=2895.0;attach=8471)
and updated the driver to:
- gamepad-20220517.zip  (https://www.os2world.com/forum/index.php?action=dlattach;topic=2895.0;attach=8670)
I hope I'm not confusing the versions here.

Change config.sys
According to your device HardwareID set your config.sys. Mine is like:
 DEVICE=X:\OS2\BOOT\USBECD.SYS /D:081#:##01:0106 /N:$PCSIGP$ /V
and
 DEVICE=X:\OS2\MDOS\GAMEDD.SYS
 DEVICE=X:\OS2\MDOS\GAMEPAD.SYS
 DEVICE=X:\OS2\MDOS\GAMEVDD.SYS

Test oinput.cmd and xevents.cmd
This is the tricky part since these file scripts are provided for some USB gamepad models that we tested with Wim. Here the scripts are the ones that connects the buttons actions with the gamepad (that is how I understand it). The name of the device ($PCSIGP$) is also an important things on the scripts.
While runing the scripts, If you get different codes when you press the buttons, it is good news.

Test an OS/2 game
With xevents.cmd running on the background I had tested Makman  (https://www.os2world.com/games/index.php/native-games/action-2/66-makman-2)(trying joy 1 and joy2)


Test DOS VDM:
With xevents.cmd running on the back you may test:
- https://hobbes.nmsu.edu/download/pub/dos/util/misc/JoystickTestUtils_1998-04-01.zip (https://hobbes.nmsu.edu/download/pub/dos/util/misc/JoystickTestUtils_1998-04-01.zip)
Also some DOS games that uses the Gameport joystick like Wolfstein in my case.

Test DOS Game with DOSBox
In my case it was very straight forward to also test Wolfstein 3D with DOSBox and gamepad worked.

Which USB Gamepad do you have? Can you generate the USB report of it?

Regards

Update: Oops, I forgot the gamepad drivers, corrected. But the best way is to read Mark's PDF.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Dave Yeo on June 03, 2022, 05:57:56 pm
The gamepad is,
Code: [Select]
Device 046D:C216 (HID) LS Logitech, Inc. F310 Gamepad [DirectInput which I guess needs a different usbecd.sys setting then any listed.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on June 03, 2022, 06:56:12 pm
Heh Dave!

About to test the latest USB stack which has some HID changes and it occurred to me that joystick support should be tested.
So how should I test? eg what to install and run. I should test then update the drivers and retest.

Hope your having a fine end of the week!

A while back I created a Testing Guide for Game Controllers, in PDF, which I attached below.

It gives all the set-up info for getting Wim's drivers to work.

However, about xevents.cmd - Wim, for these experiments created the drivers to address his extended control driver on a custom basis so in the RM203 directory of the gamepad package is the xevents.cmd file specifically created for my joystick, using my product ID's, etc. Martins is the same for the gamepads he submitted to Wim - as such, the xevents.cmd file would have to be edited with the info specific to your device, to function correctly.

The most current xevents file for my new joystick is attached below, which you may wish to use for editing purposes.

I am currently in the process of creating v1.2 of the testing guide to add more information related to how to do that, as well as how to use DOSBOX for testing purposes, and other items - hope to post that soon and Best!

Mark

P.S. If you or others have any suggestions related to the guide, I plan to create updates regularly during this testing process, so feel free to provide feedback on that through the thread here or at my Mark@paladinenvironmental.com e-mail.





Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Dave Yeo on June 04, 2022, 03:30:45 am
Well did step one, installing usbecd.sys and that killed my cheap non-conformant mouse, vender ID is zero on the mouse.
Now back to the PDF and figure out the parameters to usbecd.sys
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on June 08, 2022, 03:25:32 pm
Heh Dave!

Well did step one, installing usbecd.sys and that killed my cheap non-conformant mouse, vender ID is zero on the mouse.
Now back to the PDF and figure out the parameters to usbecd.sys

Hope your having a fine week.

Just was wondering if you found the Testing Guide v1.1 or any use at all in setting up Wim's DD's and getting your joystick or gamepad to work for testing.

I'm nearly finished v1.2 of same and just wondered if you had any suggestions as I put the finishing touches to it and Best!

M
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Dave Yeo on June 09, 2022, 08:19:25 am
Hi Mark, actually had 2 days in a row without rain, nice.
You're testing guide is fairly good, I did get lost in editing xeventsF1d.cmd, wasn't sure how to update it when it came to pressing buttons etc. I actually got 2 lines of output each time I did something, then something else came up and I got distracted. Other then that, it is pretty good.
Thanks
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on June 09, 2022, 03:57:51 pm
Hi Dave!

Just starting to get some rain this week here after weeks without, so nothing like what you or Manitoba are getting - my brother there said he was sure there was a lawn somewhere under the lake around his property ....... !

Hi Mark, actually had 2 days in a row without rain, nice.
You're testing guide is fairly good, I did get lost in editing xeventsF1d.cmd, wasn't sure how to update it when it came to pressing buttons etc. I actually got 2 lines of output each time I did something, then something else came up and I got distracted. Other then that, it is pretty good.
Thanks

As mentioned previously, when Wim created the gamepad package, the xevents files provided were customized in nature, based on equipment that Martin had provided and information about my original Thrustmaster joystick. Wim has done an amazing job on this project, in most cases at least for me going solely on the testing data I send him and lsusb reports, but as he has mentioned a number of times, we are still in the highly experimental stage.

I realize now that the xeventsf1d file was probably not the best one to provide - it was written for a joystick that has 4 buttons, a hat and the typical joystick movement mechanism, as well as an additional 6 buttons on the base, a throttle slider (which generates output but is probably useless for our applications and is programmable only in Windows)

I have not added anything currently in the guide I compiled about modifying xevents.cmd, but given you sound like your pretty busy at the moment, I wonder if you can simply try this.

I've attached xeventsjoy.cmd below, which is a version of the original xevents Wim provided, with some tweaking based on things we've found so far during testing.

Go into the file, which is for my older joystick, and modify the following:

Change Line 9:

ddNameI='$THRUST$' ; ddNameO='GAMEPAD$'

to ddNameI=<name for your device>
(ie. the /N: name you gave it in CONFIG.SYS)

Change Line 13:

info='DEVICE=?:\OS2\BOOT\USBECD.SYS /D:0583:203#:0110 /N:'ddNameI

to add the specific /D: info for your game controller as entered in CONFIG.SYS

Save the xevents.cmd file at that point and run it from a windowed command prompt.

If the device drivers are working and that is successful, you should see output being generated in the open window similar to:

Ax=4900, Ay=5600, Bx=FF00, By=6F00, Buts=F000

The output will continue every time an action is taken with your game controller and will vary based on what control is pressed or joystick movement occurs. Closing the window will stop the command file

You could try something similar for Gamepads, using one of the files contained in the directories other than in RM203 (that is my joystick) in the latest of Wim's Gamepad device driver package.

I'm curious to see if you just make those minor adjustments, Dave, without changing anything else, whether the xeventsjoy file would work for others - the whole basic output of joysticks really has not changed for decades, so if your using a simple joystick for testing most if not all of the other lines should work without modification.

The only basic weird thing we noticed when I did the same experiment with the new joystick, modifying the original xevents file, came when the output in the window was coming out as:

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

From the lsusb report we learned that the new joysticks input reports are only 7 bytes long. With the older joystiock it obtained 8 byte input records and check the 8th byte for certain values. That is why those HUH? packets were encountered.

I fine day to you Dave and Best!

M
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on June 09, 2022, 07:41:12 pm
Heh Guys!

I'm posting an new updated version of Testing Guide for Game Controllers - v1.2, in PDF, as attached.

I adjusted the formatting for easier readability, and try to add all the information, Martin, Wim and I have found so far about getting the device drivers and equipment to run for testing, under the Native OS and DOS - I've also added a Tested Equipment table to the guide, as a start, to compile things we've found so far and to add to in future.

To Wim and Martin - if you can give me some feedback about the equipment your using related to gamepads and possibly other joysticks I will try to add it to the next edition.

Hopefully anyone reading it will find the information useful, if you want to try to do some tests as well - I've tried to make the information user friendly, at the most basic level, so hopefully people won't find it too wordy or convoluted.

Any suggestions are also welcome here or at the e-mail given in the guide. Any faux pas's found are completely my own - any advances and brilliance related to this project are solely due to the efforts of people who never get enough credit for what they do for this community ............

As a tester, I've found this project a great learning experience - as one of my special skills is methods engineering, hopefully this contribution makes up for all the dumb questions I constantly ask related to the efforts of the people who do the real work here ...............

Best of the day to all!

M
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Martin Iturbide on June 11, 2022, 05:55:01 pm
Hi Mark

Thanks for your guide, I want to promote it a little bit. I was thinking to post a news about your guide and the beta testing of USB Gamepad that we are doing on this thread. Are you ok with that?

Regards
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Wim Brul on June 11, 2022, 06:21:18 pm
Hi Mark and Martin,

Right now I am reviewing the Testing Guide for Game Controllers - v1.2, in PDF, as attached earlier by Mark Szkolnicki.

Mark, I will send you an email with my comments as soon as possible. Will take some time though.

Martin, I think it is best to wait for Mark to have digested and incorporated my comments.

Best regards, Wim .
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Martin Iturbide on June 11, 2022, 06:45:32 pm
Martin, I think it is best to wait for Mark to have digested and incorporated my comments.

Ok, that's good.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on June 12, 2022, 04:59:51 am
Hi Wim!

Hope things are going well!

Hi Mark and Martin,

Right now I am reviewing the Testing Guide for Game Controllers - v1.2, in PDF, as attached earlier by Mark Szkolnicki.

Mark, I will send you an email with my comments as soon as possible. Will take some time though.

Martin, I think it is best to wait for Mark to have digested and incorporated my comments.

Best regards, Wim .

I think we're at the point, given Dave Yeo, a very active participant in the community, wants to do some testing, knowing that he is very inolved in Seamonkey at the moment, so I would want what we're doing to reflect the positive results received so far, as well as reflecting the experimental nature of what we're doing, as well, to provide more data..

Do you think that can be done, Wim at this stage? Frankly I think we need a little more involvement from others - as long as its not suddenly meaning that you are having to create more custom joystick or gamepad xevents packages - the current guide reflects that in the wording and Best!

M
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Dave Yeo on June 12, 2022, 05:29:57 am
Yes, I'm hoping to revisit once not so busy. So much to do outside if it doesn't rain tomorrow and right now I don't want to do anything that might lead to a reboot :) I'm sure memory is getting short, yep 94 MB shared low memory.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: David McKenna on June 12, 2022, 03:20:57 pm
 I've also been following this with interest so ordered a Logitech F310 gamepad (seems to be popular and inexpensive). Once I get it, I'll use Mark's guide to try it out. Thanks for all the development work on this!

Regards,
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on June 12, 2022, 04:33:49 pm


Good Morning, Wim

Hi Mark and Martin,

Right now I am reviewing the Testing Guide for Game Controllers - v1.2, in PDF, as attached earlier by Mark Szkolnicki.

Mark, I will send you an email with my comments as soon as possible. Will take some time though.

Martin, I think it is best to wait for Mark to have digested and incorporated my comments.

Best regards, Wim .

Take all the time you need, Sir! I'm looking forward to your comments.

Theres a couple of items related to this that I'd like to discuss as well with you directly, but don't have an e-mail - if you'd like to provide one to the e-mail;; I indicated in the guide, we can do some brainstorming and Best!

M

Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on June 12, 2022, 04:47:52 pm
Heh Dave!

Yes, I'm hoping to revisit once not so busy. So much to do outside if it doesn't rain tomorrow and right now I don't want to do anything that might lead to a reboot :) I'm sure memory is getting short, yep 94 MB shared low memory.

I was outside all day yesterday - fixing some solar lanterns (rebuilt the lanterns and replaced some solar panels), cut our 1/4 acre, put waterlilies back in our pond, cut down and corded 2 columnar aspens - the checkmarks on my checklist are probably like yours - they are far outnumbered by TTD's, given the length of our summer season here in Alberta.

But I couldn't live in the city anymore, except under duress, Dave - the natural trees in bloom; geese, ducks, herons and swans on the lake; waking to all the varieties of songbirds, and visits by hummingbirds, songbirds and squirrels to our feeders, birdbaths and our tsukabai and fountains - I came from the north end of Winnipeg, and it was nothing like this .........

Nope Keep Manhattan, just give me that countryside ........... !

And as to memory - sometimes I think I only have about 94 Mb upstairs on a good day .............. <sic>

M
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on June 12, 2022, 05:13:56 pm
Heh David!

Hope you having a fine weekend.

I've also been following this with interest so ordered a Logitech F310 gamepad (seems to be popular and inexpensive). Once I get it, I'll use Mark's guide to try it out. Thanks for all the development work on this!

Regards,

Yes, some days it does look like its just Wim, Martin and I having a conversation on this thread - until the straw poll (views) tells me that there have been 24,700 views of this thread as of this morning. Obviously there is a LOT of interest in what may seem like a tiny trivial subject, David ..............

I wanted to do a guide on what we are doing to capture what we've learned so far, as the one thing I do see is a LOT of useful information provided by the very gifted braintrust that lurks around our forums - the trouble is how many hundred posts do you have to go through to find the one thing that you seem to recall in someones post from 2 years ago? I'm doing this constantly myself, so I thought, why not?

Version 1.1 was ready, and I was using it as a guide myself, so when that rather fun loving Mr. Yeo (who steals his kids gamepads when they're not looking) started asking about what we were doing, I thought it was time to release it, as Martin was heroically trying to explain how to do all this from scratch (and Martin IS a true hero - perhaps we should do a video game starring HIM someday)  :)

In my spare <sic> time I'm hoping to do more of these, on other subjects we're discussing - I have a few in draft for my own use already, as its something I've done for years for paying clients - only their emergency plans and guides usually ran into hundreds of pages, something I hope to avoid here .......

But thanks for your kind words today, Sir - in my experience, in emergency response, when you do something right, you never hear a peep - however, if things go horribly wrong ........... WELL!

Best!

M
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Martin Iturbide on June 12, 2022, 06:46:28 pm
Hi

I want to try the PlayStation 3 controller (USB Connected).

I had added this on the config.sys:
Code: [Select]
DEVICE=X:\OS2\BOOT\USBECD.SYS /D:054C:0268:0100 /N:$PSX3$ /V
I had changed the "HUSKEE" oiput and xevents scripts to point to "$PSX3$". In xevents I had updated "Line 13" (or 14?) to point to "054C:0268:0100", but I get no output from the scripts. I guess it is not as simple as that.

Any tips?

Regards
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Martin Iturbide on June 12, 2022, 07:49:52 pm
Hi Mark.

Just in case, if you want to update the table on your guide (Page 9 - tested Equipment), I have some details of my gamepads here: https://www.os2world.com/wiki/index.php/Category:Joysticks (https://www.os2world.com/wiki/index.php/Category:Joysticks)

Which reminds me I need to take some time to test the "Genius MaxFighter F-31U Vibration (https://www.os2world.com/wiki/index.php/Genius_MaxFighter_F-31U_Vibration)" that I have around.

Regards
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Wim Brul on June 12, 2022, 09:26:08 pm
Hi Martin,
Hi

I want to try the PlayStation 3 controller (USB Connected).

I had added this on the config.sys:
Code: [Select]
DEVICE=X:\OS2\BOOT\USBECD.SYS /D:054C:0268:0100 /N:$PSX3$ /V
I had changed the "HUSKEE" oiput and xevents scripts to point to "$PSX3$". In xevents I had updated "Line 13" (or 14?) to point to "054C:0268:0100", but I get no output from the scripts. I guess it is not as simple as that.

Any tips?

Regards
Since this controller has not been tried and tested before, it is best to prepare a new oinput.cmd first.
From the attached lsusb -v report (PSX3controller.txt) I learned that it uses 64 byte input records.
I have prepared oinput64.cmd that I attach here for you to tryout first.

Best regards,
Wim.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on June 13, 2022, 04:28:11 pm
Hi Martin!

Hi Mark.

Just in case, if you want to update the table on your guide (Page 9 - tested Equipment), I have some details of my gamepads here: https://www.os2world.com/wiki/index.php/Category:Joysticks (https://www.os2world.com/wiki/index.php/Category:Joysticks)

Which reminds me I need to take some time to test the "Genius MaxFighter F-31U Vibration (https://www.os2world.com/wiki/index.php/Genius_MaxFighter_F-31U_Vibration)" that I have around.

Regards

Thanks, Martin - I'll add some more of the actual explanation info into the Tested Equipment Section

I'll send you some info related to the Logilink adapter as well as the Thrustmaster Joysticks for inclusion there as well, with pictures.


Let me know either here or via my e-mail once you've tested the MaxFighter and I''ll also add that if things are working for you

Got comments from Wim so will be starting Guide v1.3 sometime today - if anyone else has any observations or success stories, I'd be interested in those.

Best!.

M
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Martin Iturbide on June 13, 2022, 04:43:42 pm
Hi Martin,
Hi

I want to try the PlayStation 3 controller (USB Connected).

I had added this on the config.sys:
Code: [Select]
DEVICE=X:\OS2\BOOT\USBECD.SYS /D:054C:0268:0100 /N:$PSX3$ /V
I had changed the "HUSKEE" oiput and xevents scripts to point to "$PSX3$". In xevents I had updated "Line 13" (or 14?) to point to "054C:0268:0100", but I get no output from the scripts. I guess it is not as simple as that.

Any tips?

Regards
Since this controller has not been tried and tested before, it is best to prepare a new oinput.cmd first.
From the attached lsusb -v report (PSX3controller.txt) I learned that it uses 64 byte input records.
I have prepared oinput64.cmd that I attach here for you to tryout first.

Best regards,
Wim.

Hi Wim

I had tried the attached "oinput64.cmd" but it does not gave me any response when I press the buttons. I only get black screen with no activity.
I had confirmed that the PSX3 controller is connected by using lsusb and checking that it has the lights blinking.

Regards
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Martin Iturbide on June 13, 2022, 05:01:37 pm
Hi

It was time to also give a test drive to the "Genius MaxFighter F-31U Vibration (https://www.os2world.com/wiki/index.php/Genius_MaxFighter_F-31U_Vibration)" with ArcaOS.

I took the "RM203" files and copy it as "MAXFIG".
Added:
 
Quote
DEVICE=X:\OS2\BOOT\USBECD.SYS /D:0458:3019:0100 /N:$MAXFIG$ /V
Changed the oinput and xevents and I got some output there.

But I overestimated the difference between a joystick and gamepad. It seems that the joystick has something different that is always "pressing". Even that I got different visual feedback when I press the buttons, I was not able to make Makman and Wolfstein 3D to work with the RM203 scripts, also the DOS game joytest utilities does not provide any movement.

I'm attaching the scripts and log just in case.

Regards

Funny Note: I had to check the online dictionary to know what is a "Rudder" and I still does not know what does it do on a Joystick  ;D
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on June 13, 2022, 09:13:33 pm
Hi Martin!

Hi

It was time to also give a test drive to the "Genius MaxFighter F-31U Vibration (https://www.os2world.com/wiki/index.php/Genius_MaxFighter_F-31U_Vibration)" with ArcaOS.

I took the "RM203" files and copy it as "MAXFIG".
Added:
 
Quote
DEVICE=X:\OS2\BOOT\USBECD.SYS /D:0458:3019:0100 /N:$MAXFIG$ /V
Changed the oinput and xevents and I got some output there.

But I overestimated the difference between a joystick and gamepad. It seems that the joystick has something different that is always "pressing". Even that I got different visual feedback when I press the buttons, I was not able to make Makman and Wolfstein 3D to work with the RM203 scripts, also the DOS game joytest utilities does not provide any movement.

I'm attaching the scripts and log just in case.

Regards


Did you try modifying the Xeventsf1d.cmd file that Wim created for me? (I've attached it again below but included it in a separate post to Dave Yeo previously)

I don't know which Xevents is present in the most current RM203 file, but the MaxFighter looks very similar to the T.Flight X in configuration, so the changes there may settle things down. The MaxFighter schematic seems very similar to the T.Flight, being kind of a cross between a joystick and a gamepad

Some of that may also be due to calibration - the Mk2 and T.Flight X have sometimes needed to be re calibrated when one or the other is used in a game.

Some Joysticks can also be really sensitive - the new T. Flight has a tension adjustment on the bottom which I have cranked up to max, as I'm used to the heavy springs on the Mk2.


Funny Note: I had to check the online dictionary to know what is a "Rudder" and I still does not know what does it do on a Joystick 


The T. Flight actually has a Throttle control on the base which is a slider.

The Mk II was actually part of a Flight Control System, which also included a separate plug-in throttle. The latest systems have a Joystick, separate Throttle, Foot peddles for rudder control, sometimes even what is called a "collective" lever for helicopter control (adjusts the rotors so the helicopter doesn't spin out of control - its also the way to control direction) - I know one fellow who even has a custom chair to surround himself with all the controls - WILD!

M
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on June 14, 2022, 01:58:58 am
Heh Martin!


But I overestimated the difference between a joystick and gamepad. It seems that the joystick has something different that is always "pressing". Even that I got different visual feedback when I press the buttons, I was not able to make Makman and Wolfstein 3D to work with the RM203 scripts, also the DOS game joytest utilities does not provide any movement.


Wim in an e-mail back to me mentioned you had indicated that Masterroids might be another possible native OS/2 game to test, as it does have Joystick support. So I decided to download it from OS2World today, install and run it.

Have you or has anyone else actually tried to run this game?

Its circa 1995 and has a registration block which was obviously quite important to the author - however, despite a seemly endless set of menu categories and customization choices, there seemly seems to be something missing ............. as in HOW DO YOU ACTUALLY START THE GAME?!?

The first (Game) selection menu certainly tells you how to stop a session and exit the game, but nothing obvious as to how to start it - it originally pops up with a window that's supposed to allow you to sign in as a player (and a block on it that you must click to acknowledge you will register in 30 days) which cycles back and forth between that page and a title page, but NO menu item that simply says "Start New Game".

Exiting the game gives you this weird screen where you're supposed to place checkmarks in 7 checkboxes around the window then click a big checkmark button at the bottom.

Any clues as to how to run this one - looks like an exciting variation in living technicolour (if anyone remembers THAT) of the old monochrome Asteroids game.

Best!

M
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Neil Waldhauer on June 14, 2022, 02:26:46 am
I haven't tried this in years, but it is a pretty nice game that ought to be cracked.

To play, use the menu Game->Players->1 and the game will start. Fire using right shift, and right control does shields or something.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on June 14, 2022, 05:38:29 am
Heh Neil!

I haven't tried this in years, but it is a pretty nice game that ought to be cracked.

To play, use the menu Game->Players->1 and the game will start. Fire using right shift, and right control does shields or something.

Discovered that after trying every key combination on the keyboard and then starting with the Games Dropdown - I discovered it by pure dumb luck - of such is brilliance made <sic>.

Still trying to get it to recognize the joystick - it looks like its calibrating but your using the mouse to press all the buttons - starting the game no movement of the joystick or buttons are recognized.

Will try using just the keyboard for the moment - looks like it could be a fun game ............ if you like blowing lots of things up ............. !

M
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on June 14, 2022, 06:31:57 am
Okay Guys and Gals - after some head scratching, I got joysticks working under Masterroids 1.1.

Again it is not obvious how to do it.

With Xevents running for the joystick I'm testing, I ran Masterroids - a box is present at start-up asking you to center the joystick and then press enter (can be done from either a mouse or hitting ENTER on the keyboard.

Follow the instructions when the calibration graphic window opens - move the joystick around in a circle a couple of times then click the big Checkmark button.

Before starting the game you must go to the Options dropdown, and then click on Player (very obvious, right? - N-O-T)

A window will open which allows you to customize the keyboard control settings, for each of up to 4 players. However, there is also a checkbox marked "Joystick" which must be checked as well. Press the big Checkmark button at the bottom to go back to the starting screens.

To run the game, go to the Games dropdown - choose 1 player, then enter, to start the game.

Without checking that one Joystick checkbox, the game will not recognize that a Joystick is there, despite asking you to calibrate same .......... a fine example of the first corollary to Murphy's Law - namely Murphy was an optimist ............

And, oh, by the way, this has to be done each time the game is run - despite the ability to register the game is long in the past, the unregistered version will not save any changes to PLAYER or SETTINGS options from game to game, as opposed to settings under CONFIGURATION, also in the Options dropdown.

But we have yet another native OS game that can be tested, kids - and from the limited time spent on it this evening, a game that is a lot of fun, bringing me back to the money dropping hours I spent in the video arcades about a century ago .......... !

Time for bed and Best!

M
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on June 14, 2022, 06:19:45 pm
Heh Dave


I'm sure memory is getting short, yep 94 MB shared low memory.


When I was trying to decrypt how to run Masterroids yesterday, I had to chuckle when I read the readme.1st file included, as follows:

--------------------

MASTERROIDS loads up to 3 MB data, so your computer should have a
    minimum of 8 MB RAM. (Sorry about that, but I had no chance to test the
    game on a computer with 4 MB. I don't even know, if 4 MB is enough for
    OS/2 itself. )

    You should have a 486 or better (66 MHz or more. 33 MHz is possible
    but slow. Sorry. )

    Cause the game puts your graphic-card to its limits (and the processor
    as well) it would be the best, you have no other programs running in the
    background.

________________

You could have run roughly 30 sessions of Masterroids, at the same time in the 94 Mb left!

And apologizing for the program taking up ALL CPU time and Graphics cards resources?

How our view of the tech world, and its challenges, has changed .....................

M
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Martin Iturbide on June 15, 2022, 01:54:29 am
Hi Martin!

Hi

It was time to also give a test drive to the "Genius MaxFighter F-31U Vibration (https://www.os2world.com/wiki/index.php/Genius_MaxFighter_F-31U_Vibration)" with ArcaOS.

I took the "RM203" files and copy it as "MAXFIG".
Added:
 
Quote
DEVICE=X:\OS2\BOOT\USBECD.SYS /D:0458:3019:0100 /N:$MAXFIG$ /V
Changed the oinput and xevents and I got some output there.

But I overestimated the difference between a joystick and gamepad. It seems that the joystick has something different that is always "pressing". Even that I got different visual feedback when I press the buttons, I was not able to make Makman and Wolfstein 3D to work with the RM203 scripts, also the DOS game joytest utilities does not provide any movement.

I'm attaching the scripts and log just in case.

Regards


Did you try modifying the Xeventsf1d.cmd file that Wim created for me? (I've attached it again below but included it in a separate post to Dave Yeo previously)

I don't know which Xevents is present in the most current RM203 file, but the MaxFighter looks very similar to the T.Flight X in configuration, so the changes there may settle things down. The MaxFighter schematic seems very similar to the T.Flight, being kind of a cross between a joystick and a gamepad

Some of that may also be due to calibration - the Mk2 and T.Flight X have sometimes needed to be re calibrated when one or the other is used in a game.

Some Joysticks can also be really sensitive - the new T. Flight has a tension adjustment on the bottom which I have cranked up to max, as I'm used to the heavy springs on the Mk2.


Funny Note: I had to check the online dictionary to know what is a "Rudder" and I still does not know what does it do on a Joystick 


The T. Flight actually has a Throttle control on the base which is a slider.

The Mk II was actually part of a Flight Control System, which also included a separate plug-in throttle. The latest systems have a Joystick, separate Throttle, Foot peddles for rudder control, sometimes even what is called a "collective" lever for helicopter control (adjusts the rotors so the helicopter doesn't spin out of control - its also the way to control direction) - I know one fellow who even has a custom chair to surround himself with all the controls - WILD!

M

Hi Mark

I tried xeventsF1d.cmd , I changed the NAME and HardwareID, but I get no output from it.
I tried back the xevents.cmd (RM203) and it keeps giving me some output.

Regards
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Dave Yeo on June 15, 2022, 02:14:15 am
Hi Martin, my limited understanding is that the PlayStation (and XBox) controllers aren't actually joysticks, at least as far as the PC is concerned. They look like a joystick and act like a joystick but use a different driver. My son, who is currently using an XBox controller on his Windows PC agrees.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Dave Yeo on June 15, 2022, 02:22:02 am
Hi Mark, when I first started using OS/2, Warp v3, it was on a 4MB 386/33. At first just as a drop in replacement for DOS, then slowly migrating to OS/2 programs like WebExplorer. Had to be very careful in tuning and not use the WPS for it to be usable. That readme would have been very pertinent at the time. Even when I upgraded to 8MBs and swapped the CPU for a 486DLC.
Now here we are, so much memory that most is used as a ramdisk and still worried about the browser using all the memory :)
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on June 15, 2022, 03:35:53 am
Hi Martin!


Hi Mark

I tried xeventsF1d.cmd , I changed the NAME and HardwareID, but I get no output from it.
I tried back the xevents.cmd (RM203) and it keeps giving me some output.

Regards

Then I suspect, although the layouts of T.Flight and the MaxFighter are similar, your MaxFighter has more in common with the older joystick than the newer - input packet size perhaps? Looking at your lsusb hardware report and mine I see marked differences in the way each operates, although there are commonalities as well.

Did you modify the original xevents.cmd in RM203 from the original package (gamepad-20220317?)

If so, you might want to try this one attached - it is the latest one I'm using for the older Joystick - it contains some modifications from the original - I suspect it won't solve all your problems, but see if its any better than your first try.

Best!

M

Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Wim Brul on June 15, 2022, 10:11:37 am
Hi Martin and Mark,

I am a little bit disappointed. What you are doing is not the way to go. The "PlayStation 3 controller (USB Connected)" and the "Genius MaxFighter F-31U Vibration" are controllers not yet tested at all. Remember the method we used in the past. You need to follow the step by step approach as outlined in the "testing.txt" files that are part of the package. For the huskee device that procedure starts as follows:

Code: [Select]
Installation Instructions - Part A
==================================

A1. Ensure that USBECD.SYS has been installed.

A2. Put the following line in your CONFIG.SYS file:
(Use the proper drive and directory for your system).

DEVICE=H:\OS2\BOOT\USBECD.SYS /D:0C12:0005:0001 /N:$HUSKEE$ /V

A3. Reboot your system.

A4. Run OINPUT.CMD and watch gamepad events in hexadecimal format.
Use Ctrl+C to end this procedure.

Once this is working I would like you to do the following:
---------------------------------------------------------

A5. Run OINPUT.CMD > BUTTON.LOG and press available buttons
(one at a time, after each other, and tell me which ones)
Use Ctrl+C to end this procedure.

A6. Run OINPUT>CMD > STICK.LOG and press stick to different positions
(one at a time, after each other, and tell me what positions)
Use Ctrl+C to end this procedure.

Send me files BUTTON.LOG and STICK.LOG for me to inspect.
--------------------------------------------------------

Since you are preparing oinput.cmd yourself for these new devices, you have to prepare the corresponding testing.text accordingly. It is waste of time and effort to skip these steps.

I am currently investigating what needs to be done to provoke the "PlayStation 3 controller (USB Connected)" to send event records so step A4. can be completed succesfully.

I understand that for the "Genius MaxFighter F-31U Vibration" step A4. has been completed successfully. Why not append some of that output for me to inspect?

Best regards, Wim.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Martin Iturbide on June 15, 2022, 02:15:08 pm
Hi Wim

Thanks for posting the instructions again and keep us on the right track. I will follow that procedure for the "Genius MaxFighter F-31U Vibration" and post back.

Regards
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on June 15, 2022, 05:53:15 pm
Hi Wim!

Hope you are having a fine day!

Hi Martin and Mark,

I am a little bit disappointed. What you are doing is not the way to go. The "PlayStation 3 controller (USB Connected)" and the "Genius MaxFighter F-31U Vibration" are controllers not yet tested at all. Remember the method we used in the past. You need to follow the step by step approach as outlined in the "testing.txt" files that are part of the package. For the huskee device that procedure starts as follows:

Code: [Select]
Installation Instructions - Part A
==================================

A1. Ensure that USBECD.SYS has been installed.

A2. Put the following line in your CONFIG.SYS file:
(Use the proper drive and directory for your system).

DEVICE=H:\OS2\BOOT\USBECD.SYS /D:0C12:0005:0001 /N:$HUSKEE$ /V

A3. Reboot your system.

A4. Run OINPUT.CMD and watch gamepad events in hexadecimal format.
Use Ctrl+C to end this procedure.

Once this is working I would like you to do the following:
---------------------------------------------------------

A5. Run OINPUT.CMD > BUTTON.LOG and press available buttons
(one at a time, after each other, and tell me which ones)
Use Ctrl+C to end this procedure.

A6. Run OINPUT>CMD > STICK.LOG and press stick to different positions
(one at a time, after each other, and tell me what positions)
Use Ctrl+C to end this procedure.

Send me files BUTTON.LOG and STICK.LOG for me to inspect.
--------------------------------------------------------

Since you are preparing oinput.cmd yourself for these new devices, you have to prepare the corresponding testing.text accordingly. It is waste of time and effort to skip these steps.

I am currently investigating what needs to be done to provoke the "PlayStation 3 controller (USB Connected)" to send event records so step A4. can be completed succesfully.

I understand that for the "Genius MaxFighter F-31U Vibration" step A4. has been completed successfully. Why not append some of that output for me to inspect?

Best regards, Wim.

I deeply apologize as well if you feel we are jumping the gun, Wim as I consider you a friend and as that was not my intention. I am probably more to blame than Martin in this.

However, here is a perspective for consideration - as this testing is being done in a public forum, there is a lot of interest being generated, and a lot of people are watching what is happening. Since publishing the Testing Guide I have received private e-mails from others wondering if they can participate, as they feel we are actually carrying on a private conversation between ourselves, in public, and they are simply watching.

As we are also releasing the gamepad-xxxxxxxx,zip files in public, they are wanting to try these drivers for themselves and are looking for a path to do so. IOW there are a lot of potential testers out there that can help - but we need to enable them to do so.

Since the original gamepad package was released, the additional packages have not contained the original sub folders, for the equipment we started with (ie. Marttins and mine), which were actually the items that contained the testing instructions. If we want to keep this more structured, and possibly generate more data from others and their game controllers, I would propose the following:

1) Can we create a new gamepad package, with the most current drivers, and two folders - simply gamepad, and joystick, if the instructions need to be different for the two, and Include the necessary files in each to stay to the structure you specified. They should simply contain the files necessary to test the device, and generate the necessary information for you, to be posted here.

2) I will modify the Testing Guide to stay strictly to the program you specify there in testing.txt, plus the additional information that will allow them to test game controller function once an xevents file is created, that either we or they can test. I would also suggest adding some information on generating lsusb reports, and how to do that to the guide as well.

I will send the draft version of the guide to you privately first, so you can approve the testing info in it, so we can run these tests properly.

The only problem I foresee with that, Wim, is that you may be literally inundated with data from all sides, and it may overwhelm in that sense. You have already done a lot for this project, and being overwhelmed is the last thing we want, because, strangely you also have a life.

Best as always, Sir

M

Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on June 15, 2022, 07:48:47 pm
Heh Dave!

110 mm of rain so far in the last two days - more to come

Hi Mark, when I first started using OS/2, Warp v3, it was on a 4MB 386/33. At first just as a drop in replacement for DOS, then slowly migrating to OS/2 programs like WebExplorer. Had to be very careful in tuning and not use the WPS for it to be usable. That readme would have been very pertinent at the time. Even when I upgraded to 8MBs and swapped the CPU for a 486DLC.
Now here we are, so much memory that most is used as a ramdisk and still worried about the browser using all the memory :)

My first computer was the third IBM PC in Winnipeg (the original PC, not PC-XT).

It was an 8088 CPU, no 8087 co-processor installed, came with two full height 5.25" 360K floppy drives  (the full height brick size hard drive was too expensive for my meager budget of the time - and its full capacity, if I bought one was a whopping 10 Mb).

I think on-board memory was either 64K or 128 K, with a Hercules monochrome graphics card and screen, no sound other than the built-in PC speaker.

Strangely you were still able to do a lot on it command line wise - I learned DOS, and my first word processor was Volkswriter, which did not have bells and whistles but still worked well. Learned Windows starting with v3, as I learned I could add new components to the box and upgrade it (remember AST memory cards, and the absolutely state of the art 10 Mb Hardcard hard drive, which plugged into the motherboard bus, like other add on cards?).

Still have that box, but most items in a disassembled state - got rid of the full height floppys, but wish I had kept them - was hoping to reassemble that box someday, but probably will just get rid of it to make space ............

I jumped up to a 386/66 next, where I installed OS/2 for the first time - v2.0 (missed v1.3), then v2.11, Warp 3, Warp 4 (added all the fixpacks, which came on the new 1.44 Mb 3.5" disks - sometimes 16 or so of them), then on to eCS and now ArcaOS,

Along the way I learned how to build computers from components, setup and run a network, connect first with a 28 K modem, then 56 K (remember Compuserve and Golden Compass for OS/2?) then on to ADSL, Satellite and where we are today.

So about 25 or so Desktops, Towers and portables later here I am - still a hardware geek, but one that has covered the entire history of the PC line, IBM or otherwise.

So yes, its amazing that we marvel at 94 Mb being small, given where we've come from ............

M

Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Wim Brul on June 16, 2022, 05:26:06 pm
Hi Mark,

Quote
The only problem I foresee with that, Wim, is that you may be literally inundated with data from all sides, and it may overwhelm in that sense. You have already done a lot for this project, and being overwhelmed is the last thing we want, because, strangely you also have a life.

Thank you Mark, for your compassion. Right now I am already grinding to a standstill. This is all too much for me to handle. In light of my health I have to let go.

Will send you an email soon.

Best regards, Wim.
Title: Re: DOS VDM - USB and Game port Gamepad support
Post by: Mark Szkolnicki on June 17, 2022, 04:02:07 am
Thanks Wim, for your contribution to this.

Hi Mark,

Quote
The only problem I foresee with that, Wim, is that you may be literally inundated with data from all sides, and it may overwhelm in that sense. You have already done a lot for this project, and being overwhelmed is the last thing we want, because, strangely you also have a life.

Thank you Mark, for your compassion. Right now I am already grinding to a standstill. This is all too much for me to handle. In light of my health I have to let go.

Will send you an email soon.

Best regards, Wim.

You've been nothing other than gracious, in both your time, and interest in this small little project, as well as the advances you have contributed to in all areas, including this, based on your technical knowledge.

The least we can all do is say - Thank-you!

We will muddle on, as always, Sir, like the rest of humanity,

Rest, Warrior and Best, as always - will email soon as well!

M