Newbie Needing to Know Where To Start With Joysticks

[ChrisHale]

Hi all!

I'm looking to get my CH Fighterstick USB from CH Products working with my Thinkpad 390X. I have the drivers loading up fine in DOS and I've read far enough to know how to change some of the settings in USBJSTIK.COM. I'm going to need to reread the directions a few times because I'm not entirely sure what the next step is that I should take. Is there a way of seeing if my joystick is being detected by the driver and I'm pretty sure I need to write up a config file to map my joystick to USBJSTIK. Can anyone give me the broad strokes or checklist of what I need to read up on?

Thanks and sorry!

[ChrisHale]

So, I'm able to verify that the driver is working with my joystick using JOYKY200's THRUST.COM output. The axis's values are updating and it's showing 4 of the buttons are responding with on/off value changes. However, when I run my copy of Descent the game won't recognize that any joystick is present and throws an error. Would anyone know if Descent is simply incompatible with the driver?

[Bret]

Chris:

In THRUST, make sure you are using the D option (THRUST D) to verify the joystick is emulating at the hardware level instead of the software/BIOS level. Unfortunately, emulating at the hardware level requires that you to use Microsoft's EMM386 (and it must be the one from Microsoft).

Even then, it may not necessarily work with Descent but there is a much greater chance that it will.

[EdwardBrittgmtB]

Hello. I had this with a mouse. Try to pull the joystick out of the network and reset it to factory settings.

[biggieshellz]

For anyone running into the same issue, I was able to get Descent / Descent 2 to work with a USB joystick using the usbjstik driver. The default mode doesn't work, even with EMM386 and virtualized I/O (working as tested with THRUST.EXE), but if you run it as 'descent2 -JoyBios', it works just fine. Note that for original Descent, you should update to v1.5 for this option to become available.

Bret, I know you're probably way too busy to take a look at an edge case like this, but the Descent source is available at https://github.com/videogamepreservation/descent and there is a joystick test utility in BIOS\TESTJ.C that would probably reproduce the issue.

[Bret]

Thanks for the information. It's good to know the Descent has made the necessary updates. I looked a little bit at the code, and the "interesting" file is JOY.ASM which details how the joystick is accessed. It contains both the "regular" joystick polling (which uses the I/O ports directly, the same way most games do) and the BIOS polling (which is what is required by the USB drivers).

A little technical sidelight here on why using the I/O ports doesn't work. To virtualize I/O ports, USBJSTIK must leverage the capabilities of EMM386. What EMM386 does is put the CPU into protected mode "permanently" and then runs DOS in the Virtual-86 (V86) mode of the CPU. Even though the CPU acts very much like it is in Real Mode when EMM386 is installed, it really isn't.

When in V86 mode, there are several CPU instructions that will create faults in the CPU (there are several instructions that are allowed in Real Mode but not in Protected Mode). The CPU notifies EMM386 when these faults occur so EMM386 can "fix" them so the DOS programs think they are running in real mode. Some of the instructions that can cause issues are reads and writes to the I/O ports (such as the game port I/O).

When the CPU is in Protected Mode, there is a table for all 65,536 I/O ports which indicates whether a specific I/O port should be trapped or not (whether or not it should generate a "fault" for EMM386 to handle). EMM386 has several I/O ports it must "trap" in order to effectively simulate real mode, include things like the I/O ports associated with Direct Memory Access (DMA) and the keyboard controller (because on some computers the keyboard controller is used to turn the Address-20 (A20) line on and off so the computer can access high memory addresses). The program thinks it's talking to the real I/O port when it isn't -- EMM386 must "virtualize" what the program is trying to do in Real Mode.

In later versions of EMM386, MS added an I/O Virtualization feature. This allows DOS programs (like USBJSTIK) to virtualize I/O ports. What happens is that the program (like USBJSTIK) informs EMM386 which I/O ports it wants to virtualize and provides a memory address for EMM386 to "call" when the I/O port is accessed. EMM386 then modifies the "I/O trap" table in the CPU so that when one of the I/O ports is accessed by a program, the CPU informs EMM386 of the "fault" and then EMM386 "calls" the "I/O Virtualizer" (in this case, USBJSTIK) to tell it how to respond to the I/O call. But, this usually only works when the program itself runs in Real Mode.

When a program runs in Protected Mode (such as running under DPMI), the "I/O Trap Table" used by EMM386 is no longer used. So, when the Protected Mode program (like Descent) accesses an I/O port, the actual I/O port is addressed instead of it being virtualized (by the combination of EMM386 and USBJSTIK).

I know that's a lot of information, and maybe a lot more information than you wanted, and I hope it makes sense.

I think all Protected Mode program should do something similar to Descent, where you can select between using I/O or using the BIOS to access the joystick(s). The BIOS code is actually much simpler, smaller, and faster. The reason most programs don't use the BIOS is because the joystick BIOS function on many modern computers doesn't work right, so the programs simply assume it NEVER works right. But if the joysticks are not actual analog joysticks attached to a regular game port, that isn't true.

I have released two joystick-related programs, USBJSTIK and SDWRGMPD. USBJSTIK works with USB joysticks and gamepads, and SDWRGMPD works with the old Microsoft Sidewinder gamepad (which I don't think is even made any more). The Sidewinder attaches to a regular game port but uses a special digital protocol instead of the "normal" analog protocol that most joysticks use. I know Microsoft also made other joysticks/gamepads which attached to regular game ports and used special digital protocols, and I know other joystick manufacturers did too (including Logitech). In looking at the Descent code, it doesn't look like it will work with any of those digital joysticks or gamepads.

What I did with SDWRGMDPD and USBJSTIK is to set it up so that you really SHOULD use the BIOS to access the joystick/gamepad, but I also TRY to let you access it directly through the I/O ports (by virtualizing the I/O port). But I/O virtualization is only provided by later versions of EMM386 and 386MAX (made by Qualitas), and even then usually doesn't work if the game uses Protected Mode (and a lot of them do nowadays).

What I've done with SDWRGMPD and USBJSTIK is added a special function to the joystick BIOS to indicate that the joystick is virtualized and that the joystick BIOS works correctly and can be trusted. This is discussed in the documentation for SDWRGMPD (though it is not prominent so most people probably miss it), and of course it is in the source code for both programs (though you do need to look for it) :

The format of the special BIOS function is:

INT 15h, with AH=84h and DX=-1 (FFFFh)

If the driver is installed and ENABLEd, return with Carry clear and
DX=0.

If the driver is not installed, or is DISABLEd (which is functionally
the same as not having it installed), return with Carry set and AH=80h
or 86h (the regular BIOS function will do this for you). The regular
BIOS will also usually return with DX unchanged, but you should not
depend on it. The regular BIOS function may also change BX and CX.

If Descent (or other programs) called this function to automatically detect a "valid" joystick BIOS you wouldn't even need to use the "-joybios" option.