DescentBB

For those of you who have an interest in using the MS SideWinder 3D Pro in Win9x, I have some good news. I just got done playing some D3 with my 3D Pro on my 933 MHz Pentium III/133 MHZ FSB machine, I wasn't in an analog emulation mode, and I don't own one of Grendel's nifty converters. I selected the default control map for the SW 3D Pro, mapped the four base buttons, and everything works.

I won't dwell on the gory details, but I have determined where the timing values are in the Version 3.00.00 SW3DPRO.VXD that comes with the Version 3.02 SideWinder Software package. After some extensive trial and error, I found a set of substitute timing values that allow the driver to work on my Win98 SE machine described above. I still need to do some experimentation to guarantee that the values I am using are in the middle of the \"acceptable\" range to avoid timeouts and unwanted switches to analog mode, but it shouldn't take too long to do so.

My hope is to create an automated method for determining the correct timing values to substitute in the driver on a given machine and then have the automated process replace timing values as necessary. This may or may not be feasible. Part of the problem is that I don't have immediate access to anything faster than a 933 MHz PIII, so I would need some help from folks who are running Win9x on a variety of processor types (Intel, AMD, VIA, etc.) and at a variety of processor and bus speeds. In the worst case scenario, the timing may be so idiosyncratic that there is no way to come up with an algorithm to determine timing values. In that case, I hope to provide diagnostic and tuning tools similar to what I have been using, and folks will have to manually tune the SW3DPRO.VXD driver for each machine.

If you have a SW 3D Pro and you are getting the \"not connected\" message with the original Microsoft driver in Win9x (Win95, Win98, WinME) and you are willing to spend a little time in determining the proper timing values for your system, post in this thread or PM me. Thanks.

wow, great news, thanks a lot. Do you think the same would also work with XP?

Since this driver is a VXD driver, it is usable only on Win9x systems, so it cannot be used on Windows OSes based on the NT kernel (which would include WinXP). For NT-kernel OSes, you would need a WDM-compatible driver, like the one which Microsoft provided with WinXP. I have heard a lot of people say that the default WinXP driver does not work (\"not connected\"), but on my WinXP Pro system, it works fine. My WinXP Pro system is an 866 MHz Pentium III/133 MHz FSB system, so it would have been close to state-of-the-art at the time that WinXP was first released. I am guessing that all of the people who say the SW 3D Pro doesn't work on WinXP are using substantially faster CPUs and bus speeds, and that Microsoft still hadn't learned the lesson of using machine-dependent timing loops and timeout values. In other words, Microsoft made exactly the same error in creating the WinXP driver as they did when they created the SW3DPRO.VXD (it works on the current generation of machines, but increase the performance enough and the timing falls apart).

If that is the case, then it might be possible to do the same thing with the WinXP driver that I have done with the SW3DPRO.VXD driver. First, somebody would have to determine what file (probably a DLL) actually contains the driver. Then, the driver would have to be disassembled with a tool designed to operate on the same format as the DLL. VXDs use the Linear Executable (LE) format, but I would guess that WDM drivers probably use Portable Executable (PE) or maybe some other format. The disassembled driver would then have to be mapped and the timing values isolated.

One thing that might throw a monkey wrench in the works is the possibility that the OS or the driver itself does some sort of integrity check on the driver file. If that is the case, then you may not be able to alter the driver at all without causing an exception or an error.

I don't really know anything about WDM drivers or their format, so I really can't say whether this approach is feasible or not. The bottom line is that if you are interested in using recent incarnations of Windows, you should probably take advantage of Grendel's converter while you can.

I have a P4 running at 1.8 Ghz, with Win XP pro, and both the 3d pro and the PP work fine. Once in a great while looses calibration. How fast do you consider too fast?

The WinXP built-in WDM driver worked fine for my old non-USB Precision-Pro.

That said, I do have an old Win98 machine that I may hook up to, so this is good news; thank you!

WillyP, I would guess that (comparatively) slow P4s would work along with fast Pentium IIIs. A 1.8 GHz P4 would probably be borderline, so that may explain the occasional loss of calibration. I remember when P4s first came out that there was a lot of talk about the fact that slower-clocked P3s were actually competitive with P4s in some circumstances depending on code-optimization, etc.

Foil, what was the CPU type and speed and bus speed that you used with your Precision Pro? Was it comparable to the system WillyP described?

IIRC it depends on the FSB speed. > 133MHz and it becomes unstable. The P4 based (2.8G NW) comps I tried (200MHz FSB) had a hard time connecting to the 3DP w/ their build-in gameport until they reach operating temp (Don't ask. Took me a while to figure that out..)

The 3DPP, PP and FFP are less likely to have a problem like that since they are always in digital overdrive mode.

I think there are two problems w/ the drivers: 1. switching the 3DP into digital overdrive (needs some very accurate timing), 2. losing synchronisation to the sticks.

Also there may be a problem w/ correctly identifying a 3DPP/PP/FFP if the time constant of the game port hardware is too high (10nF caps vs 5.6nF or 4.7nF).

Edit: BTW, I think the article in the MSKB about a \"problem w/ static charge buildup\" in the sticks is BS (FUD or a red hering), I never saw a stick disconnecting from a converter on its own, even in dry carpeted environments.

Your problem #1 is something I pretty much had to address. The delay values that are hard-coded for the sequence of Start Digital commands in the SW3DPRO.VXD file don't correspond to the acceptable values that Microsoft specified in the patent application (at least the first one does not). The original driver uses values of 100, 845, and 410 as the delay times (microseconds). The first value is well below the 115 microsecond lower bound, and the only reason it works at all is because they used a 1.2X multiplier (fudge-factor, possibly for interrupt latency) for all timing values.

I ended up using the same delay values that Vojtech Pavlik used in his Linux driver, although I am not sure that we had the same motivation for using those specific values.

MS patent #5628686 defines them as:

When the INT0 input 134 returns to a high logic level, a second analog mode interrupt request 352 must be generated within a predetermined period of time t.sub.1, as shown in FIG. 9. In the presently preferred embodiment, the second analog mode interrupt request 352 must occur between 115 .mu.sec and 305 .mu.sec of the time at which the INT0 input 134 (see FIG. 3C) returned to a low logic level. If the second analog mode interrupt request 352 does not occur within this time frame, there is no valid Switch to Digital command and the second analog mode interrupt request is merely treated as another request for position data. If the second analog mode interrupt request 352 does occur within the required time frame, the microprocessor 124 records the precise time t.sub.1 and stores the time, designated as t.sub.v. When the INT0 input 134 returns to a high logic level, a third analog mode interrupt request 354 must be generated with a predetermined period of time t.sub.2. When the INT0 input 134 returns to a high logic level, a fourth analog mode interrupt request 356 must be generated within a predetermined period of time t.sub.3 as shown in FIG. 9. The time periods t.sub.1, t.sub.2 and t.sub.3 are all different time periods to prevent the accidental transition of the digital joystick 102 from the Analog Emulation Mode 302 to the Digital Transmission Mode 300 by computer software programs. As stated above, the time period t.sub.1 is designated as t.sub.V only if it is greater than 115 .mu.sec and less than 305 .mu.sec. The time periods t.sub.2 and t.sub.3 must satisfy the equations below:

t.sub.V+697 .mu.sec<t.sub.2<t.sub.V+755.mu.sec
t.sub.V+288 .mu.sec<t.sub.3<t.sub.V+312.mu.sec

such that all three time periods t.sub.1, t.sub.2, and t.sub.3 must be within specified ranges. If the four analog mode interrupt requests 350, 352, 354, and 356 do have the specified timing relationship, the digital joystick 102 switches from the Analog Emulation Mode 302 (see FIG. 4) to the Digital Transmission Mode 300. Thus, the system 100 can effectively send commands to the digital joystick 102 in either the Digital Transmission Mode 300 or the Analog Emulation Mode 302 (see FIG. 4).

100us as t1 is too tight, maybe that's the problem.

I use t1=140us, t2=140+725us, t3=140+300us.

Edit: heh, was skimming again. Obviousely you read the patent

In general using the lower bound values is prefered since it gives you leeway to compensate for \"slow\" gameports. 100us + charge until INT0 is asserted on a \"fast\" gameport is probably > 115us. Not sure how fast build-in gameports from a couple years ago are tho, may be too fast to reach the 115us.

I have put together a small package of SW3DPRO.VXD drivers that should span a very wide range of performance. I was able to find at least one driver in the package that worked for all three of the Win9x machines that are available to me, and performance up to several GHz should be supported.

File info on the ZIP archive (sw3dp10.zip) is as follows:
260320 bytes
md5: 60d5b0496fdf8ee332da0353355d817f
sha1: 0b75dcf6c0066d01fdc0bfab5cb90960c4a90730

PM me an address if you are interested in trying it out.

akula65,

When I was directed to your posting by a comrade of mine, I got very excited. Here's the deal. I have a P4 2.8GHz w/800 FSB on an Asrock P4S61 mobo, SB Live! 5.1, x800GTO AGP, etc. I also have an AMD 1800+ 1.533 GHz @ 266FSB on an Asus A7M266 mobo using on-board sound, LAN with a Geforce 4 4400 AGP card. Both of these systems work in Windows XP with the Sidewinder 3D Pro. The first system refused to work using the SB Live!'s gameport, but when I used the on-board gameport (mobo) it worked just fine! Same with the second system. The on-board gameport works just fine. Here's my problem:

I have a P3 733 MHz PC on a Gigabyte ga-6vxc7-4x, Soundblaster Vibra 16 ISA CT2260 sound card, PCI NIC, PC133 memory and a Rage Ultra 128 video card, etc. I use this PC for classic DOS gaming and am dual booting DOS 6.22 and Windows 98 SE. In Windows 98 SE, I have tried many different gameport drivers, the different Sideiwnder drivers from MS, unplugging and plugigng in the joy multiple times (static), removing the \"OEMCALL\" value in the registry (http://www.koolbear.com/Descent/Faqs/MS ... repair.htm), etc. with no luck. If I setup the joy as a 2 axis, 4 button joy, it works just fine, but then I can't use the other 4 buttons and I am sure it's in analog mode. Funny thing is that I had the sidewinder working on a 98 SE machine (850MHz AMD Athlon, PC100 RAM, Vibra 16 PNP ISA sound card - dif from above) and the same, other specs as the P3 above. Now, it refuses to work on this slower P3. I PM'd you. Please let me know what assistance you can lend. I'd be happy to help you test!

D

I posted the modified drivers at VOGONS:

http://vogons.zetafleet.com/viewtopic.php?t=17941

Feedback is welcome.

I PM'd you! Great work!!