X-Wing, TIE Fighter and Joystick hat switch support

ps: do you own xwing alliance ?
http://www.pcgamer.com/uk/2010/10/11/play-x-w … ou-should/#null

According to this page, ThrustMaster considered TOP GUN (non-USB) to be an FCS-type stick:

https://web.archive.org/web/19970607182208/ht … rt/fcs/help.htm

While the xwcoolie.exe file listed on this page doesn't seem to be available, a ZIP file is available here:

https://web.archive.org/web/19970117181122/ht … tils/xwcool.zip

And you can see more utilities on this page (including the above link):

https://web.archive.org/web/19970117181122/ht … echsup/util.htm

akula65 wrote:

According to this page, ThrustMaster considered TOP GUN (non-USB) to be an FCS-type stick: […]
Show full quote

According to this page, ThrustMaster considered TOP GUN (non-USB) to be an FCS-type stick:

https://web.archive.org/web/19970607182208/ht … rt/fcs/help.htm

While the xwcoolie.exe file listed on this page doesn't seem to be available, a ZIP file is available here:

https://web.archive.org/web/19970117181122/ht … tils/xwcool.zip

And you can see more utilities on this page (including the above link):

https://web.archive.org/web/19970117181122/ht … echsup/util.htm

COOOL!!! Thanks, that was exactly what I was looking for 😀 Just got my new MB in, so I can't test it right this second, but from my fuzzy memories, it seems right 😀 I'll eventually have to start finding the tools I used for my other flight games as well. But I'm going to worry about those on an "as needed" basis. Too many flight games to remember all the ones that needed little tools to use the extra buttons & hat. Now, I'm trying to remember if re-programing a button (mainly the pinky button,) changes it in game, or will it do both functions. Whatever I program it too "and" removing the cockpit display 😒 I just don't remember. I guess I'll find out once I get the new MB up and running.

Davros wrote:

X-Wing, TIE Fighter and Joystick hat switch support

ps: do you own xwing alliance ?
http://www.pcgamer.com/uk/2010/10/11/play-x-w … ou-should/#null

As a matter of fact, I think I just might have it around in a box somewhere. Back in the day I was grabbing everything X-Wing along with everything Wing Commander pretty much as soon as they hit the shelves. It's boxed up though, and I don't know if it's in one of the many I have with me, or one of the many that are currently in storage. Never was much of a fan of cross engine patching, though. A 3D patch like Tomb Raider uses is one thing, actually porting over to a new engine is something else. I might play around with it for fun, but probably not for long term use.

Well, that program XWCOOL doesn't work right 🙁 No matter what keys I program the hat to, it does the same thing. That is, right cycles through the different view modes (very quickly,) up sets view mode forward, left & down do nothing. Buttons 3 & 4 just do what they already do regardless of what I set them too.

I don't remember actually loading a program, I thought it was a patch. I could be wrong, I'm real big on writing batch files to do things like that for me.

Well, something is definitely up here 😒 After fighting with xwcool.exe and not getting any results, I wrote my own TSR. It took quite a bit of research, and I still have no idea how to "unload" it. I have to reboot between every re-write/test. Finally got it working (didn't worry about "blocking" it when X-Wing wasn't loaded - or making the "key" changeable - I'll do that later.) Load the program, and push on the coolie hat. The characters appear (like I had typed that key.) "Yay," I say 😀 Load up X-Wing, and only up and right work. Up does what I programmed, right does what I programmed into down. Exit the game and hit the coolie. Yep, the correct characters are appearing. Enter the game - hit the characters on the keyboard, they work right. Hit the coolie, again it's wrong.

Ok, so what's up?? Anyone have any idea what X-Wing could be doing to change how the Y-Axis on joystick 2 (what the coolie hat uses,) responds? I've tried everything I can think of to clean up how it works. At the DOS prompt it works perfectly. In X-Wing, it all changes 🙁

It might pay to consider the types of computer systems you used previously and what you are using now:

https://web.archive.org/web/19970607182208/ht … rt/fcs/help.htm (See hat switch troubleshooting)
https://web.archive.org/web/19970607183158/ht … rt/gameport.htm

Are you playing on the same machine you used years ago or is it a much faster machine now? Are you using a speed-controllable dedicated game port or a sound card? The fact that your TSR works at the command line but not in the program suggests a speed issue specific to X-Wing rather than a mechanical failure. It doesn't look like a patch for X-Wing exists that addresses this kind of problem:

https://web.archive.org/web/20000304015338/ht … tches/xwing.htm

It might pay to do some research and see if you can find one or more other games that are prone to this kind of speed sensitivity and see if you have comparable issues with your particular stick on your current system. Use the game demo if you don't own the game.

The only thing I could come up while sleeping on it is that X-Wing somehow changes the timing of the port. There are only 2 ways that I found to read the coolie hat on the Thrustmaster. 1 is to use the INT 15H 84H 0001H routine to get the joystick 2 Y-Position value (in DX.) Or to do a loop read of I/O port 201H, and measure how many loops pass before the joystick 2 Y-Position bit changes. Both of these are timing sensitive, obviously. On the Thrustmaster stick Up will have the lowest value and center the highest, with right, being the next lowest and left being the next highest (down being in the middle.) Now, if X-Wing is causing a delay of some sort during the read, then the lowest & highest are safe by the method I was using. It stands to reason that the second lowest gets delayed to become the middle, and evidently the middle and second highest get delayed to become equal to the highest. Only thing I can think of is to tweak the settings so that it reads correctly on my current machine. Which precludes the possibility of working for others 🙁 Unless I include detailed instructions and an easy to edit config file.... Giving that some thoughts. I'm also thinking of stepping away from a TSR and build a loader instead, so that it will unload itself after X-Wing (or another game) exits.

As for the system, no it isn't the same system. My old system was a P1 233Mhz and this is a P3 333Mhz (currently - underclocked because of PCI issues.) I have a replacement board on it's way, so everything is going to change in a few days. If I get it working right, though, I'll know what I need to do.

Well, got it working at last 😀 Still tweaking, and also researching a way to turn it into a COM file. Stepped away from a TSR, mainly because that's how I fixed it 😒 For some reason, works great as a loader, stops working as a TSR. Been trying to gets it's memory footprint down. Started at 65k of memory usage, got it down to 16k. Without making it a COM file (and TC3 refuses to make it one,) I can't think of a way to get it down any smaller. On the plus side, it will load high. It is also designed to work with other games as well. I'm fairly well convinced my old program was a loader as well (didn't write that one though.) I originally got it when there wasn't an internet. Got it off of an old BBS, so it may no longer be available anywhere. I seem to recall using it with other games (Wing Commander comes to mind,) but not 100% sure about that.

Well, I've tried everything I can think of. This is the best I can get it 🙁 It probably uses much the same methods as XWCOOL does, it just works as a loader instead of a TSR. On my system, that seems to make the difference on whether it will work or not. I'm posting it her in case any of you would like to test it out. Also, feel free to look at the code and help me find ways to make it smaller. 16K is a bit high IMHO, but I just cannot figure a way to make it any smaller. I've already reduced the stack & heap as much as I can. The heap was the big one, defaults to 64K, now only using 1K, the stack is changed to 1K from 4K. Loaded X-Wing (w/ I.P. + Patch and B-Wing installed,) and played for about an hour without issue.

Usage is very simple. The programs themselves do not have to be in the same directory as the game in question, as long as their in the path (or you type out the full path.) They do all their work in the current directory, so that needs to be whatever directory you are in when you start your game. First, run TMSetup.exe. That will let you chose the keys each hat direction will be mapped too. It will also run a calibration on the hat values for your system setup (if system changes, have to re-calibrate.) It will save all of this in the TMLoader.cfg file for the loader to use. Next you will run "tmloader <game> <args>" . I didn't get fancy, it will try to run the first entry and doesn't check if it's valid or anything (just fails if its invalid.) Everything past the first entry is considered to be arguments to be passed to the game. So, if you need arguments for the game you would put them there. Fore example, to load Monkey Island with VGA, Mouse, & Roland you would normally type "monkey v mo r". If you were to use this loader, you would type "tmloader monkey v mo r" instead. TMLoader will insert it's watch routine, programmed to emulate key presses when you use the hat, run the game, then sit and wait for you to exit the game. When you exit the game, it removes it's routine and exits.

I've tried the loader with X-Wing and with The Secret of Monkey Isle without any issues so far. I'm digging for more games to test it with 😀 Any help would be appreciated.

I know this is an old post, but I recently got a 486 and a Thrustmaster FCS and tried to use your loader. I'm getting a memory exception. I'm running Freedos, Jemm386 gives me error 06 and a long string of I guess hex numbers, memory addresses maybe. I didn't know if you had since updated your loader and fixed any bugs.

FeedingDragon wrote on 2014-09-23, 19:18:

Well, I've tried everything I can think of. This is the best I can get it 🙁 It probably uses much the same methods as XWCOOL does, it just works as a loader instead of a TSR. On my system, that seems to make the difference on whether it will work or not. I'm posting it her in case any of you would like to test it out. Also, feel free to look at the code and help me find ways to make it smaller. 16K is a bit high IMHO, but I just cannot figure a way to make it any smaller. I've already reduced the stack & heap as much as I can. The heap was the big one, defaults to 64K, now only using 1K, the stack is changed to 1K from 4K. Loaded X-Wing (w/ I.P. + Patch and B-Wing installed,) and played for about an hour without issue.

Usage is very simple. The programs themselves do not have to be in the same directory as the game in question, as long as their in the path (or you type out the full path.) They do all their work in the current directory, so that needs to be whatever directory you are in when you start your game. First, run TMSetup.exe. That will let you chose the keys each hat direction will be mapped too. It will also run a calibration on the hat values for your system setup (if system changes, have to re-calibrate.) It will save all of this in the TMLoader.cfg file for the loader to use. Next you will run "tmloader <game> <args>" . I didn't get fancy, it will try to run the first entry and doesn't check if it's valid or anything (just fails if its invalid.) Everything past the first entry is considered to be arguments to be passed to the game. So, if you need arguments for the game you would put them there. Fore example, to load Monkey Island with VGA, Mouse, & Roland you would normally type "monkey v mo r". If you were to use this loader, you would type "tmloader monkey v mo r" instead. TMLoader will insert it's watch routine, programmed to emulate key presses when you use the hat, run the game, then sit and wait for you to exit the game. When you exit the game, it removes it's routine and exits.

I've tried the loader with X-Wing and with The Secret of Monkey Isle without any issues so far. I'm digging for more games to test it with 😀 Any help would be appreciated.

I haven't done anything with it since shortly after the last post (2014.) I've since added a WCS to my setup, and have stopped using the this loader completely. As for your issue, I'd assume it would have to do with the differences between a 486 and Pentium, Freedos & MS-DOS, or EMM386 & JEMM386. I haven't worked with Freedos or JEMM, though I have worked with QEMM and the loader worked fine with that (IIRC.)

The only thing I can think of, off hand, is that the clock interupt is diiferent (just looked at my code again, had to download it.) My program expects the clock interupt to be vectored through $1C. So, if a 486 is vectored differently, or if Freedos or JEMM change it, this could cause the problem.

Well damn. I've a WCS Mark 2 and I'm struggling to get that to function. The program appears to download to the throttle, but then none of the buttons function. I don't know if it's a Freedos issue, or a problem with my throttle. The software attempts to put a line in the autoexec that (or maybe its config.sys) that redirects the whole OS to use a different directory for programs external to the kernel. I'm guessing it needs that to run, I can't tell for sure but it looks like it's trying to set what keyboard type is being used. There doesn't seem to be a memory resident program, and I wouldn't think it would need to have one since it's outputs through to the keyboard input on the computer.

Oh well, thanks for responding.

FeedingDragon wrote on 2023-02-05, 15:18:

I haven't done anything with it since shortly after the last post (2014.) I've since added a WCS to my setup, and have stopped using the this loader completely. As for your issue, I'd assume it would have to do with the differences between a 486 and Pentium, Freedos & MS-DOS, or EMM386 & JEMM386. I haven't worked with Freedos or JEMM, though I have worked with QEMM and the loader worked fine with that (IIRC.)

The only thing I can think of, off hand, is that the clock interupt is diiferent (just looked at my code again, had to download it.) My program expects the clock interupt to be vectored through $1C. So, if a 486 is vectored differently, or if Freedos or JEMM change it, this could cause the problem.