It seems that K8055N and VM110N do not suffer this DirectX problem any more!
retrotecchie: You may try to use K8055N or VM110N. It may solve the problem.[/quote]
Welcome.
retrotecchie: Based on my findings below, your best option is probably getting one of the new cards.
I think I found something. If I remember correctly J_Holland used USBlyzer to capture the USB config data from his original K8055. The USB descriptors, he created from that data, are identical to the original K8055 ones. They specify in the HID report descriptor input and output as “0x81,0x02” and “0x91,0x02”. Those 0x02 values mean “Data, Variable, Absolute”. If I change those to “0x81,0x00” and “0x91,0x00” (Data, Array, Absolute), DxDiag does not crash any more when my card is connected. It still works just fine with that change.
VEL255: If you have access to the K8055N firmware code, can you take a look at the USB HID Report descriptor and see if that is indeed a detail that has changed?
Thanks MostlyHarmless!
It seems that finally the cause of the DirectX problem is found!
Indeed, there are different descriptors in the K8055N/VM110N than in the K8055/VM110.
Here are the descriptors used in the K8055N/VM110N:
0x06, 0x00, 0xFF, // Usage Page = 0xFF00 (Vendor Defined Page 1)
0x09, 0x01, // Usage (Vendor Usage 1)
0xA1, 0x01, // Collection (Application)
0x19, 0x01, // Usage Minimum
0x29, 0x08, // Usage Maximum //8 input usages total (0x01 to 0x08)
0x15, 0x00, // Logical Minimum (data bytes in the report may have minimum value = 0x00)
0x25, 0xFF, // Logical Maximum (data bytes in the report may have maximum value = 0x00FF = unsigned 255)
0x75, 0x08, // Report Size: 8-bit field size
0x95, 0x08, // Report Count: Make eight 8-bit fields (the next time the parser hits an "Input", "Output", or "Feature" item)
0x81, 0x00, // Input (Data, Array, Abs): Instantiates input packet fields based on the above report size, count, logical min/max, and usage.
0x19, 0x01, // Usage Minimum
0x29, 0x08, // Usage Maximum //8 output usages total (0x01 to 0x08)
0x91, 0x00, // Output (Data, Array, Abs): Instantiates output packet fields. Uses same report size and count as "Input" fields, since nothing new/different was specified to the parser since the "Input" item.
0xC0} // End Collection
[quote=“VEL255”]Thanks MostlyHarmless!
It seems that finally the cause of the DirectX problem is found!
Indeed, there are different descriptors in the K8055N/VM110N than in the K8055/VM110.
Here are the descriptors used in the K8055N/VM110N:[/quote]
Thank you very much.
That looks very similar to what I have tested.
I wonder if this could also be the cause of some of the Windows-7 problems, people were reporting.
[quote=“MostlyHarmless”]I wonder if this could also be the cause of some of the Windows-7 problems, people were reporting.[/quote]Indeed, there have been some strange problems with Windows 7. I hope K8055N/VM110N will fix some problems.
I have isolated these changes using a PIC18F2550 just to be sure.
With the original K8055 HID descriptors, Windows XP (32 bit) DxDiag.exe crashes. Windows 7 DxDiag.exe as well as it’s 64-bit counterpart ignore the K8055 (not listed under Inputs but they don’t crash). The card works and can be accessed via K8055D.DLL on both systems. This behavior is identical to my PIC16C745 on life support.
Changing the HID descriptors to the K8055N ones, everything is peachy. Both systems list it in the DxDiag Inputs and it can be accessed without any problems.
The bad news is that this problem cannot be solved with a download, installing another DLL or anything like that. The problem is inside the PIC on the K8055 card. Anyone having this problem will need to modify the K8055 hardware one way or another. The original PIC16C745 on the K8055 is a one-time-only program chip. There is no way to change it. So you will have to replace that chip or the entire card.
The replacement chip I am using is the (almost) pin-compatible PIC18F2550. Subscribe to this thread to see how that is progressing: viewtopic.php?f=3&t=7480
The newer VM110N board solves all the problems I have been experiencing. Clearly the transition from the 16C745 silicon to the better 18F24J50 device has been the way forward here.
Using the existing software, untouched, and swapping between my K8055 and the VM110N, the old silicon causes the DxDiag DirectInput crash and the newer board works like a dream. The demo software also works with the two boards simultaneously (on different addresses) so the two can be happily mixed in applications where DirectInput isn’t an issue.
My only slight disappointment is that the new VM110N has a surface mount PIC on the board, so I’ll have to field-replace all my older boards, rather than just swap chips (would have been nice not to have to rewire all the I/O lines to the boards themselves!) but I’ll be able to reuse the older versions for other tasks not needing DirectX, so no huge problem financially. The old silicon works just fine with Mindows 98 embedded boxes and our legacy Windows 2000 systems.
