Can USB parallel port adapters be creatively (ab)used like old DB25?

[chkno]

Following the directions in the linux source tree, I made a SNES controller adaptor that connects to a DB25 parallel port. It works great and is fun to play.

The problem is that I am quickly running out of computers with parallel ports.

This use of a parallel port is within the letter but not the spirit of IEEE 1284. For example, it expects the driver to continuously transmit 0xFF to keep the data pins high, which are then run through diodes (so as not to short them together) and connected to the controllers' +5v power pins. The actual data from the controllers to the computer is passed back via the ACK, BUSY, PAPER-END, SELECT, and ERROR control lines.

Is this likely to work at all with these newfangled USB <-> DB25 adaptors? Is there a specific brand/model I should seek or avoid?

 

[dEAne]

You have to stick to USB 1.0 or 1.1 not 2.0 and above to play with USB to DB25. This is a pretty old gadget, this is only used on legacy printers. I played around this things a long time ago. If you wish its better to go USB than IEEE 1284 there are lots of application on the web. In your case you can search the web for that game adapter using DB25. You are very curious and thats good for an enthusiast.

 

[chkno]

Update: I found a data sheet for one of these things. It completely takes over the ACK and BUSY lines (controllers 1 and 2) to do data transfer without talking to the host. It does pass back the PAPER-END, SELECT, and ERROR lines (controllers 3-5) as usb packets, but only once per frame. The driver relies on being able to test these once per clock cycle.

Re-wiring the cable to skip controller lines 1 and 2 and re-writing the driver to be USB aware so that it could force one-byte frames, this might be workable. It would be something like 1000 times slower, but that would probably be ok because it only has to be as fast as a human can push buttons.

As wired and as written, this setup would not work at all. =(