Here comes a mostly true simplification. Printers speak an extremely low level protocol of "Once the printer ready pin indicates the printer is ready, load up

Here comes a mostly true simplification. Printers speak an extremely low level protocol of "Once the printer ready pin indicates the printer is ready, load up one byte of data across 8 pins, smack a pulse out that says yo here is another valid byte, wait a bit, then repeat until you run out of data in the buffer to print". This is actually not too far from how parallel port hardware and port driver OS software worked. In practice the hardware ends up as something like 10 general purpose TTL IO ports, in fact in the REALLY old days our NON-integrated parallel printer ports used actual 8 bit latches like you'd see on memory busses from S-100 cards and stuff. Not the abstract concept of a latch but an actual TTL DIP chip like a 74LS373 or whatever printers use (I don't remember inverting or not or whatever) Newer hardware is way more complicated and "automated" and "buffered" but at some level the original PC compatible API locked down how low level it had to be and you have to be able to at least pretend you're GPIO to be "IBM PC Compatible". Standards being a great idea there are of course at least four SPP, EPP, and some others that spec'ed slightly more advanced but whatever. So the high level protocol PLUS industry monopoly compatibility meant if you sell it as "IBM PC compatible" its gotta be able to speak at a 10+ pins of general purpose IO level. The USB replacements do something different and appear to be printers and can no longer implement general purpose IO they implement "print a character" at the USB level not bit fiddling. I've not written a USB driver for a printer (on either side) so I'm a little fuzzy but what I've heard second hand is the USB level lives at an abstraction of "here's a packets worth of UTF-8 stream" Note that there were weird situations for RS-232 serial where you'd synthesize signals by weird pulsing of DTR leads or CTS or whatever that can be pretty well messed up by transitioning to a USB implementation of "heres a bit stream". I guess another way to look at it, is its easier to maintain compatibility across hardware generations for a single stream of bits so serial has it easy, whereas parallel was always a mismatch of high level byte transfer vs GPIO in the same system. The USB emulators only mass market making a printer work, not concerned about providing 10 or so pins of GPIO. There is other fun... to a first approximation (aka its untrue) no one implemented multipoint networks on parallel ports. So latency was approximately zilch and much hardware hacking relied on that. USB of course is shared and totally non-deterministic and just maintains a long term average bandwidth. So trying to synthesize a beautiful sine wave works fine on actual hardware, not so well over a jittery USB. Its very much like the technical challenge of output sound to a local sound card vs stream VOIP across the public internet, which is really hard.