FFP Force Feedback Improvements

[ej113]

So I've been very impressed with what has been achieved on this project! Since I was able to get the adapter to work I've been fascinated by what's going on under the hood and keen to get involved. Although the project seems to have been dormant for some time I can see that people are still building adapters for the increasingly venerable FFB Pro and using the code. Although it works very well in general I've noticed there are a few quirks of the force feedback (due to both adapt-ffb-joy and original MS firmware) so I've started some methodical testing.

I was going to wait until I had worked my way through and had a full list of the FFB capabilities and any potential improvements. But I found a simple fix already that I think will make a big impact on the feel of the device and the effects that can be perceived! I will submit this as issue #46 now and carry on testing.

What I've done so far:

• Studied the codebase and learned a bit about AVR, USB PID and MIDI
• Made a new .hex file (Using WinAVR on Windows 10) with USB debug enabled. I started from the juchong fork so that I could use an Arduino Micro.
• Read the USB reports and MIDI messages over USB Com port using TeraTerm while creating forces with fedit.
• Compared the USB/MIDI in a spreadsheet and tried to understand the data format and conversions. So far for constant force, ramp, sine, all with envelopes.
• Logged debug output in-game with timestamp so I can later understand what effects are typically used and how they're being controlled.

Still to do:

• Work through USB->MIDI conversions for other effects.
• Understand the in-game output - Planning to look at Need for Speed 3 (weirdly it has effects in both axes), FS Force plugin for FSX and XP Force plugin with FSX, as well as FSX native effects. My current PC won't handle the likes of MSFS2020 or DCS.
• Write some scripts, probably in Python, to send MIDI messages in real time over the debug channel and see if it helps to change any parameters differently to how the adapter currently does it.
• Report the capabilities, limitations of the FFB Pro so far as I find them and any potential improvements or fixes for the adapter.
• Have a go at updating the code

Progress is likely to be slow since I have a lot else on, but I hope to keep plugging away when I get the chance...

[ej113]

I'll start this (long and detailed) post with some background I've been able to piece together about Force Feedback APIs which I think is relevant, and then go on to list what I've found from experimenting with sending MIDI messages to the stick, and how I think the force feedback with the adapter can be improved. Apologies if any errors, misconceptions or omissions.

tl;dr I think there is enough information from reverse engineering now to make it possible to implement the generic DirectInput effects for the FFP as least as well as was done with the original MS drivers.

The first Force Feedback joystick on sale was the CH Force-FX in 1996 which used Immersion's I-FORCE 1.0 core and API. Not long after Microsoft released the Sidewinder Force Feedback Pro (FFP) using the Sidewinder Force "SWForce" API based on similar but incompatible technology from an acquisition of Exos Inc. (err … this ) The first few games supporting force feedback typically implemented one or other of these APIs but rarely both.

Microsoft and Immersion "played nice" over IP in this instance and worked together to develop the DirectX 5.0 DirectInput Force Feedback API which combined many of the common effects and parameters, ensuring a level of cross-compatibility. SWForce and IForce 1.0/2.0 still existed as separate API's that were "wrappers" around the DirectInput API and each included a host of additional proprietary effects. The FFP drivers were ported to DirectInput FF but since it pre-dates the API a few aspects were not fully supported by the FFP (e.g. periodic phase).Thereafter games using DirectInput were more universally compatible. Presumably games from Microsoft studios also made use of the additional SWForce effects on top of the basic force feedback, and some games used the additional effects provided by Immersion.

Most of the later (non-Microsoft) Force Feedback joysticks released licensed the IFORCE 2.0 processor (Logitech, Thrustmaster).

When USB became the standard for joysticks Microsoft and Immersion also worked on the Device Class Definition for PID 1.0 which is well aligned with DirectInput. The Sidewinder Force Feedback 2 (FF2) uses this, as does this adapter. When Gameport was dropped for Windows Vista so was the support for FFP (maybe earlier - not sure what version the final driver update was for).

As Sidewinder drivers ceased to be supported with newer versions of Windows, the additional SWForce effects became inaccessible for both legacy and new games, since without vendor drivers devices fall back to the generic DirectInput force feedback. This presumably affects the FF2 and USB FF Wheel but is also an unavoidable limitation of the adapter for FFP.

Some more recent iterations of DirectInput appear to have dropped an axis to only provide legacy support for wheels (I'm not very clear about when this applies). The latest API is now GameInput which does support two axis force feedback again but notably appears to have dropped Custom Force effects.

That's the background.

Here is the IForce SDK linked thanks to @kfix

And here is the Microsoft Sidewinder Force Feedback SDK Programmers Guide.
This is quite a find since it includes the specification for the FFP force feedback including how many of each effect type it supports, what parameters can be adjusted "on-the-fly" as well as explicit reference to anywhere that the FFP does not meet the DX5.0 DirectInput specification. This version seems to predate the wheel however.

As well as all of the generic DirectInput effects the FFP apparently has a number of device specific effects including

• 32 ROM effects (like keyboard samples) such as "AircraftCarrierTakeOff" and "PlasmaCannon2"
• RawForce, intended for direct streaming of forces from game physics engines
• "Wall" conditional effect that creates a notional barrier in the range of motion
• VFXEffects, which can combine up to 8 atomic effects in a sequence as a single effect

These are interesting, but given the lack of current API support there is probably not much value implementing them in the adapter. I reckon ROM and Wall effect MIDI messages (as well as Custom Forces) could be found by some educated guesswork, but to fully crack the others open would need ideally a legacy PC with the SDK including Microsoft Visual Force Factory (vforce.exe) and sniffing the MIDI lines. I haven't been able to find any trace of the SDK tools online. Only a low-res screenshot here and some libraries here.

I won't list out all the limitations of the FFP with respect to DirectInput, since they are well described in the Programmer's Guide. However I do have a few clarifying points from experimentation:

• The TriggerButton implementation differs from DirectInput. The FFP plays the effect once and stops it as soon as the button is released. RepeatInterval is not applicable. Also the selected button does not appear to be shiftable i.e. the trigger will play an effect regardless of whether the shift button on the base is pressed.
• Only phase values 0, 9000, 18000 are valid" (Units of deg/100). I think it should be 0,90,180,270deg for Sine and 0,180deg for other periodics.
• Periodic frequency values are limited to integers from 1 to 169Hz. This only allows coarse control of low frequencies i.e. 1Hz to 2Hz is a big jump perceptually. At higher frequencies there are increasingly large steps in actual frequency played. I bumped the effect sample rate as high as it would go and used a phone app "Spectroid" to measure this. At 50Hz the step is about 5Hz. Between 124 and 125Hz the response jumps from 124Hz up to 164Hz. This is B to E so you can't hope to play a tune with it! Maybe there is a hardware explanation for why it was implemented in this way.
• "Once a Ramp is created, like. Ramp_Up, it cannot be modified to become a Ramp_Down." I couldn't find this limitation. I was able to reverse ramp direction on-the-fly. I think "Peak Value 1" is constrained by the original drivers to always be greater than "Peak Value 2" for Ramps and Periodics but I still got the expected behaviour when this was not enforced.

I've been using some Python scripts to do all the message construction, data type conversions, checksums, serial port handling etc. and sending MIDI messages via the USB virtual serial port that was helpfully implemented in the adapter.

I'm making a few assumptions:

1. All the FFPs have the same firmware. I do have some doubts here since there are notes in the adapter code and wiki that certain things aren't supported by the FFP - but they worked for me when I tried them. I am using a 96755 model
2. There may be some workarounds of FFP firmware bugs either in the adapter or original drivers that I have not come across yet. Unless I hear/find otherwise I am presenting what appears to work after preliminary testing.
3. I am generally testing effects in isolation so there may be FFP bugs as above that only occur when effects are used in combination.
4. I am assuming that the timing in the Atmega32u4 is not so tight that some additional simple conversion of USB message data to MIDI messages would be possible without reducing reliability too much.

Here's what I've found so far. This all builds on what is in the Wiki.

Device Gain

The adapter is already sending device gain (i.e. stick volume) messages, but they are always set to max i.e. 0x7F.
0xB5 0x7C 0x7F 0xA5 0x7F 0x00
0x7C is the modify code for device gain. If the effect ID (3rd byte) is not 0x7F it still seems to apply to all effects including waveforms and conditionals.
These messages are currently sent in mode 0x01 but can also be sent when FFB mode is activated.

Effect IDs

Effect ID MIDI	Effect	In adapt-ffb-joy?
01	Custom
02	Sine	X
03	Cosine	X
04	Square Start Low
05	Square Start High	X
06	Ramp 2->1	X
07	Ramp 1->2
08	Triangle Start Low	X
09	Triangle Start High
0A	Sawtooth Up	X
0B	Sawtooth Down	X
0C	?
0D	Spring	X
0E	Damper	X
0F	Inertia	X
10	Friction	X
11	?
12	Constant	X

High refers to the greatest value in the nominal direction as e.g. played with a positive constant force
As you can see Adapt-FFB-Joy already supports all of the DirectInput effects at some level except Custom Forces.

Effect Parameters

SysEx Byte(s)	Modify Value	Parameter	Usable Range	Description
6	N/A	Effect Type	0x01..0x12	Select Effect type. See Table of effects
7	N/A	Overwrite Effect	0x02 .. 0x7F	Overwrites allocated effect IDs only. If not allocated takes next available slot.
8,9	0x40	Duration	0 .. 16383	Units of ms. 0.002 to 32.766s or 0 is infinite.
10,11	0x44	TriggerButton	0b0 .. 0b1	Bitwise assignment for 9 buttons from LSB. Stops when button released. Multiple buttons can be assigned to each effect.
Waveform Effects (ignoring Custom(4))
12,13	0x48	Direction	0 .. 360	Units of Degrees
14	0x4C	Effect Gain	1 .. 127	Scales effect including envelope
15,16	0x50	Sample Rate (1)	1 .. >340	Samples/s (Hz) in waveform. Saturation value unknown but >340
17,18	0x54	Truncate (2)	1 .. 10000	Values less than 10000 truncate the waveform proportionally in time i.e. cut and shut
19	0x64	Envelope Attack	0 .. 127	Attack level
20,21	0x5C	Attack Time	0 .. 16383	Time attack ramp ends. Interpret same as Duration
22	0x68	Envelope Sustain	0 .. 127	Level between attack end and fade start
23,24	0x60	Fade Time	0 .. 16383	Time fade ramp starts. Interpret same as Duration
25	0x6C	Envelope Fade	0 .. 127	Fade level
26,27	0x70	Frequency	0 .. 169 (3)	Units of Hz. 1 for Ramp and Constant Force.
28,29	0x74	Peak Value 1	-128 .. 127
30,31	0x78	Peak Value 2	-128 .. 127	Present but not used for constant force
Conditional Effects
12,13	0x48	Roll Coefficient	-128 .. 127	Negative values are non -restoring and unstable
14,15	0x4C	Pitch Coefficient	-128 .. 127	Negative values are non -restoring and unstable
Conditional Effects except Friction
16,17	0x50	Roll Offset	-128 .. 127	Centre offset
18,19	0x54	Pitch Offset	-128 .. 127	Centre offset

Notes
(1) Are there implications of increasing sample rate above the default 100Hz? Do the original drivers limit max frequency?
(2) Truncate can be used to e.g. play a square wave with a 00100100 pattern. But it is not a known parameter in the API.
(3) Frequency of 0 plays a very long period wave ~30s. Sample Rate must be >>2x frequency to properly capture waveform.
(4) I haven't quite managed to get Custom Forces to play samples as I expect, but I can at least get them to play and I'm certain they overlap with WaveForm messages at least up to byte 16.

Another Observation

Sending an "after touch" message after Start Effect is a shortcut to modify the effect gain. The modification persists the next time the effect is played.
e.g. B5 20 02 A5 3E 00

Conclusions

I think a good objective would be to fully support the PID spec as far as the FFP will allow, with the exception of Custom Forces, which I don't believe are often used. Complex logic in the adapter, for example using multiple effects to stand in for a single effect, should be avoided.

Here is a list of improvements I have identified to achieve this that can work with the FFP. I will aim to submit more details in issues.
These ones I think will have a significant effect on the general user experience:

• Resolve issue with incorrect effect gains (Subtle effects missing due to int overflow in CalcGain  #46)
• Bugs with constant forces being adjusted on the fly - negative values don't work and envelopes are suppressed
• Effect gain for all effects, using the actual effect gain parameter where possible
• Device gain

And the following mainly improve support for less commonly used effects and parameters or cover edge cases:

• Support offset and magnitude for periodics other than sine - currently they use max range.
• Support all types of ramps as far as FFP allows
• Support SampleRate for Waveforms. If set to max in USB, ensure this is bumped up to at least 2x Nyquist rate for higher frequencies. This will fix Periodic effects don't work with all frequencies ("feature" of the joystick) #6
• Play nearest of 4 values of phase for sine; 2 for other periodics
• Support TriggerButton (using the available FFP implementation)
• Handle overflows of sine offset +/- magnitude. There is nothing preventing values exceeding the range in the USB input. Currently this causes erratic stick forces.

And one I am on the fence about - I think it's possible but the adapter logic could be complex.

• Support StartDelay and LoopCount parameters (issue feature request: support start delay parameter #33) by timing Start Effect messages in the adapter.

I'm aware probably not many people will stumble across this post here, but it still seemed like the right discussion board to attach it to. I'd like to wiki some of the above to make it referenceable in future.

[ej113]

Hi @tloimu, I'd be keen to contribute and eventually get some of these (potential) updates into the main repository via pull request, as well as updates to the wiki, for greatest visibility. Most of the existing forks are "user preference" style customisations of axes, buttons & pinouts etc., but no one else has touched the force feedback code. I know it's been a few years so would understand if you're not interested in maintaining this project any more? If that's the case, no worries, I can fork and go my own way.

[ej113]

The implementation of periodic effect parameters doesn't quite match between FFP MIDI and USB and some translation is needed. The current translation in the adapter is close but not quite right. I wanted to document my interpretation somewhere, so here it is:

Here is a diagram of how the USB parameters describe the levels of a sine effect with envelope:

And this is how it appears to work for the FFP:

For USB the unsigned Attack, Magnitude and Fade levels and the signed Offset are all as a proportion of the available range set by the device x effect gains.

For FFP the device x effect gain sets the available range. This is then scaled to the limits set by signed values Param1 and Param2, which implicitly includes the offset from zero, since effects are symmetrical about the centre. Attack, Magnitude(a.k.a. Sustain) and Fade levels are then proportional to these limits. The plot shows Attack set at 100% (0x7F) and Magnitude and Fade set lower.

Normally Param1 is set higher than Param2 and this gives a phase of 0°. A phase of 180° can be generated by reversing these values.

So to set this correctly in MIDI, for the case where USB Attack Time and Fade Time are both nonzero and Phase is ~0.
Param1, Param2 = Offset +/- max(USB_Attack, USB_Magnitude, USB_Fade)
and then MIDI levels need to be scaled. (There may be some factors of 2 in here that I'm ignoring for this explanation)

For reference, the current adapter firmware sets MIDI Magnitude to 100% (0x7F) and uses Param1, Param2 = Offset +/- USB_Magnitude. Attack and Fade levels greater than Magnitude are therefore not possible.

For the FFP there is no way to set an offset +/- magnitude value that is "off the chart". Currently there isn't a check in the adapter that this hasn't been set in the USB input, and this condition will set invalid parameter values and cause the effect to play erratically. FEdit seems to indicate the effect should be clipped, but I haven't seen this stated in any spec, and the FFP can't do this.

There are 3 ways I could see this can be resolved by the adapter:

1. Respect levels and reduce offset to fit
2. Respect offset and reduce levels to fit
3. Respect the ratio between offset and levels and scale both.
   I think 1. makes most sense. Hopefully this is an edge case anyway since game implementations would hopefully avoid it.

[ej113]

Also the adapter currently includes the ratio of effect gain in the calculation of Param1 and Param2 - this can be separated since the Effect Gain parameter is now known.

[ej113]

I've been able to implement this in my fork. The way I did it was actually using [2. Respect offset and reduce levels to fit.] This was the simplest to implement, gives the correct behaviour when used for ramps, and in most cases keeps the number of parameters to be modified low.

Essentially (and ignoring type conversions between USB and MIDI)

1. Set param1, param2 to the min and max values that can achieve the correct offset. So for offset = 0 they are at extremes [127,-128] and for offset = +10 they are [127, -107]
2. range = param1 - param2
3. Swap param1 and param2 if 180 degree phase shift is needed
4. Scale magnitude, attack and fade * (127 / range), or 127 (0x7F) if saturated i.e. "off the chart".

For ramps exactly the same method is used. According to the Microsoft Sidewinder Force Feedback SDK Programmers Guide Appendix E. Ramps are defined so that:
offset = (start + end)/2;
magnitude = abs(start - end)/2
And then the envelope attack and fade work as specified and can be outside or inside the unenveloped ramp.

By swapping param1 and param2 both upwards and downwards ramps can be played. This can also be changed on the fly - which the guide says is not possible - but it works! I think the drivers originally always set param1 > param2. I'm not sure if swapping them could cause some unexpected behaviour, but I haven't found any yet.

[ej113]

MIDI 0xC5 0x01 = Reset (stop all effects; free all effects; reset device gain to 0x7F; enable actuators; enable auto spring centre)
MIDI 0xC5 0x02 = Enable actuators
MIDI 0xC5 0x03 = Disable actuators (but time stepping continues for effects)
MIDI 0xC5 0x04 = Continue (resume paused effects)
MIDI 0xC5 0x05 = Pause currently playing effects at current time step
MIDI 0xC5 0x06 = Stop all effects
MIDI 0xC5 0x07 = ??? Not sure. The Wiki refers to this under "Quit FFB Application" with a following sequence. It doesn't seem to have any effect on it's own and it's not used by the adapter.
0x01 to 0x06 correspond exactly to the USB PID Device Control commands

In modes 0x03 and 0x05 other effect commands are accepted. e.g.
When starting effects while device is paused, they are queued until Continue
When starting effects while actuators disabled, they start at the current time step and time stepping continues in the background.

[ej113]

I found a weird bug with the FFP (not the adapter) where periodic effects with finite duration stop playing prematurely if you decrease the frequency while they are playing, sometimes instantly and sometimes after a few cycles. Increasing frequency starts the effect playing again if still within duration.

Probably not an issue very often in games because the frequency drop has to be quite large for this to be noticeable.

[ej113]

The other FFP bug I had found is that changing Peak Value1 (param1) on the fly for Constant Forces causes the envelope attack and fade to stop being applied, including any time the effect is played again. I was able to work around this by leaving it set to maximum (7F 00), using the Envelope Sustain parameter for magnitude and flipping the direction by 180degrees if the USB magnitude value became negative.

[gh0stless]

Thank you for your commitment, when will there be a new firmware version?

[ej113]

Beta for testing now available!
v0.5.0beta1

[ej113]

Done testing and it all seems to work. Here's my plan for tloimu/adapt-ffb-joy:

1. Submit pull request
2. Tag this commit as "0.3.0 (=r54)"
3. Tag latest commit as "0.4.0 (=r74) [unreleased]"
4. Wait at least one week before then merging pull request if no objections from @tloimu et al.
5. Release as "0.5.0 [beta]". The first .hex targets Teensy 2.0 only, for legacy adapters, consistent with the previous .hex files. USB serial port will be disabled in the released firmware.
6. Sometime after create two branches in the main repo that include commits from each of JayBee-git and juchong forks. These both remove the extra axes for trim pots and set the arrow button as a shift function. The latter then targets Micro/Pro Micro by changing the pinout (PB0 -> PB6). I have an additional fix to get the LEDs working.
7. Release two additional .hex files from compiling the above branches, under the same version release.
8. Some updates to the wiki.

I'm tagging r54 because the *_r54.hex is still the download and the current commit because it has been used for most forks, even though an *_r74.hex was never published in the main repo. r54/r74 refer to the google code commit that was previously used to version the hex.
The new release is labelled a beta until at least a few other people have tested it and fed back!

[You69Man]

@ej113 I'm amazed and happy that this project, which I thought was dead for about two years, has come out of its coma! I own a Microsoft Forcefeedback Wheel since about 24 years, but it's unused long time (due to obsolete gameport interface). I have often been close to throwing it away, but at the same time the desire to once play with it again is great. That's why I spent some time on this project 2-3 years ago, built an adapter and also spent some time on the firmware. I got the steering to work, but unfortunately the force feedback experience didn't happen. I also didn't manage to scrape together enough know-how to help myself. Since nothing else was happening in the project, I gave up and it fell asleep again. By pure chance, I looked into the project again today and saw that there is indeed something new, which made me very happy. However, I have to admit that I didn't read and understand everything.
So I wanted to ask, does the new merge also bring any improvements for the Wheel? Or if not, is it foreseeable that something will happen in this direction again? Many thanks for your efforts!

[ej113]

Nothing new for the wheel, although I've tested it and recorded the current state here #39. Where I've changed the wheel FFB source files it's only to maintain compatibility with the generic FFB code. I want to have a go at the wheel FFB, but not promising anything. Plus it's taken since about May to get this far on the joystick, and there's a bit more to do for the wheel, so I wouldn't hold your breath for anything soon!

[You69Man]

No problem, there is no hurry. The wheel has been stored so long in the box, so it can wait even longer to get into action again. In any case as long as there is any chance for a 'breakthough' for the wheel i will not dismiss it yet. It would be such a pity for this actually very excellent part!

[ej113]

I started a separate thread on wheel force feedback developments #54

[gh0stless]

[ej113]

Hmm. Well it sounds like either a) fedit not working properly on your system b) you weren't covering the light sensor on the front of the stick or c) something intermittent with wiring that might work if you tried it again.
I'm presuming the effects you got in X3 are more than just the basic spring centering effect?

[HotteX]

THank you for breathing back life in this project! I unwrapped my dear 96755 tonight, replugged some wires on my breadboard and gave your new beta a go and it works like a breeze (Teensy2.0, SW FFPro, Win11).

Tried Freespace2 and ForceTest. Both work. The "Groove" Effekt in ForceTest does nothing (but I think it didnt work before).
The slight tremble of the axes is still there.

There is a small mix-up in https://github.com/tloimu/adapt-ffb-joy/releases/tag/0.5.0beta1 Table "Which Firmware should I use?": The table mixes the Micro-Firmware and the Teensy Firmware Target Boards (but its obvious with the names of course).

The firmware with 8 axes has 2 of my potis "combined", so their position is added up (to 100%). Is that on purpose? I have no idea how that was before, but the 8th axis is also "dead" in my calibration view.

[ej113]

Glad to hear its working for you.

There is a small mix-up in https://github.com/tloimu/adapt-ffb-joy/releases/tag/0.5.0beta1 Table "Which Firmware should I use?": The table mixes the Micro-Firmware and the Teensy Firmware Target Boards (but its obvious with the names of course).

Thanks for reporting this! I have fixed it now.

The "Groove" Effekt in ForceTest does nothing (but I think it didnt work before).

You should get only the first groove. FFP does not support LoopCount (i.e. repeatedly playing an effect) nor StartDelay (in order to leave gaps between the grooves). This is noted in the release notes and issue #33. It is possible to get them to work but only by implementing a timer in the adapter and having the adapter manage all the repetitions and delays. I don't know how often these parameters are used - Dirk who made ForceTest implemented an alternative method in FS-Force with the PC app managing the timings because not all other joysticks supported them.

The firmware with 8 axes has 2 of my potis "combined", so their position is added up (to 100%). Is that on purpose? I have no idea how that was before, but the 8th axis is also "dead" in my calibration view.

It is exactly as the original firmware. tloimu used them for separate rudder pedals combined into one. I wanted to leave the original setup for anyone who was already using their adapter in this way.

Configuration is an open question. It is simple enough to change these things in the code (buttons, axes, smoothing the trembling axes and so on) and there are forks with most of these variations. I think it would be good to get a lot of the "options" like this in initially as pre-compile switches - but then there are so many permutations it still requires users to "roll their own" if they want exactly the right set. There are the seeds of a configuration tool with the USB serial port (disabled in those beta builds) allowing you to e.g. disable particular effects, but it would require a desktop widget to manage the settings, it might affect performance to have the serial port open and it is very difficult to allow changes to the descriptors to report different buttons and axes to the PC. These are pretty much fixed in program memory.

[FluffyRedLobster]

@ej113 I just wanted to add my thanks for breathing life back into this project as Hottex said. I've applied the v5 beta to my teensy and am looking forward to giving it a thorough test. Your firmware updates combined with the jitter fix from nhede in #23 look like major steps forward. Thanks again!

[sonik-br]

@ej113 Kudos for the research and documentation!

I currently only have a FFB2 Joystick but a I recently got a FFBPro one that I whant to use on a old XP machine to play "SWForce". I also want to try the updatd firmware with this device to use it on a modern pc.

I'm tempted to write a wrapper for SWForce to modern dinput ffb. Do you happen to know if something like this already exists?
And if the original microsoft driver supports any SWForce device via usb? Or it's just via gameport? If it does support via usb, I could write a RP2040 firmware that emulates a SWForce usb device and translate the ffb info to USB-PID or even Logitech's FFB. This would allow modern sticks to be used on older SWForce exclusive games.

I want to also make a wrapper for iforce1 to dinput. It appears that an official wrapper was made by Immersion but I can't find it anywhere.

And while on it... As the Windows native usb-pid driver does not have any user configuration setting, I've made an external dinput injector that can modify some ffb parameters. I use it to set the strength of some effects.

[ej113]

Thanks. I'm not sure I can add much new but...

And if the original microsoft driver supports any SWForce device via usb?

This I doubt, since we have the PID descriptors for both the USB wheel and the later FFB2. The PID spec allows for additional proprietary effects and parameters that could have included the SWForce only ones, however they are not evident in the descriptors, which seem to be vanilla directinput. Does the FFB2 configurator tool allow you to test the canned ROM effects like the FFP one?

The Freespace 2 source code, which I linked somewhere above and used the SWForce libraries, might be useful.

Good luck!

[SantiagoSaldana]

Amazing work. I have been working on a recent project to support force feedback devices on a Teensy as a host. I've run into some USB issues and went back to look at my old adapt-ffb code and stumbled on the work you have been doing since last year. Brought a smile to my face as I had mentioned some of this stuff to tloimu when I was playing around with building an Arduino library for the device. Specifically I noticed how the device wouldn't respond to certain frequencies.

My main question. I had to update to Windows 11 for work and nothing WinAVR related is working for me. What toolchain are you using to make updates / compile the code?

Sorry had to repost as I was signed in on the wrong github account.

[ej113]

I've not updated the toolchain. WinAVR installed and worked fine for me on Windows 10. I didn't go near the IDE though - just ran "make" from the shell (sh.exe). juchong reported success with WinAVR using a Windows 7 VM.

It would be great to hear if you or anyone has success building or testing this with the newer toolchain, or a later version of LUFA. I've just tried not to open this can of worms.

[SantiagoSaldana]

I spent a while trying to get the toolchain to work under Windows. I found this site https://www.tonymitchell.ca/posts/setup-avr-toolchain-on-windows/#install-avr-toolchain to be helpful but running make it just says file not found.

On the other hand I tried installing linux mint on a virtual machine

sudo apt-get update
sudo apt-get install gcc-avr binutils-avr avr-libc gdb-avr avrdude

Then I tried pulling down the code and typing make and it just worked.

There is the issue of moving files back and forth across the virtual machine, but I might just use that approach. I spent 3 days working on the USB side of things. I'm using a teensy as a host and connecting to the controller. It's frustrating working with a black box. I use WireShark to see what works but only have the USB protocol.

I went back and found that I had already coded up what I wanted to do with my original arduino libary code, I just forgot about that example. It's also not quite the same as it only works for the gameport devices like the sidewinder and not across the USB bus. I hope to be able to use the adapt-ffb as I can confirm that commands are working and then hopefully debug it across a spare Serial line or use software serial. Can't use the original USB serial as I won't be connected to a computer. Great work by the way.

---

I tried it later, and it was trivial to set up shared folder in virtualbox to share the Joystick.hex file between linux and windows. I tried building it and exporting it and then uploading it to the teensy and it worked fine.