That page basically says that, since the BIOS supports legacy emulation of USB devices upon startup and this would conflict with Windows talking to USB devices directly, Windows has to kick it out of the way so that it can talk to USB devices directly. Look at Figure 1 and read the section "Operating System Takes Control of the OHCI Host Controller" (there is also one detailed for UHCI controllers).
No. That is not really about Windows, but any OS. It says that OS has the choice to use BIOS drivers, if present. It also says PS/2 emulation is within SMM, which is transparent to the operating system and application software, and so this functionality stays as a part of whatever higher-level operation is wrapped around it.
Yes, PS/2 emulation happens within SMM. The SMM takes data from the USB HCI and dumps it into the emulated port 0x60 interface. However, that document also details how Windows disables this emulation so that it can take control of the USB HCI directly. A different procedure is used for OHCI and UHCI, but both processes result in the same thing: SMM emulation is disabled (by causing the USB HCI to never generate any SMI signals to activate it) and the OS (whatever it is, in this case Windows) can talk to the HCI directly.
If you think that document says that emulation is left on while Windows is running, you're not reading it right.
I'm guessing the process differs some now that EHCI (and whatever USB 3.0 uses) is around, but it's still the same concept: the "real" OS disables SMM emulation of legacy keyboard/mouse for USB keyboard/mouse so that it can take direct control over the USB HCI. The OS is then responsible for handling all USB devices, including HID boot protocol keyboards and mice, on its own. The OS will still ask port 0x60 for actual PS/2 keyboard data.
Basically, any DOS application you run on modern (meaning less than 10 years old) Windows is running inside an emulation layer. This means that attempting to extrapolate basic underlying system behavior from the behavior of a DOS application running on said modern Windows OS will give misleading and even irrelevant results.
How about this "Passmark keyboard test" from www.passmark.com, AndyWarne was talking about?
I get minimum of 7-8 ms lag between each scan code sent with USB keyboard. With PS/2 keyboard this lag is 4-5 ms. That comes down to about two keys per frame @ 60FPS. And so, I was right after all, at least as far as my own computer goes. -- I also tried several "USB sniffer" programs, and according to this little investigation I see key codes are always transmitted one by one, and there are all sorts of lags and two-way communication going on in between each packet.
Anyway, do you accept 'Passmark keyboard test' as "benchmark" program to settle this argument?
Looks like it's probably a native Win32 application, so NTVDM is not in play.
You'll note that 1/125th of a second is 7.87ms. 7-8ms of lag is consistent with a 125Hz polling rate. This is the forced polling rate for low-speed USB HID devices in Windows. Most keyboards are low-speed, so Windows will poll them at 125Hz regardless of what they otherwise may ask for.
I'm not surprised that PS/2 keyboards are slightly less laggy than a 125Hz polled USB keyboard. While the PS/2 keyboard clock is usually only ~100kHz (less than 1/10th the bit clock of even low speed USB), the keyboard controller has a real interrupt to signal the CPU with, so it can potentially get data there very quickly once it is received.
Note that Andy says his IPAC keyboard encoder has a polling rate of 500Hz. Since the IPAC is a full speed device, Windows will use the polling rate specified in its descriptor. A 500Hz polling rate would mean one poll every 2ms or about 4 times faster than a normal keyboard. I'd be interested to see the passmark lag results for an IPAC or other HID device with a faster than typical polling rate.
Note also that games (especially arcade games being emulated in MAME) only check the inputs at a certain rate, regardless of how often new input data may be available. For arcade games, this is typically once per frame. Since the framerate is usually ~60Hz, as long as new data is available at least that often (and 120Hz+ would guarantee it), there's little to be gained from higher polling rates or lower input lag.
The parallel port is handy if you don't want to buy anything, are willing to do a fair bit of software hackery, and only need up to 13 inputs. Beyond that the matrixing/multiplexing required makes it inferior to dedicated, multi-input encoders in terms of either complexity or having ghosting issues.
- "are willing to do a fair bit of software hackery,"
Not true, many emulators have this driver built in, plus there are "joystick" OS specific drivers for Windows, Linux and DOS. This is mature and very well tested interface enjoyed by many people who know about it, for the last 8 years or more.
- "and only need up to 13 inputs."
TGXLPT sets the maximum number of inputs, 9x7 = 63.
- "Beyond that the matrixing/multiplexing required makes..."
8 bits at the time, gathering 24 inputs in just three instructions...
Did you not say that is exactly how arcade games originally did it?
I didn't say that it was slow or had high overhead (in fact, I specifically mentioned that it can be a very low latency interface and at least hinted that application can be electrically simple, but of course you neglected to quote any of that). I said that it is more complex than many users will want to deal with. You say that TGXLPT is built into many emulators, and while that may be true, you have to go to some trouble to make raw parallel port access work on WinNT (to include XP). This is more trouble than some users may want to deal with. In fact, I can only find references to using MAME with that TGXLPT interface when running MAME on DOS, but it may support it on Windows provided the user goes to the trouble of enabling raw port access or installing a 3rd party driver. USB (and PS/2, for that matter) keyboard encoders are literally plug-and-play.
What I meant by matrixing or multiplexing is that either external multiplexors (ICs) are required or a matrix has to be built to handle more than 13 inputs. The tgxlpt interface you linked to is a matrix. If you don't use a butt-ton of diodes, a matrix will quickly have problems with ghosting (potentially any time more than 2 inputs are triggered). Many users don't want to wire up a ton of diodes, and I don't blame them. Matrixes are fine when ghosting is not an issue, e.g. on a TV remote control, but we generally don't use them on arcade controls for this reason.
Either a digitally multiplexed or a matrixed solution will require more IO instructions to read the whole thing. For your tgxlpt interface you seem to adore, you read 5 inputs at a time (on the status port) then 4 inputs (on the control port) and have to manipulate the data port to scan the matrix. Each group of 5 inputs requires 3 IO instructions plus potentially a brief spinloop delay (wasting CPU time) to let the matrix settle (this may or may not be required depending on stray capacitance and how fast IO instructions actually run on your CPU). So, to read all 63 inputs (the 7 groups of 9) requires at least 7*3=21 instructions plus instructions required to correct polarities and re-pack the data into 8-bit variables if desired. Not that any of this really matters given how fast CPUs are, these days. The issue with multiplexing and matrixing is really more of a physical implementation hassle.
OK here is a USB bus analyzer trace. This is the result of pressing 5 keys at the same time. Note the 2ms time intervals, and the fact all pressed keys (5 keys) are sent together.
I did not respond to this earlier because I did not see any time intervals in that screen shot there (1st page). -- It never occurred to me before we can sort all this out without any arguments actually. AndyWarne was right to come along with such testing tools, I wish I paid more attention to that before, as that's the easiest and most reliable source of information, especially since no one believes the word I say, for some reason, and what's even better such software will tell every one about their specific situation with their own particular computer.
Anyhow, if we forget about everything else, 2ms intervals between each scan code would give you about 8 keys per frame max @ 60FPS, if you are not using arrow keys that is. However, releasing or *TAPPING* buttons, just as using arrow keys, will emit double scan codes, which can leave you with less than 8 keys per frame. -- Perhaps that's "good enough", but if it is 2 keys per frame like on my computer, well that's not "good enough", not for me anyway.
You're reading it wrong. Every 2ms, a HID report frame is transferred to the host. This report frame contains a large number of scancodes. In the trace Andy posted, 5 scancodes were sent every 2ms, and there's plenty of unused positions (having NULL 0x00 data) in the report (it's cut off on the display, even), suggesting that the device could send quite a few more. USB HID devices do not send key up/key down events for each key like a PS/2 device does; they instead send a "report" every time they are polled that lists the entirety of the keys pressed (up to a maximum limit). The IPAC sends this report every 2ms (or rather tells the host to request the report every 2ms, which it does). They can do this because USB is pretty fast (1.5Mbps or 12Mbps) compared to the PS/2 AT keyboard interface (~10-20kbps).
Thus, there is NO limit on the number of keys pressed per frame other than the number of keys the device can handle being held down at once. While this number is typically 6 for conventional keyboards as that's what is used in boot protocol mode, it's possible to make a device where this limit is "the number of keys physically present", and I believe Andy has said that this is how the IPAC is set up. Thus, the IPAC could handle you simultaneously pressing every input on the encoder in one 2ms interval (good luck!) then releasing them all simultaneously just 2ms later (again, good luck!). How HID reporting works is all detailed in the USB HID specification we've all been asking you to read. Clearly, you haven't done so.
Home
Help
Search
Login
Register
Send this topic
Print
Topic: USB vs PS/2 vs COM vs LPT (Read 101056 times)
