Some things use very precisely timed signals, as short as a few microseconds, and that simply can't be recreated by software over USB without hardware support.
Some things use very precisely timed signals, as short as a few microseconds, and that simply can't be recreated by software over USB without hardware support.
What you're describing sounds more relevant for something that's adding a parallel port to a modern computer?
It was quite a bit later in the history of the printer, when equipment started to expect 2-way communication with printers - obtaining information about the model, ink levels, paper status etc - generally that type of equipment had printer drivers for each model of printer.
We would have liked to implement something along those lines, but there is very little information (if any) about the status messages passed from the printer back to the equipment (it is not covered in the ESC/P2 documentation for example as that was last updated in 1990).
Edit: s/port/printing/
CNCs with MachCNC software and lots of old industrial equipment operated this way since it saved money on custom PCB designs. BART [1] still buys older motherboards with parallel ports wired to the south bridge because USB adaptors can’t guarantee timing and swapping to a PCIe card would require rewriting some old stuff.
However it has to be done at the driver level, it wasn’t Postscript or GCode or something like that, so I doubt this piece of gear will be anywhere as useful as parallel ports used to be.
Devices that do that often have very tight timing requirements - since original 1990's era computers could respond to a change in a pin change in as little as a few clock cycles.