Main > Main Forum
USB vs PS/2 vs COM vs LPT
Driver-Man:
--- Quote from: AndyWarne ---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.
--- End quote ---
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.
MonMotha:
--- Quote from: Driver-Man on September 26, 2010, 05:29:53 am ---
--- Quote from: MonMotha ---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).
--- End quote ---
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.
--- End quote ---
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.
--- Quote from: Driver-Man on September 26, 2010, 05:29:53 am ---
--- Quote ---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.
--- End quote ---
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?
--- End quote ---
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.
--- Quote from: Driver-Man on September 26, 2010, 05:29:53 am ---
--- Quote ---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.
--- End quote ---
- "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?
--- End quote ---
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.
--- Quote from: Driver-Man on September 26, 2010, 06:00:58 am ---
--- Quote from: AndyWarne ---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.
--- End quote ---
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.
--- End quote ---
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.
Driver-Man:
--- Quote from: AndyWarne ---OK here you go: http://www.microsoft.com/whdc/archive/usbcompat.mspx?pf=true#E2C
--- End quote ---
Touché!
Figure 1. Architecture for Legacy Support for USB and PS/2
Figure 2. Architecture after the operating system takes control
CONGRATULATIONS!!! The winner is you!
And, bonus points for diagrams. Thank you.
Driver-Man:
--- Quote from: MonMotha ---If you think that document says that emulation is left on while Windows is running, you're not reading it right.
--- End quote ---
You were telling the truth after all, but points go to AndyWarne. You are informative indeed, but at the end Andy won with single elegant hit, right between Driver-Man's eyes, oouch! In any case, I thank you too. -- Perhaps it was unreasonable for me to ask for such evidence, but at least we established one more point, slightly less relevant now when we can obtain actual real-world measurements with the software tools such as 'keyboard testers" and "USB sniffers". Your persistence was not in vain, but the battle goes on.... with great power comes great responsibility!
--- Quote ---
--- Quote ---Anyway, do you accept 'Passmark keyboard test' as "benchmark" program to settle this argument?
--- End quote ---
Looks like it's probably a native Win32 application, so NTVDM is not in play.
--- End quote ---
I'll take that as a "yes".
--- Quote ---You'll note that 1/125th of a second is 7.87ms. 7-8ms of lag is consistent with a 125Hz polling rate.
--- End quote ---
Let's also make a note that is what it is, and that's ONE KEY per 8ms. -- Your "pipe" can be big and wide, but if there is only a tiny hole at the end where "water" can come out (heh), then that little hole is what will define the maximum "flow rate", hence the name "bottleneck".
We are looking for the bottleneck and USB protocol is not it, move on. My USB sniffer says USB keyboard does indeed transfer 8 bytes long packages, so that can probably do 6 keys at once, and 2 bytes for modifiers, I guess.
HOWEVER, that 8 byte "USB buffer" does not get copied as bunch to some "usb keyboard buffer", but each byte goes to port 0x81, which is pretty much USB equivalent of PS/2 port 0x60. The point is, "entrance" to keyboard buffer is one byte wide again, and that is the "bottleneck".
--- Quote ---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.
--- End quote ---
Ok, you can send as many as you like as often as you like. But, of what use is that if you need to plug each byte separately, one by one, to port 0x81, and possibly even wait until application (OS) clears the port before able to put another scan code in, just like with PS/2 and port 0x60.
This is why it is important that we establish benchmark software for READING the input. According to "Passmark keyboard test", regardless of 8 bytes per 8ms, it still can still read only ONE KEY in that time-window, or so it says.
=====
And, for the love of drugs, why has no one taken my "dramatic persona" as a joke? What in the world is so offensive about me fooling around with "Spider-Man" spoof? It's allegory, it's a joke, it's to make it more interesting for me, to add some drama and provoke response, to see if anyone will come up with some interesting come-backs.... But that was only 2%, and Saint saw that. He was smart enough to see through my "theatricality", and wise enough to allow it continue for the sake of information. I admire that. Thank you Saint.
Marsupial:
--- Quote from: Driver-Man on September 26, 2010, 11:28:19 am ---
--- Quote from: AndyWarne ---OK here you go: http://www.microsoft.com/whdc/archive/usbcompat.mspx?pf=true#E2C
--- End quote ---
Touché!
Figure 1. Architecture for Legacy Support for USB and PS/2
Figure 2. Architecture after the operating system takes control
CONGRATULATIONS!!! The winner is you!
And, bonus points for diagrams. Thank you.
--- End quote ---
What, you needed drawing to understand/believe what's been said and referrenced all along???
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version