DOS VDM - USB and Game port Gamepad support

[Andreas Schnellbacher]

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.

[David McKenna]

 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,

[Mark Szkolnicki]

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

[Dave Yeo]

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.

[Jochen Schäfer]

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.

[Mark Szkolnicki]

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

[Mark Szkolnicki]

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

[Dave Yeo]

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.

[Roderick Klein]

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

[Mark Szkolnicki]

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

[Wim Brul]

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.

[Mark Szkolnicki]

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

[Wim Brul]

Hi Mark,

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

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

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

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.

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

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.

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

[Mark Szkolnicki]

Hi Wim

Busy weekend so was not on-line at all

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

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.
   

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

[Wim Brul]

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