Looking for code or whatever to control the pins on a usb parallel adapter.

AFAIK you can not control individual pins on a USB - parallel port adapter like the real hardware. You will need specialized USB I/O device.

"Real" parallel ports were never that standard. I used to use them as digital I/O for programming fpgas and flash memory. I found that the code was very fussy about the SuperIO chip type and even the bios.
The low cost USB equivalents do not give you the fine bidirectional control of individual pins

Moved to Programming

Apparently, there are some USB parallel printer ports that allow bit-level access. I know of someone who needed such a device to satisfy a copy protection dongle (Windows software), and he was able to do so. I don't know any more specific information than that.
--- rod.

If one can send a byte, he/she can send a byte with individually changed bits. So, the bit access probably applies only to status bits.

It isn't quite that simple. There are data bits, and there are control and status bits that manage the transfer of the data. In all but the most primitive parallel ports there is also the capability to use the data lines bidirectionally, in a couple of different formats. Most USB parallel ports are geared to printing only, and often using closed-source Windows-only drivers. The original IBM compatible printer ports were little more than a few latches and line drivers mapped into some real-mode IO space, and provided the capability to access bits and bytes individually, and without regard for Centronics compatibilty. These type of printer ports have all but disappeared from the landscape. There used to also be a plethora of online references to printer ports, and lots of hacker oriented projects that use them. I have used them in a couple of projects that are still running after several years. Don't know what I'll do when the hardware dies. I thought the parallel port would be ubiquitous for years...
--- rod.

I am reiterating my point: modern general purpose CPUs do not have bit-level addressing, just the byte-level one.

Hi -

theNbomr is right. Programming a parallel port in DOS (or, for that matter, via a linux kernel module) involves much more than simple "byte-wise bit twiddling". Here are two very good links (for Linux, not DOS, that is ):

http://parapin.sourceforge.net/doc/parapin.html

http://www.xml.com/ldd/chapter/book/ch08.html

Back to the original question: what about parallel port programming over a USB device?

We actually investigated this recently. We had a specialized device that happened to use a parallel port plug; it interfaced to DOS with some assembly language code. We needed to port to Windows (and to a motherboard that doesn't have a parallel port or any spare PCI slots). We considered substituting a "USB parallel port" device ... but ultimately wound up just using an Advantech I/O controller (also USB!) instead.

In any case, I believe in this latter scenario, michaelk's comments are correct:
As such, Sergei Steshenko comments are also correct.

IMHO .. PSM

I wasn't suggesting bit level addressing, in the sense of a microcontroller with bit addresses; merely that the original style of parallel port hardware made it easy to do bit-bash style hacking. In contrast, the USB parallel port usually (exceptions exist, as I mentioned earlier) provides a higher level of abstraction, such as the handshaked transfer of a byte or probably even larger chunks of data.
--- rod.

I know about the traditional parallel port I have hooked stepper motors, servos and switches to it. Linux does have a driver for usb parallel cable, but I am not a machine language programmer. While researching this yesterday, I found where someone had taken 74373 and 7400 chips (plus resistors) to a jet direct box and did some home automation. Since the chips are cheap, It might be neat to see if it works for the usb parallel cable also. Since there is no way for it to work, I have nothing to lose.

So, what is the problem compared to traditional parallel port ? The fact that the transfer is handshaked ?

The problem is that the USB parallel ports don't provide a way to access the non-data registers directly (or even the data registers, for that matter). In applications such as peonuser describes, these other bits can be used as well as using the status bits as inputs. The USB-based interfaces only provide for Centronics-compatible operation. To transfer a byte to a printer requires a sequence of bit setting and polling that the USB interface performs internally. For applications that need to use the bits in other ways, there is no method to access the appropriate registers. The traditional Centronics compatible hardware also provided a bit that could be used to generate interrupts, allowing you to connect arbitrary TTL level signals to it, and trigger interrupts. In DOS and other real-mode applications, you could toggle bits in either the data register or control register under controlled timing, and this is one feature that software security dongles use.
So yes, if one wants to use the control register for purposes outside the Centronics standard, the USB-based interface will not allow this, as it alone will control the bits used for performing the handshake. To understand all of this, I suggest that you explore the nature of the parallel interface through one of the numerous online descriptions, perhaps starting with Tomi Engdahl's Parallel Port Interfacing Made Easy. The final couple of paragraphs are particularly germane to this thread.

--- rod.

I don't need. In the mid-end eighties I designed ROM simulator connected to a parallel port of the host computer and support package for.

The simulator had a cable connected to a socket which had the same geometry and pinout as a ROM to be simulated; but internally it was a static RAM into which the code to be debugged could be downloaded.

The thing was used instead of PC BIOS ROM to help debug HW problems first, and then to debug BIOS modifications.