I have been working a while in an attempt to put Force Feedback into my FFP with this adapter in Windows 7. My primary goal is to get sufficient FFB support to play at least the effects in IL2 (for which I now have to dual boot to XP to get the FFB). I have the 3DPVert working very nicely on a Tweeny now as a non-FFB joystick in Windows 7 (thank you!).

Secondary goal is to retire my separate self-made ATmega168-based USB-joystick and move the controllers under the 3DPVert, so I can have joystick and my home made rudder pedals and elevator and rudder trim potentiometers to a single device under Windows instead of two separate ones. Less boxes on the table and less problems with joystick IDs changing every now and then when having multiple devices. I think this should be quite a simple task of adding ADC, HID descriptors and report buildup - but FFB interests me more since I do not have it working in Win7.

I know what Grendel said earlier about not having FFB due too much work to reverse engineer the MIDI protocol etc.. I think it is time for others to continue where Grendel brought us!

I've studied some of the USB specs on FFB a bit and there does not seem to be any major showstoppers at least for the level of FFB support I'm planning. I've found a few examples on such HID descriptors on other forums. IL2 default FFB effects seem to contain only a spring, periodical and constant effects with some envelopes. And if it comes to that, I could easily modify the IL2's FFB effects for simpler ones with FEdit. But, before going there, I want a proof of concept on getting the stick to answer to FFB data in general while being connected via 3DPVert.

At the moment I have decoded most of the MIDI protocol essentials by tapping into the Joystick's pin 12 with a Tweeny's USART listening the traffic to the Joystick while using FEdit in XP and having the stick in the game port. I soldered the GND+MIDI pins out of the stick on a separate connector to get easy access to the MIDI channel. I can make this information public if someone's interested - latest if and when I can see this thing flying (other than out of the window, that is). It's not that complex protocol after all at least on the basics.

I even succeeded in modifying the 3DPVert code to move the Button4 to another pin so that Tweeny's USART TX-pin would be free - for sending MIDI data to the stick. So, next step was to start pushing some FFB data to the stick.

Now, here's where I've hit the wall. The stick does not respond to the FFB data I'm sending to it. It is like it doesn't even want to hear anything from the pin 12. Even the initialization routine FEdit does that disables the auto-centering spring does nothing. After reviewing several MIDI circuits, it sounds that AVR should be able to drive the MIDI directly from the TX-pin (with a protective 220ohm resistor in series for added safety - tried a few alternative circuits but with no better results). I've recorded the basic data being sent to the stick from FEdit and try to repeat that. (I first attempted to send it directly from the 3DPVert's TX-pin, but couldn't for some reason to make it send anything so I put another Tweeny connected only to the stick's pin 12 that is capable of sending data - I checked that it does by reading what it sends and it looks fine.)

Here's the question:Grendel (or anyone else more familiar with the 3DPVert's code and the FFP stick), can you tell if the FFB has somehow been "disabled" (or not "enabled) in a way that the 3DPVert handshakes with the stick? Could it be that the way 3DPVert initializes the stick, the stick is in some kind of "wrong mode"?

There is still one confirmation test I should run to check which direction the problem lies, but it involves opening up the stick again and cutting its MIDI wire to disconnect it from the game port altogether and getting the Tweeny in between - so I could connect the stick to game port while having full electrical control on the MIDI wire. The far shot, simply connecting the Tweeny's TX-pin in parallel with the game port's pin 12 didn't work - as expected...

(I have a masters on EE and work as a professional programmer with years of hobby time on both areas. So, if you have ideas on any level - let me hear it. I think I can take even the nasty technical details - and if not, I'll learn to get it.)

Today I had the exact same idea!
I really would like to revive my FFB! This thing is an amazing thing of HW and it would be very nice, to play the latest games with it...
I would really like to help you as best I can... So if you don't mind you could share your findings as detailed as possible. At first I would like to build kind of an adapter so I can plug in the joystick while having the MIDI RX pin connected to an oscillator.
Something that might work (but I doubt it): writing a nice mail to Microsoft an ask for some documentation on the protocol for the FF part...http://answers.microsoft.com/en-us/wind ... b599b31bf5 Someone had the same question some time ago, but if we keep posting, perhaps something will happen =) ?
Oh and btw: I am also an EE from Germany...

I don't have a definitive answer, sorry. My guess would be that the FF interface is isolated from the OverDrive protocol (since FF was added later), all FF related actions are probably driven via MIDI channel 6. What exactly makes up these commands I don't know and would be subject to reverse engineering. Another place to look are older DirectX/DirectInput SDKs, chances are there are some notes about it. As for the USB side of things, check out the document "Device Class Definition for Physical Interface Devices (PID)" V1 (pid1_01.pdf, should be inside this archive.)

I did revive that thread on MS Answers, I'd suggest that everyone interested in this posts there as well

Some progress, but still a critical bit is missing to go forward. I cut the MIDI-wire on the joystick and took both end out of it, so that I can have the stick on actual game port and still have full control on the MIDI-line to the stick with a Teensy.

I can now consistently control the effects on the joystick with a Teensy. There seemed to be some timing related issues i.e. that after certain commands, the joystick needs to be given a bit time to process them. I can start and stop a few pre-recorded effects and disable and enable the auto-center spring effect on the stick.

The problem still is that I need to get the stick "in the mood" to get my MIDI-commands. With the 3DPVert, the stick is NOT "in the mood". Actually, the stick is not "on the mood" by default even when it is connected to a real game port.

When connected to a real game port, opening FEdit in XP seems to do the trick. After that I can send commands and the joystick replies as expected. If I issue a command to re-enable the default auto-center spring effect as of going "out of application scope" I have to restart FEdit to put the stick back to the "mood" to receive commands.

The funny thing is that FEdit (or any application using FFB) can put the stick to the mood even if the MIDI-wire is completely disconnected. Which means, that the game port is talking to the stick also on FFB-related matters (at least this "mood switch") using the conventional pins instead of MIDI.

I believe this test confirms my earlier hunch, that the joystick is in a wrong "mode" and that's why it doesn't take the FFB commands in.

Does anyone have tools or know-how at hand to analyze what happens in the game port outside the MIDI-pin when you start FEdit or other FFB-using apps?

I think there is something previously unnoticed or overlooked that would provide the key to enabling FFB with 3DPVert.

After reading the MS patent description about bidirectional data transfer mechanism used between the game port and joystick, I am making a guess that the "Go to FFB Mode"-command I'm missing is one of the commands sent to the joystick using the "interrupts" in the Overdrive protocol.

If I understood the patent description correctly, there is only a limited number of commands that can be sent this way and since "SendData", "SendID", "Go to Analog Mode", "Go to Digital Mode" etc. already taking most of the options, there is quite a small number of "command codes" left to try.

Grendel, is it in the QueryFFP-function (written in asm) that the "kick" is the "interrupt" signal sent to the joystick and that the current code only implements the commands 1 and 2 (SendData and SendID i.e. commands with 1 and 2 interrupts total)? And maybe calling the QueryFFP-function differently (more than once/twice with the negative timing parameter?) or modifying it one could implement sending of the other commands too using the interrupts?

Since I cannot easily put the Tweeny completely in between the game port and joystick, and since there seem to be only quite finite number of commands towards the joystick possible, I was thinking of simply modifying the 3DPVert to try out a few commands and see if they trigger the missed "FFB mode" in the FFP. Or have I completely misunderstood the mechanism how "game port" can control the joystick?

There is really only one "command" -- the stick detects the initiation of the analog query. When idle the capacitors are fully carged. The 1st step in a query is to discharge them to have the caps recarged from the stick. The SideWinder sticks detect the low-high carging transition and interpret this as a command. On a 3DPro you have to issue a timed sequence of commands to switch it over into digital mode. In digital mode each command will cause the stick to transfer its values using the button lines as a serial interface (clock on B1, data on B2-3) Another command during the transfer will cause ID data to be sent immediately after the position information. Another command while transfering the ID data will sent a 3DPro back to analog mode. The FFP doesn't have an analog emulation mode so it's never send any special sequence from the 3DP-Vert.

I doubt that there is a special OverDrive sequence necessary to enable FF. I'm fairly sure it's all in the MIDI commands. For verification tho you could hook up a scope on the X1 axis line and monitor the signal during enumeration.

It is not all MIDI. I repeated the above-mentioned test and got the same result. The stick consistently goes into some "FFB mode" even when I have MIDI pin disconnected between the stick and game port when I startup FEdit. And only after that I can feed it the MIDI data so that the stick actually executes the given effects.

I even shorted the MIDI pin from the game port to ground (with a small resistor for safety) to prevent any crosstalk. And thus, I'm quite confident that the stick is not getting anything thru to the stick's MIDI input from game port and it still switches its mode. There is even a slight, but immediate and recognizable change in how the stick's auto-center-spring behaves right after starting FEdit (which also notices that it was not able to disable the auto-center-spring - as if game port would somehow also get feedback of the mode switch).

I don't have a scope. So, if anyone with one could see what's happening in the axis/button pins at the moment of an FFB-using application starts up and sets the stick to the "FFB mode".

Maybe, I could try to listen these pins with AVR with digital inputs (ADC is supposedly too slow for this) and high valued resistors (in attempt not to interfere to the signalling too much). Just that this would take much more time in order to get all of these pins wired out of the stick to the breadboard. Also, I'm still not 100% sure what kind of sequences I should be seeing in which pin.

BTW, Grendel, you mentioned about reviving a thread in "MS Answers". Don't know where that is - couldn't find a thread here with such a string. Some other forum?

Also, I finally got the time to write a short text document about the MIDI protocol decoded this far in somewhat readable format. Is this thread a place to post it or would you as moderator here prefer some other site/thread/forum? I'm not quite sure of the role of this particular forum for this type of "in the development"-kind of information.

There is already a preliminary Sidewinder MIDI description in the project's wiki page and an simple Arduino-based (USB-to-serial based) tool for sniffing and controlling the MIDI channel.

About the code then to convert the USB and MIDI data, I'm sure it can be done in C in a way that it compiles and works pretty much as such despite the mcu-platform. A simple interface that can be easily adapted to any other project like 3DPVert.

- the 1st pulse is probably to initial reading the stick to check if something is connceted
- following this should be a "read ID" sequence (pulse to start transmitting data, followed by a pulse while the data is still transmitting.) to determine that a FFP is indeed connected
- the 1-4-3 pulses block is probably it (initial read, ID read, switch to FF mode sequence)
- the "enable FF" sequence will have fairly tight timings measured in micro-seconds (less than 1ms pauses)
- the "enable FF" sequence is probably executed before the 1st MIDI command is send
- the overall sequence could also be: read, switch to FF, read ID (last two swapped, would allow for FF enable verification)
- or read, read ID, enable FF, read ID.
- pulses sent later are just initiating the transmission of the joysticks position data

The "enable FF" sequence could be similar to the "set digital mode" of a 3D Pro, which looks like (see Init3DPro() in 3DPro.c) :

pulse, wait 140us, pulse, wait 865us, pulse, wait 440us, pulse

May be worthwhile to modify the 3DP-Vert code to send that sequence after a FFP stick is detected (very easy modification.) MS may have reused the firmware from the 3D Pro...

The sequence to get out of analog mode is: pulse, pulse while data is transfered (will initiate ID packet transfer), pulse while ID data is transfered. Most likely this would also be the sequence to disable FF mode again (actually, this could also be the sequence to enter FF mode !)

Dang, you really need to monitor B1-4 along w/ X1 to get the whole picture

Yep, I had the same day dream; using the 3DP's "set ditial mode" sequence after the FFP had been detected to see if it is "enable FFB" sequence on FFP (even removed the 3DP parts in the initialization sequence to make sure they won't interfere), but no - it was only a dream.

I also tried to replicate the sequence game port sends just to see if it would be that simple. Again, the second day dream was harassed by the harsh reality. Maybe I wasn't accurate enough on the timings (there were a few micro second differences here and there), but looks like there is more to it. All what was accomplished that I got the stick into a mode that almost any MIDI command made the FFP "crash" and disappear from the scene and recover only with a complete cold boot.

So, I'll next need to dispatch more wires out of the stick (5 more, buttons and X2) and extend the tester tool to take all those in. This will take a few days to get a time slot for it.

BTW, do you know how the X1 and X2 lines (sometimes incorrectly referred as Y2 in the code comments) differ from their usage in the communication to the stick? The 3DPVert (and seemingly the kernel driver too) always uses both the same way (pull both, release both). Or did I miss some place?

And when going into more timing details, do you know if the width of the pulse matters or only the delay between the pulses? Real game port seems to use pulse widths of 220us and 290us (always the last pulse in series of more than one pulses) and the delay width is 200us.

There are more possibilities -- the 3D Pro by default will only send data on B1 and B2. This allows to hook up two 3D Pros to a single gameport via a Y-cable. In order to use all 4 button lines for data transfer the 3D Pro needs the pulses on X1 and Y2 at the same time (the code comments are correct ! ). The FFP will only get the X1 pulses from a 3DP-Vert -- try moving the Y2 connection to X2, maybe that's all that's needed for FF mode...

A gameport will always pulse X1/2 and Y1/2 at the same time. The 3D Pro uses the presence of Y2 as an indication of being connected to a "full" gameport (two analog interfaces.) I don't know what the FFP does w/ the absence of X2.

Pulse lenghts are not important, voltage levels are. 50us on the Teensy w/ the 1k/1nF combo work reliably.

Ok, made the tester to print also buttons and X2-line values. Got some nice data out. It is still raw data, but since I have already well exceeded my time slot for doing this for now and pay for it tomorrow. I'll just leave the data for others to view if you could find anything on it.

X2 seemed to change value too. And now that you mentioned about it, indeed the 3DPVert is connected to DB15 pin 13 (Y2), which is not connected to FFP. Instead DB15 pin 11 (X2) is. I hope it would not be that simple after all the... well, actually I do hope it would be that simple.

EDIT: Actually, it cannot be that simple as moving the cable from Y2 to X2 pin since even with a real game port, the FFB mode is not enabled by default, but first needs to be enabled with the sequences now under scrutiny.

EDIT 2: Indeed, the pulsing in X2 is not same as in X1. And looks like not all of it matters at least for normal positional data reading since 3DPVert works with FFP even when the X2 is not connected. Normal "Read" command for FFP includes pulsing the X2 line once too. Game port does it with about 400us pulse instead of X1 line's much shorter 230us pulse. In setup command sequence "1-4-3-2", all commands include X2 line pulsing (with pulse counts of "1-2-2-1" respectively with longer pulse widths and delays). X2 pulsing is not present in other commands. The 4-pulse command returns roughly 60 clocks of data to PC and the 2-pulse command about the same. Details update to the project wiki page above.

- the FFP data packet is 16 clocks in size, the ID packet 14. This results in a 30 clock "big" packet for ID reads. Looks like you are counting each clock phase twice or the stick actually sends everything twice (would make sense for 2 and 4 pulse sequences).
- the X1/X2 pulse widths are defined by the R/C values in the game port circuitry and the resistor value to 5V inside the FFP. I would expect these to be fixed.
- the offset betw. X1/X2 start should be fixed too, it results from the differnt rising slopes. Ie. the shorter pulse will hit the logic "1" value earlier.
- the interesting numbers are the times between the start of pulses.
- I'm not sure reading X1/X2 digitally gives the whole picture. The "missing" pulses on X2 eg. are most likely "restarts", causing reading a long pulse instaed of two (see also PC analogue joystick interface). 290us is well w/ the data packet transaction period (100us + 16 * 10us). So every time you see a long X2, the software issued a pulse close to the end of reading a data packet (I call that "kick" in the 3DP-Vert code) to either read the ID, or issuing a timed sequence. You could miss X1 pulses as well. For clarity you can ignore the X2 line (should always follow X1.)

I got one of these. I may be able to find a XP machine w/ a gameport (and the power supplies involved... ). What exactly do I have to do to get FF to work ? Where can I d/l the FF software ? (Got my FFP from Goodwill...)

Long time nothing done. Civil life and work getting a bit in the way of the hobby now.

I added links to the related information section of the project under subtitle Tools for Force Feedback in Windows for getting the FEdit application. It is part of DirectX 9.0 SDK (not the latest tho anymore). Install the SDK to get the FEdit-application.

You need to run Windows XP (latest SP is fine) - it has the built-in drivers for the old game port sidewinder joysticks. To install your controller in XP:
* Plug it in, click Start -> Control Panel (Switch to Classic view if you haven't already) -> click Game Controllers
* Click Add... -> Select Microsoft Sidewinder Auto Detect -> OK -> OK.

On older Windows, you need to install Sidewinder 3D drivers first - downloadable from Microsoft as a single executable.

Once installed and having your stick detected (should display "Microsoft SideWinder Force FeedBack Pro" and status "OK" in Game Controllers- control panel) you are ready to go.

Locate FEdit.exe from the SDK directories and run it. If you don't have any pre-made FFB effect files (with .ffe-suffix), you can easily create effects of your own in FEdit e.g. create a constant force and "Play" it and you should have the stick to react. You also need to actually have the FFP's power brick connected and your hand on the stick, since FFP has proximity check to see if you are really holding it or not. The stick does not move if you do not hold the stick. The stick however does take all FFB commands in fine even when not holding it.

As mentioned in earlier posts, already starting up FEdit, the stick is enumerated and FFB-mode enabled. You can then even quit FEdit and start pushing MIDI-data to the stick to make it react. The interesting part here is what happens when FEdit is started up.

Of course, if you don't want to use FEdit, any game or other application generating FFB-effects would do the same.

----

I know the digital view of the situation if not really giving all information especially with this archaic circuitry. A lot of educated guesswork on electric properties - and sheer luck - is also needed. The article on analog joystick interface was very useful on educating the guesswork, thanks.

EDIT: I tested, whether the X2-line has any real effect by shorting it permanently to ground (with 220 ohm resistor, which should be sufficient to keep the voltage level down) on real game port. The FFB-mode was still successfully enabled so I believe we can indeed forget the X2-line altogether.

Thanks, I'll see what I can do -- I do have access to a decent scope at work, looking at X1 and B1 (clock) should be sufficient to analyze the timings for the sequence to enable FF mode. Give me some time tho, busy as well... :/

Note on the grip sensor -- it's a photoelectric sensor, taping one of the holes w/ electrical or duct tape should free up one hand

Made it. I have now a version of 3DPVert that enables the FFB mode (and disables the auto-center spring). For testing purposes it also now, when pulling one joystick button plays a constant force effect and pressing another button it pauses the effect. It uses UART (pin D3) to send the MIDI data (which required remapping the button lines in an ugly way...).

The startup sequence indeed is the full set of pulse sets; 1-4-3-2-2-3-2 and then sending the MIDI commands.

Delays for sending the MIDI commands are as previously noted in the project wiki. Delays between the pulse sets that I use now and seem to work are: 7, 35, 14, 78, 3.3 and 59 ms respectively. The MIDI data can be sent immediately after the very last two-pulse command.

Using pulses with widths of 50us and 150us delay in between end of previous and start of the next one seems to work. These might not be the optimal in terms of reliability, but seem to work for now.

I'll update the project wiki soon to include the above information. Maybe I should post the (severely mutilated) source code of the 3DPVert version with prototype FFB there too just that everyone can start testing it. But that will have to wait until at least tomorrow since its already 3am and the kids need to be put to school and - stuff. The critical info is already above anyway.

The next step would be to work on the USB HID for FFB and more detailed analysis on the MIDI data to enable mapping of USB output reports to MIDI data packages.

I think I'll put the buttons to pins B0..B3 since D5 in Tweeny is in a bad location for breadboard constructs and the led is on D6. And sure, have that B0 and D0 connected for the INT0. Also, D1 and D2 would still be left free for INT1 and INT2 e.g. if someone wants to add pulse counters for digital pots or something.

I'll leave the F-port free since later, I'm planning to put those ADC pins into use for rudders, elevator trim and rudder trim pots (and get rid of my separate box for them with ATmega168 doing that with the software USB). Darn, there even room for analog flaps and if I completely loose it, for additional throttles for those four engine planes and... (calm down... clam now... deep breaths...)

I got the pins changed now to B0..B3 and the code seems to work fine.I do have a couple of Teensy++s set aside for another project waiting in the queue, but there's plenty of room as a pin count as well as in free memory in the smaller Teensy still.

But, as I feared on the reliability, after the wiring changes - possibly coincidentally - the reliability of the FFB mode enabling really suffered. It fails 9 out of 10 times now where it used to succeed with that ratio before. It is a breadboard setup so rogue capacitance and loose pinholes could easily change these things a lot without any visible queues. Also, the temporary wires hanging out of the stick used for snooping the game port traffic are likely to pick up all kinds of disturbances. After I had added them earlier, reliability even with a real game port was slightly affected already.

I need to check if changing the pulse timing settings of 50us/150us to one or the other direction would bring more reliability into it. I'll get back on this hopefully in a couple of days.

EDIT: Ok, reliability is back after twiddling with the wires a bit. The above timings seem to be fine and the unreliability came from the wiring.

The next problem. Now it is in the 3DP-Vert's USB-code. It limits the HID descriptor to 256 bytes while minimal FFB descriptor part already seems to be over 500 bytes (I've seen descriptors of over 1200 bytes long too).

In the code, the limit comes at least from most length variables being uint8_t. I changed these length variables to uint16_t in the obvious places and checked that everything still works as before. To test for the limit again, I started adding more buttons to get bigger HID descriptor (and extended the report size) and again checking that it still works (i.e. I can see more buttons in the Game Controller panel correctly). But, I still keep hitting the 256 descriptor size limit. So, there is something else than mere data types that brings the limit, but I cannot see what it is.

I changed the length/count variable data types in main(), and parameters for functions usb_send_EP0(), and lookup() (and even usb_send_IN() even tho it seems to be used only to send the report data, whose length is still within 256 bytes . I also modified the struct descriptor_list_t to have uint16_t for length for the descriptor.

I also tried to see a way to add that OUT end point to the USB for the FFB data and I'm almost thinking already of trying to port the 3DP-Vert to use LUFA to handle the USB side. It should solve the HID descriptor length issue too. Just that I have no previous hands-on experience with LUFA, but they say it should be easy to use.

Yeah, the USB code is highly optimized and simplyfied. I probably wouldn't use it for this project too. LUFA seems a reasonable option since it does come w/ a Joystick reference. Atmel's reference code is another option, I would suggest to stay away from it tho (last time I used it I found multiple errors in it.) Both USB stacks will give you a full chapter 9 implementation but in return will eat up more resources.

Lots of work, very little progress. Before actually porting the 3DPVert to LUFA, I tried to get the simplest FFB Joystick made with it to see how the USB, LUFA and Windows build-in USB PID driver works.

I'm posting this to indicate that I'm still working on this and to ask for help on the USB part. If you cannot help, please spread the word if you know someone who has worked on the topic. So, please let me know if anyone knows a working sample on any kind of force feedback HID device that works with built-in Windows USB PID drivers.

If I don't get the PID approach working in due time, I'll consider looking at MS samples from their SDKs for building a mini-driver to map DirectInput data already in the PC side to avoid the Windows PID driver issues. This also seems to be the most common approach by the commercial joystick manufacturers.

I started out from a basic LUFA (the latest beta due it having new features needed here) joystick samples and got them working fine on Teensy after some trivial modifications. Then experimented adding a few FFB descriptors found on the forums (links in project wiki). I keep hitting the same wall people around the net have been i.e. getting any force feedback HID working using the built-in USB PID driver in Windows. Many have said they finally solved it but never actually posted the final methods.

The closest I've come is a joystick that gets enumerated as FFB device after manually modifying some OEMForceFeedback-registry values and keys in Windows (thanks to ulao's experiments on this on a Microchip forum). Yes, manually since the HIDs I've used are likely to miss some axis-binding or something and Windows does not automatically detect the stick's features correctly. So, I did get some data to the device from PC during enumeration when starting FEdit. However, the data did not meet the expectations (i.e. as defined by HID descriptor) of the content and seemed more like garbage - even it's length was off by a couple of bytes.

Been reading USB HID specs and samples more than I really bargained for, but getting better at it. Even tried to work with the USB.org's sample but it has other complexities that seem to give trouble (custom force specs and tons of different report IDs). Also, the whole PID HID descriptor seem to be very picky on anything being missing or even slightly wrong resulting in Windows rejecting the whole device.

UPDATE: Ok, after bumping into a few discussions on LUFA compiler warnings, I ended up updating my WINAVR to the latest and found some compiler options in LUFA to allow for larger HID descriptors with more reports, collections and stack size. The defaults were too small. These made the critical difference and I can now get clear and understandable output reports from PC to the joystick using a "minimal FFB" descriptor found on the forums. The descriptor has its issues (requires manual registry manipulation at install time, no axis-binding for force direction etc.), but I'm now more confident on moving on to attempt on the full blown descriptor from USB.org's samples. Actually, even with the current descriptor, I could already move along with the LUFA port and having the test effects being played by Windows instead of by the adapter itself on hard coded joystick button bindings. I thought I was going mad and sad, but now there is hope again!

That would be more than interesting. Last night, I got the USB.org's sample PID HID working (enumerates and I get sensible FFB data to the stick) with LUFA, but even with that HID, the OEMForceFeedback-registry key's values for Effects lack the binding to the X-Y-axis and I need to manually modify the entries (enable two bits in the Attributes-value that bind X and Y axis to the effect respectively) in order for the joystick to be considered as FFB device. I also need to figure out what response messages I need to give back to PC to certain FFB-commands the stick receives to give proper feedback on creating an effect.

It could be possible that the FFP2's HID and protocol might give some insight on the latter topic. Altho, I am afraid that FFP2 is actually working via MS's custom drivers for Sidewinders instead of using the standard PID HID-driver. Thus, its HID descriptor might not help that much.

On the other hand, if the standard PID approach doesn't work well, it might be possible (or even easier) to mimic FFP2 with the 3DPVert and use its drivers and protocol for FFP-adaptation. I understood that feature-wise, FFP2 and FFP are very similar (same buttons, axis and effects). Do you know if force feedback works also in 64-bit Windows 7 with FFP2 - meaning that the drivers are still maintained?

I own a SideWinder Force-Feedback 2 and can confirm that not only does it work on Vista/Win7 64-bit, but that force-feedback does indeed work in every game I know that has it, even with nothing more than the bare-bone drivers already present in Vista/Win7 64-bit. Good thing all of them allow in-game configuration of the FFB, too, because the drivers sure don't!

It also has a very tight centering force with practically no center play, but the centering forces are also gradual and ramp up more as you move away from center, unlike the Logitech WingMan Strike Force 3D I've tried. No wonder the SWFFB2 has the cult following that it does in the flight sim community over a decade after its release and discontinuation...it's not just a FFB stick, but a FFB stick with well-implemented forces.

However, low-level driver work and descriptor sniffing is beyond my league. I'll have to leave that to Grendel.

That's comforting to know, that the plan B of using FFP2's USB protocol is at least possible in Win7 64bit. Hopefully tho, we can get the PID driver would work for it. That way it would also allow extensions (like those extra sliders for e.g. elevator/rudder trims in IL2). FFP2's custom driver (if it uses one) might not allow for such extensions.

Crivens! It really looks like it is using the PID driver in there instead of a custom one. At least all the PID-related report descriptors are there and looking very familiar. Compared to the USB.org's sample PID HID it is slightly larger (offers a couple of more effect types and some PID states etc.). I'll need to compare these two now and see what is wrong with the USB.org's sample as to why it is not automatically (without RegEdit-magic that is) recognized as a FFB device. On the other hand, the Sidewinder's seem to come with registry keys for FFB from the .inf-files so, in the end, it might be possible that this 3DPVert+FFB might need a simple .inf-file too to make it fully functional. Well have to see. It could still be a problem in descriptor I'm using or the answers I'm giving (which is none now) when the device is first plugged-in to PC and Windows starts to look drivers for it.

Indeed, as you noticed, these PID descriptors tend to get huge and I have only started to understand something on why much of the stuff is there (well, not really understand "why" but at least I can see how it brings more information about the effects protocol).

On the side note; I just got the 3DPVert ported to LUFA and have included a working "enable FFB mode" command there too at startup. I'm still sorting the code a little bit to isolate your original 3DPVert code since you are distributing it with a bit more restrictive license than what I have in store for the FFB code (going out in MIT license to make it simple). This first port however is strictly for FFP and Teensy 2 (I severely amputated it from many of the other parts) since the other sticks have no FFB and at this point I wanted to simplify the prototyping by having as little of moving parts as possible. I'll also have some extra inputs in it to allow additional buttons and potentiometers to be plugged in. It should be quite a simple matter to include the amputated parts back in once the whole thing works together. I'll upload it into the site in a day or two and we are finally approaching the position where I hoped to be in the very early stages of the project

Here's the report descriptors with descriptive texts in place of the "undefined"s. Biggest differences seem to be in the memory management reports and effect indexing mechanism. FF2 also seems to support more force feedback features than FFP (e.g. non-zero phase in periodic effects and startup delay for an effect). So, Microsoft did some other under-the-hood improvements too to the FF2 than just the form factor and USB connectivity.

I would not be surprised to see that the Windows' PID driver is actually made for the FF2 features in mind and it might be required to adhere to that subset and ways of usages its descriptor has...

Finally, I managed to get some actual code published (please, notify me if the credits in the code are not as you would like them to be).

The project site now contains source code and hex file for the prototype version 1 in the downloads-section. It combines 3DPVert, LUFA (for USB comms) and code to enable FFP's "force feedback"-mode at startup. The HID descriptor has also a few additional controls for extra controls.

3DPVert code in this prototype has been stripped to only contain FFP-related code for simplicity.

To see the device as FFB device (e.g. in FEdit or a game) you need to do the registry magic mentioned in the project wiki-page. The code outputs all force feedback data it gets from the host to its USART TX port so it can be viewed with a device reading serial data.

The FF2 descriptor made the real difference in finding out what the WIndows PID driver really accepts. I've done full scale testing with FEdit, FConst and some preliminary testing with IL2 game too. With FEdit, I can play effects mostly fine. In IL2, there are some weird glitches and issues in the effects making it not really playable yet, but I consider this level of achievement as a proper proof of concept

Also, no need for that registry magic anymore - plug the joystick in and Windows will automatically generate correct OEM/FFB registry entries it likes to have. The decisive factor was the FF2 descriptors and that I needed to report a correct PID state reports when requested. None of which seem to be documented anywhere in sufficient detail - as you might guess. The FF2 descriptor also has several features not really supported by FFP (like phase or offset of periodic forces).

Creating effects, playing and stopping them work. The Windows USB-protocol implementation did (surprise surprise) not actually match the one described in USB.org's documents, but had some shortcuts that caused some pulling of hair (or what's left of it) at a time.

Almost all effect types now work when played using e.g. FEdit; constant effect, sine, triangle, square, spring, friction, inertia almost as much as FFP can support them. There were lots of nasty number format conversions and FFP limitations to stumble into. Ramps are not fully working yet - FFP also has very strict limits on what kind of ramps it actually can perform (only rampup from MIN to MAX or rampdown from MAX to MIN - nothing in between).

FFP can play up to 10 effects simultaneously even tho it can hold 40 definitions in its memory. Both properties are now taken into account. The adapter now needs to keep all 40 definitions in memory (taking a lot of RAM) since USB data updates are not always sent to MIDI immediately and need to be cached in the adapter. Some optimization could be done but ATmega32U4 can just take it all already now.

Most on-fly updates to already playing effects are also now working. E.g. changing direction or magnitude of a force already playing work. There are some limitations in FFP as it does allow changing e.g. magnitude of already playing constant force, but not periodic forces.

All that after tens of hours of tedious trial and error, half-educated guesses and even a few reboots due blue-screens in XP. Windows 7 64-bit works too.

FFB also seem to affect the joystick position reports by making some of the values jump erratically every now and then. I remember seeing some button line activity when playing effects - possibly it reports to PC whether an effect is playing or not or something like that. At the moment, I just ignore all that data, but it might be causing the erratic jumps (and random reported button clicks) in the input reports.

I suspect that there are also issues with the way I use LUFA-library too since I run into random issues if I get a large burst of output data going to the joystick in a short period of time. There seem to be also some timing issues with the MIDI-data to joystick. There are also some timing issues in replying to some USB-requests too quickly from the adapter to PC. I hope to get these solved by getting in touch with some LUFA-experts. It now looks very plausible to have a generic sample force feedback joystick project added to LUFA too.

I have already updated some of the MIDI-protocol documentation parts in the project Wiki and I'll post the new version of the code in the coming days too.

Thank you to all involved - especially Grendel and Ulao - for the help and support to get this thing already this far! I hope we can finalize it to be actually playable with any decent game.

BTW: I just got a second FFP with €10 to make sure the efforts are not wasted for me if one happens to break...