Tom's brain dump-ADI protocl of Logitech Wingman Interceptor
Posted: Thu Aug 07, 2008 12:16 am
Tom's brain dump
The standard Linux kernel already includes a rather good implementation of the ADI protocol. (Vojtech Pavlik wrote the code), I don't seem to be able to find that spec around here anymore (maybe if I dig a bit more), but I would suggest you start out with Vojtech's code.
· analog lines are used as \"output\", or trigger (request to send). A write to the gameport causes the analog lines' voltage to drop, which is recognized by the firmware as a request to send a report (What kind of report? Data? ID? Or both?).
· when the firmware sees a trigger on the analog lines, it serializes out a bitstream across the digital lines. It can deal with either 4 digital lines, or 2 digital lines (button0/1 or button 2/3), which allows it to work on Y cables (two ADI devices on a single gameport). The firmware detects(how can firmware detect? voltage? Or by other means?) how many button lines are hooked up and then decides if it wants to use the first half, second half, or the full gameport.
· when using the first/second half, it serializes the bitstream out linearly.
· when using the full gameport, it cuts the bitstream in half, and sends the first part of the bitstream through the b0/b1, and the second half through b2/3
· a button pair (b0/1 or b2/3) uses an encoding scheme where every bit causes either one or the other line to change. In case of a \"0\", one of the lines changes, in case of a \"1\", the other one. This allows the host to extract the clock, as there will be a guaranteed transition every bit (which is around 10 microseconds per bit, but may be a bit larger (up to 100us (=0.1ms) for WingMan Gamepad Extreme, due to interrupt routines inside the pad).
· to find out what device is hooked up and to switch it to ADI mode (WMED can be an analog or ADI joystick), you need to send it a \"magic knock\". This is just a sequence of writes with defined timing - see Vojtech's code for the exact numbers. To knock it back into analog, you have to perform another \"knock\".
· as for the parsing of the bitstream, I'd suggest you look at Vojtech's code as well.
· ADI is officially dead now, we won't be making any new devices that hook up to the gameport.
You can find an old description that Vojtech wrote up at one point (before he had the spec) here.
(original source: http://atrey.karlin.mff.cuni.cz/~vojtec ... /specs.txt)
Florian Bruckner wrote::: Hello!()：Hi Florian,to be honest, I didn't get any time to search for the ADI spec. However, considering that it is a \"self-describing\" specification (the ID packet has the number of 10 bit axes, number of 8 bit axes axes, buttons, hats along with the device ID), and it will report those pieces in that sequence as well I think you should really take a look at the Linux code (adi.c, attached for your reference) - remembering the ADI spec when I read it last (awhile ago
, this code seems almost clearer than the spec, it even implements \"SideCar\" (which is a product that never was built adi_read_packet() does the low-level bit banging,adi_decode() decodes a received packet,adi_read() reads a full report and decodes it.to find out about your device, adi_id_decode() will decode the ID packet and figure out the capabilities of the device. That's about all you need, and it's better than the spec From my memory, the Extreme Digital 3D has the following format:10 bit X10 bit Y8 bit Throttle8 bit Twisthowever many buttons4 bit POVNone of our code uses any hard coded capabilities or bit masks, it acts much like the adi.c code that is attached (except that it's much more complicated for no good reason)Scroll down...（）：I was able to find some information from Pavlik Vojtech in the internet that shows how an ADI - Packet looks like. But unfortunately it only shows the packets sent from an Wingman Extreme Digital. I would be pleased if you could tell me how this packet looks for a Wingman Extreme Digital 3D.:: e.g. like that::: Logitech WingMan Extreme Digital packet::
The standard Linux kernel already includes a rather good implementation of the ADI protocol. (Vojtech Pavlik wrote the code), I don't seem to be able to find that spec around here anymore (maybe if I dig a bit more), but I would suggest you start out with Vojtech's code.
· analog lines are used as \"output\", or trigger (request to send). A write to the gameport causes the analog lines' voltage to drop, which is recognized by the firmware as a request to send a report (What kind of report? Data? ID? Or both?).
· when the firmware sees a trigger on the analog lines, it serializes out a bitstream across the digital lines. It can deal with either 4 digital lines, or 2 digital lines (button0/1 or button 2/3), which allows it to work on Y cables (two ADI devices on a single gameport). The firmware detects(how can firmware detect? voltage? Or by other means?) how many button lines are hooked up and then decides if it wants to use the first half, second half, or the full gameport.
· when using the first/second half, it serializes the bitstream out linearly.
· when using the full gameport, it cuts the bitstream in half, and sends the first part of the bitstream through the b0/b1, and the second half through b2/3
· a button pair (b0/1 or b2/3) uses an encoding scheme where every bit causes either one or the other line to change. In case of a \"0\", one of the lines changes, in case of a \"1\", the other one. This allows the host to extract the clock, as there will be a guaranteed transition every bit (which is around 10 microseconds per bit, but may be a bit larger (up to 100us (=0.1ms) for WingMan Gamepad Extreme, due to interrupt routines inside the pad).
· to find out what device is hooked up and to switch it to ADI mode (WMED can be an analog or ADI joystick), you need to send it a \"magic knock\". This is just a sequence of writes with defined timing - see Vojtech's code for the exact numbers. To knock it back into analog, you have to perform another \"knock\".
· as for the parsing of the bitstream, I'd suggest you look at Vojtech's code as well.
· ADI is officially dead now, we won't be making any new devices that hook up to the gameport.
You can find an old description that Vojtech wrote up at one point (before he had the spec) here.
(original source: http://atrey.karlin.mff.cuni.cz/~vojtec ... /specs.txt)
Florian Bruckner wrote::: Hello!()：Hi Florian,to be honest, I didn't get any time to search for the ADI spec. However, considering that it is a \"self-describing\" specification (the ID packet has the number of 10 bit axes, number of 8 bit axes axes, buttons, hats along with the device ID), and it will report those pieces in that sequence as well I think you should really take a look at the Linux code (adi.c, attached for your reference) - remembering the ADI spec when I read it last (awhile ago
, this code seems almost clearer than the spec, it even implements \"SideCar\" (which is a product that never was built adi_read_packet() does the low-level bit banging,adi_decode() decodes a received packet,adi_read() reads a full report and decodes it.to find out about your device, adi_id_decode() will decode the ID packet and figure out the capabilities of the device. That's about all you need, and it's better than the spec From my memory, the Extreme Digital 3D has the following format:10 bit X10 bit Y8 bit Throttle8 bit Twisthowever many buttons4 bit POVNone of our code uses any hard coded capabilities or bit masks, it acts much like the adi.c code that is attached (except that it's much more complicated for no good reason)Scroll down...（）：I was able to find some information from Pavlik Vojtech in the internet that shows how an ADI - Packet looks like. But unfortunately it only shows the packets sent from an Wingman Extreme Digital. I would be pleased if you could tell me how this packet looks for a Wingman Extreme Digital 3D.:: e.g. like that::: Logitech WingMan Extreme Digital packet::