"Jim Thompson" wrote in message news: snipped-for-privacy@4ax.com...
The problem is that devices like this, do not take 'parallel port commands', but direct bit I/O, often at high rates. So (for instance), the driver may issue something like a 1uSec pulse easily when talking directly to the port, but via the 'time sliced' system used on USB, this becomes very difficult indeed. The only 'universal' way to do it for output, would be to use something like a bulk I/O device, and sample the data to be sent perhaps every uSec, and then send this as a block to the USB device, which generates the output at the same rate. This however would fail, if the communication is bidirectional. If (for instance), the local driver expects to output a bit, and then only a uSec latter, retrieve a 'reply'. By the time the transmission is packetted up, and sent over USB, then the reply is received, hundreds of times the expected delay wuld have taken place. The way it can be done, is to put significant intelligence in the USB device, and program this to output the required patterns, and retrieve the data, then send this as a 'non timing critical' transaction over USB. This can be done, and several companies do such adapters for their older devices, but it requires a new local driver, and custom code in the USB device, which makes this a more expensive solution....
Best Wishes