Main Woodworking Reviews Software Monitor/Video Maximus Arcade
Audio/Jukebox/MP3 Project Announcements Artwork Consoles Buy/Sell/Trade Meet Up
Arcade Miscellaneous Everything Else Politics n Religion Forum Discussion Wiki Discussion GroovyMAME
DOS/WinCab Merit/JVL Touchscreen Automated Projects Driving & Racing Project Arcade Old Boards
Linux Restorations Pinball MaLa Frontend controls.dat Old Archives
    Retail Vendors    

Unread posts | New Replies | Recent posts | Arcade | Rules | Chatroom | Wiki | File Repository | RSS


  

Author Topic: I-PAC / Keyboard Encoder polling rate?  (Read 2477 times)

0 Members and 1 Guest are viewing this topic.

toilet

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 104
    • Briefcase Emulator
I-PAC / Keyboard Encoder polling rate?
« on: May 27, 2003, 02:37:11 pm »
Does anyone have any numbers on the I-PAC or generic PS2/USB keyboard encoder polling rates? I'm looking for the actual sampling rates of the devices (40Hz, 125Hz, etc.). If anyone knows anything or has any relevant links I'd appreciate hearing them. Thanks.

Tiger-Heli

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 5422
  • Ron Howard? . . . er, I mean . . . Run, Coward!!!
    • Tiger-Heli
Re:I-PAC / Keyboard Encoder polling rate?
« Reply #1 on: May 27, 2003, 03:42:20 pm »
Does anyone have any numbers on the I-PAC or generic PS2/USB keyboard encoder polling rates? I'm looking for the actual sampling rates of the devices (40Hz, 125Hz, etc.). If anyone knows anything or has any relevant links I'd appreciate hearing them. Thanks.
The I/Pac's page mentions a 16-character buffer, so it can accept keypresses faster than the PS/2 (or USB) port can process them.  I don't know the actual speed.  The KeyWiz says it has a 12Mhz processor, uses a 72-character buffer, and would need more than 500 keypresses per second before you would get stuck or dropped keys.
It's not what you take when you leave this world behind you, it's what you leave behind you when you go. - R. Travis.
When all is said and done, generally much more is SAID than DONE.

BeBoxer

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 20
  • I'm a secret agent!
Re:I-PAC / Keyboard Encoder polling rate?
« Reply #2 on: May 28, 2003, 12:46:08 pm »
The I-Pac information page says that it is interrupt based, so it doesn't poll at all. There is of course some limit to how fast it can process inputs, but those limits aren't as simple as just looking at a polling rate. And since the thing was designed from the ground up with MAME in mind, I'd guess that you would have to be mashing the buttons pretty fast to get it to drop any inputs. And even then it might be a limitation of the PS/2 port, not the I-Pac.

IIOIOOIOO

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 295
Re:I-PAC / Keyboard Encoder polling rate?
« Reply #3 on: May 28, 2003, 02:21:50 pm »
Or maybe he just wanted to know the polling rates :)

qaotik

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 17
  • The only way to fly..
Re:I-PAC / Keyboard Encoder polling rate?
« Reply #4 on: May 28, 2003, 02:34:24 pm »
Wow that thing might be worth the extra money then. But how easily can you get to the limits of usb? Since if i someday go worth the trouble and make a cabinet for myself id like to know all the inside stuff and know that it doesnt get any better than this setup. :P

Oh i have also a follow up question because i dont quite undestand these tecnical terms so well. All i know is that ps2 mouses refreshing rate is about 60hz and that usb mices have 120hz but with programs like ps2rate for windows 98 you can tweak the ps2 to go 200hz however it doesnt do it consistently. So would it be possible to build something to do it much higher?
« Last Edit: May 28, 2003, 02:54:20 pm by qaotik »

paigeoliver

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 9957
  • Awesome face!
Re:I-PAC / Keyboard Encoder polling rate?
« Reply #5 on: May 28, 2003, 11:56:34 pm »
Wow that thing might be worth the extra money then. But how easily can you get to the limits of usb? Since if i someday go worth the trouble and make a cabinet for myself id like to know all the inside stuff and know that it doesnt get any better than this setup. :P

Oh i have also a follow up question because i dont quite undestand these tecnical terms so well. All i know is that ps2 mouses refreshing rate is about 60hz and that usb mices have 120hz but with programs like ps2rate for windows 98 you can tweak the ps2 to go 200hz however it doesnt do it consistently. So would it be possible to build something to do it much higher?

How fast did most REAL games poll the controls anyway?
Acceptance of Zen philosophy is marred slightly by the nagging thought that if all things are interconnected, then all things must be in some way involved with Pauly Shore.

Beley

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 116
Re:I-PAC / Keyboard Encoder polling rate?
« Reply #6 on: May 29, 2003, 01:42:13 am »
my understanding of the keyboard port (ie motherboard) is that it dosent poll, when a key is pushed( or you let go of a key) it triggers an interupt(int 1 to be exact) only then is the kb port polled to see which key(s) has been pushed/unpushed, the same goes for a ps2 mouse.

toilet

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 104
    • Briefcase Emulator
Re:I-PAC / Keyboard Encoder polling rate?
« Reply #7 on: May 29, 2003, 08:47:44 am »
Hey thanks. I'm more concerned about sampling rate with regards to the game engine. CPS/2 games are 60Hz. There are a lot of Capcom figthing sitautions with small 1-3 frame windows. Although still doable under emulation, my consistency is not at the level it is at the arcade.

If I remember correctly from my glquake, m_filter, and PS2Rate days, PS2 mice on Win9x were 40Hz and USB 125Hz. In WinXP there's a tab under the mouse control panel where you can set the sampling rate for a PS2 mouse. Not that this is really applicable, just thought I'd throw it out there.

u_rebelscum

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 3633
  • You rebel scum
    • Mame:Analog+
Re:I-PAC / Keyboard Encoder polling rate?
« Reply #8 on: May 30, 2003, 02:59:29 am »
How fast did most REAL games poll the controls anyway?

Usually once a frame, during the V_blank period.  For most games that's ~60 hz, since most games ran close to 60 hz video refresh rate.  Some games had 30, 45, 53 hz or close to those numbers video refresh, though, so those games' polling would be at the same speed.
Robin
Knowledge is Power

TheManuel

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 689
  • On and off hobbyist
Re:I-PAC / Keyboard Encoder polling rate?
« Reply #9 on: May 30, 2003, 04:01:16 pm »
CPS/2 games are 60Hz. There are a lot of Capcom figthing sitautions with small 1-3 frame windows.

Maybe I'm not getting it right but, how can you possibly time something to take an action within a 1 to 3 frame window? At 60Hz, that is 17 to 50 milliseconds.  That would be inhuman.
"The Manuel"

Beley

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 116
Re:I-PAC / Keyboard Encoder polling rate?
« Reply #10 on: May 30, 2003, 04:46:09 pm »
Maybe I'm not getting it right but, how can you possibly time something to take an action within a 1 to 3 frame window? At 60Hz, that is 17 to 50 milliseconds.  That would be inhuman.

its not human of course, its a computer, lets say it uses a 4mhz clock, 4,000,000/1=250 nanoseconds, that’s 1 clock cycle every 250 nanoseconds, if each instruction for the cpu takes between 1-10 clock cycles (most are 2). so lest say 4 on average, that’s 1 microsecond, using your 17miliseconds, that gives time for 17,000 instructions , more then enough time to check which keys have been pushed

TheManuel

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 689
  • On and off hobbyist
Re:I-PAC / Keyboard Encoder polling rate?
« Reply #11 on: May 30, 2003, 05:07:36 pm »
its not human of course, its a computer, lets say it uses a 4mhz clock, 4,000,000/1=250 nanoseconds, that’s 1 clock cycle every 250 nanoseconds, if each instruction for the cpu takes between 1-10 clock cycles (most are 2). so lest say 4 on average, that’s 1 microsecond, using your 17miliseconds, that gives time for 17,000 instructions , more then enough time to check which keys have been pushed

I know the computer can do it, smart pants  ;).
What I'm questioning is, what is an example of a game situation that requires a precision of a couple of frames?
What can the player can do in such a short span?
"The Manuel"

toilet

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 104
    • Briefcase Emulator
Re:I-PAC / Keyboard Encoder polling rate?
« Reply #12 on: June 01, 2003, 12:04:23 am »
Maybe I'm not getting it right but, how can you possibly time something to take an action within a 1 to 3 frame window? At 60Hz, that is 17 to 50 milliseconds.  That would be inhuman.
It's not. Reversal windows are 1-2 frames depending on the version, off the ground grabs are 3 depending on character. Won't get too technical but there is some forgiveness built in, but getting the button presses in those small windows is doable if you play it enough.

AndyWarne

  • Trade Count: (+18)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 1638
    • Ultimarc
Re:I-PAC / Keyboard Encoder polling rate?
« Reply #13 on: June 01, 2003, 05:52:02 am »
This is not an easy question to answer. The I-PAC uses an interrupt method which detects a pressed key and sends it to the PC without any polling. It can do this because it has one microcontroller pin per input so it does not need to poll around looking for keypresses. Things get a bit more complex when multiple keys are pressed because the PC may not be able to accept the presses fast enough in PS/2 mode (it probably can in USB). The keys are buffered but the buffer should never get more than 2 or 3 outstanding codes in it unless there is something wrong at the other end. So the size of the buffer is not really important if the software is working properly.
The buffer should only be needed whan keys are pressed at EXACTLY the same time.
The ability of MAME to accept the keycodes is another issue. When I was originally developing the I-PAC and looking at the PS/2 interface on the logic analyzer, I found that Advanced MAME is really slow at accepting keypresses and I even had to modify the code in the I-PAC because this version of MAME was sleeping for so long in between the two bytes of double-byte codes such as arrow keys, that the I-PAC was timing out. (in that early version, a double-byte code was one single buffer entry).
Back at the encoder side, another issue is de-bounce. There needs to be a limit on how quickly sucessive presses of the SAME key are sent. So after pressing a key, we send it but if we get any activity on that key for 30 milliseconds we ignore it. Otherwise we would have multiple key repeats all over the place owing to switch bounce. The important thing is that we should still send OTHER keys during this time. This is a big issue with fighing games and about a year ago, a regular on this board looked at this extensively and did some testing which revealed some deficiencies in some encoders, although newer arrivals probably don't have this problem.

RandyT

  • Trade Count: (+14)
  • Full Member
  • ***
  • Online Online
  • Posts: 5560
  • Friends don't let friends hack keyboards.
    • GroovyGameGear.com
Re:I-PAC / Keyboard Encoder polling rate?
« Reply #14 on: June 01, 2003, 05:08:39 pm »
It is becoming clear to me that a number of people here don't really understand what an interrupt is or how one works. Since it is brought up on such a regular occasion with no explanation as to the impact it has on any real-world application, I'll do my best to explain it.  You can be the judge as to whether I know what I am talking about, but I will tell you that I was one of the first individuals to put 128 animated full color sprites on the screen of a C64 at one time.  Something that is not achieveable without extensive machine level interrupt programming.  Ok, so I'm a dinosaur :).

BTW, if you do not agree with what is stated here, please do the research and provide your references.  A statement like "you are wrong, because X told me so", as happens all too often here, is not grounds for reasonable debate.  But I can't force anyone to be reasonable, so have at it if that's what winds your watch :).

This is a long one and it's going to take more than one post, so here we go.

Interrupts exist on microprocessors for a simple reason.  That reason being there are many things that the processor must do at regular intervals to keep things running smoothly, and a simple processor, by it's nature, can only do one thing at a time. Period.  Therefore, the actual code given to the processor by the user always takes second priority to the main "housekeeping" code built into the processor.  The processor regularly interrupts the user code momentarily to execute the "housekeeping" code so the processor continues to run properly.

There are also things called "user interrupts".  This inserts a vector into the processor's interrupt table (the list of things it needs to do at regular intervals) and adds the users task to the list.  This means that the user's code is executed at very regular intervals and is nested into the "housekeeping" code of the CPU.  Great caution is required when doing this however, as some of the "housekeeping" routines expect to be executed within a certain time-frame.  If the time taken to execute the user code extends beyond the time-frame expected by the "housekeeping" routines, bad things can happen, like the code going into endless loops, etc....  Similar things can be done without "user interrupts", and as most microcontrollers don't allow for these, different approaches can be taken and require the same precautions.

(continued on next->)

RandyT

  • Trade Count: (+14)
  • Full Member
  • ***
  • Online Online
  • Posts: 5560
  • Friends don't let friends hack keyboards.
    • GroovyGameGear.com
Re:I-PAC / Keyboard Encoder polling rate?
« Reply #15 on: June 01, 2003, 05:09:45 pm »
(continued)

Microcontrollers have things called "hardware interrupts".  These are usually useful features built in that can be enabled/disabled by the user code.  On the particular microcontroller talked about so much, there are a few of interest.  There are 2 time based HW interrupts, one that occurs every 128us (that's millionths of a second) and one that occurs every 1.024ms(thousandths of a second).  Come hell or high water :) any code pointed to by those start to execute at those intervals, within the restraints of the above.  If you have code to evaluate the states of the pins on a microcontroller that executes at these intervals, this is really no different than "polling".  The difference is that they will ALWAYS be polled at those intervals.

The thing that is interesting to note here is the following comparison:

A scheme that uses an interrupt to check the state of the ports at 1ms intervals, sees what is going on there at 1000 times per second, very regularly.

However, a scheme that uses a loop to scan the port at irregular intervals 2000 times a second is still going to be close to twice as fast/accurate :)


There is also one other interesting hardware interrupt available on the microcontroller in question.  This one is the "General Purpose Input/Output Interrupt".  This one is capable of generating an interrupt when ANY of the 32 I/O pins change state.  The important thing to note here is that the microcontroller DOES NOT generate a seperate interrupt for each and every pin, and therefore can't tell the user code which pin (input) generated the interrupt.  It is now the responsibility of the user code executed by this interrupt to "poll" the pins individually and decide what has changed.  At this point, well written code will examine (poll) ALL inputs and act on the changes appropriately.  During this time, no other inputs can generate a GPIO interrupt but the time a well-written piece of code will spend here is so small, it is unimportant.

(continued on next->)

RandyT

  • Trade Count: (+14)
  • Full Member
  • ***
  • Online Online
  • Posts: 5560
  • Friends don't let friends hack keyboards.
    • GroovyGameGear.com
Re:I-PAC / Keyboard Encoder polling rate?
« Reply #16 on: June 01, 2003, 05:11:26 pm »
(continued)

Also, for the sake of the "big picture", it is important to note that the interrupt for polling the inputs needs to be turned off when the processor is performing a time critical task like transmitting to or receiving from the computer (or any external device which may also be connected to the controller, such as keyboards, mice, etc.)  During this time, it is highly likely that no transitions of the I/O port would be sensed regardless of the means used to check them.


Here is another interesting comparison:

Using a GPIO interrupt, unless in "transmit", "receive" or some other "state", the microcontroller will immediately "poll" the pins to see which one (or more) of them changed state and generated the interrupt.

Using a fast-polling method, also unless in "transmit", "receive" or some other "state", the "main loop" of the code will be constantly and      very, very quickly (perhaps thousands of times per second) polling the pins to see if something has changed.

So using this example, one can see that the use of interrupts (or the lack thereof) doesn't have as large an effect on performance as limiting the amount of time spent by the microcontroller in alternate "states" where it is unable to monitor the pins.  In other words, the more time-critical functions being handled by the microcontroller, the less time it can look at the pins, as it can always only do one timing-critical thing at a time.


So to summarize, "polling" of individual input pins takes place regardless of whether the routines are executed by result of an interrupt or by a constant loop outside of one.  If a microcontroller does little outside of polling the pins when not in an interrupt service routine, the increase in performance realized will be very small, if any.  In fact, any of the methods written here will probably be able to monitor far more transitions than are humanly possible.


If anyone has any corrections, questions, or needs further elaboration on anything I have written here, you know the drill :).

RandyT



BTW, for anyone who might be interested, the max throughput of the PS/2 interface is over 1500 characters per second.  More than fast enough to keep up with just about any type of controls you could dream of throwing at it, regardless of the I/O monitoring scheme.



TheManuel

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 689
  • On and off hobbyist
Re:I-PAC / Keyboard Encoder polling rate?
« Reply #17 on: June 01, 2003, 09:41:41 pm »
This is a big issue with fighing games and about a year ago, a regular on this board looked at this extensively and did some testing which revealed some deficiencies in some encoders, although newer arrivals probably don't have this problem.

Is this newer IPac arrivals or newer encoder arrivals?
"The Manuel"

TheManuel

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 689
  • On and off hobbyist
Re:I-PAC / Keyboard Encoder polling rate?
« Reply #18 on: June 01, 2003, 09:47:06 pm »
Back at the encoder side, another issue is de-bounce. There needs to be a limit on how quickly sucessive presses of the SAME key are sent. So after pressing a key, we send it but if we get any activity on that key for 30 milliseconds we ignore it. Otherwise we would have multiple key repeats all over the place owing to switch bounce.

I insist.
Why should the 30 milliseconds restriction should be a problem for gamers?
If you can make successive presses (even for a few) within 30ms, that is a rate of 33 presses per secons.
Who the hell can do this?
"The Manuel"

Pulsewidth

  • Trade Count: (0)
  • Jr. Member
  • **
  • Offline Offline
  • Posts: 3
Re: I-PAC / Keyboard Encoder polling rate?
« Reply #19 on: April 05, 2007, 06:01:01 pm »
On Linux, it is possible to set the USB mouse polling rate, and almost all mice can work with 500Hz polling.  There's no official support for increased polling speed of other HID devices (and I assume the I-PAC is a standard HID device), but with a simple modification to drivers/usb/input/hid-core.c you can increase the polling rate for those too.  I poll my USB keyboard at 250Hz and it works perfectly, but I haven't tested other keyboards, and it's likely that it won't work with all devices.  I assume an analogous hack exists for Windows too.

Will the I-PAC work with USB polling speeds faster than the default 100Hz?

Also, is it possible to tune the debounce time, preferably with different debounce on different inputs?  30ms could be a problem when you need to tap a button for an extremely short time, as it will register as held down for at least one frame longer than it should.

BobA

  • Trade Count: (+14)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 5884
  • What Me Worry?
    • Bartop Jukebox
Re: I-PAC / Keyboard Encoder polling rate?
« Reply #20 on: April 05, 2007, 06:12:14 pm »
Pulswidth since it is your first post we will give you the benefit of nubee.   Did you realize you are responding to a 4 year old thread?   Nations have come and gone in less time.

 ;D

Pulsewidth

  • Trade Count: (0)
  • Jr. Member
  • **
  • Offline Offline
  • Posts: 3
Re: I-PAC / Keyboard Encoder polling rate?
« Reply #21 on: April 05, 2007, 06:22:55 pm »
Yes, but it seemed a waste to make a duplicate topic.

BobA

  • Trade Count: (+14)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 5884
  • What Me Worry?
    • Bartop Jukebox
Re: I-PAC / Keyboard Encoder polling rate?
« Reply #22 on: April 06, 2007, 08:59:24 am »
Good point,   I hope Randy or Andy can give you the answer as they are the experts.


AndyWarne

  • Trade Count: (+18)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 1638
    • Ultimarc
Re: I-PAC / Keyboard Encoder polling rate?
« Reply #23 on: April 07, 2007, 08:29:25 am »
The USB polling rate is approx 7ms. I am not sure any benefit would be noticed by increasing this although it could be done using the software utility. All currently-pressed keys are sent at a very high rate (compared to PS/2) so the overall bandwith is much higher although there could be a USB max latency of 7ms.
I am not sure why you would need to reduce the de-bounce time. Certainly not with standard arcade buttons since its impossible to press one button repeatedly that fast.
Note that the I-PAC (and I hope other such devices) only debounce the same button. You could press one button, then a different button, in less time than 30ms and the second would register fine.
The de-bounce does not delay the release of the button during a short press.

Andy

Pulsewidth

  • Trade Count: (0)
  • Jr. Member
  • **
  • Offline Offline
  • Posts: 3
Re: I-PAC / Keyboard Encoder polling rate?
« Reply #24 on: April 07, 2007, 11:10:15 am »
7ms polling is most likely good enough, but if it can accept 4ms polling like my current keyboard I'd be very happy with that.

If it does not delay the release of a short button press, how can it distinguish between a switch bounce and a deliberate short tap of the button?  I'm sure buttons where the switch engage position is close to the maximum travel can be pressed for <30ms if hit with sufficient speed and a relaxed finger.  This is a case of deliberately bouncing the entire button, as I don't think humans are fast enough to press a button for such a short time if they have to actively apply and then release pressure.  Of course the button would have to be carefully adjusted so unintentional bouncing is minimized.

RandyT

  • Trade Count: (+14)
  • Full Member
  • ***
  • Online Online
  • Posts: 5560
  • Friends don't let friends hack keyboards.
    • GroovyGameGear.com
Re: I-PAC / Keyboard Encoder polling rate?
« Reply #25 on: April 07, 2007, 11:25:56 am »
The USB polling rate is approx 7ms. I am not sure any benefit would be noticed by increasing this although it could be done using the software utility. All currently-pressed keys are sent at a very high rate (compared to PS/2) so the overall bandwith is much higher although there could be a USB max latency of 7ms.

And that's the difference between USB and PS/2.  At every poll, USB keyboards must always sends the state of possible keypresses, whether pressed or not, as well as other "houskeeping" data.  PS/2 sends only the changed state of a given key and is interrupt based, meaning that it sends nothing until the state of an input changes.   The speed of USB is necessary to do the same job, based on it's bulkier reporting schemes.  It isn't an automatic indicator of better performance in a device.

Also, a combo (mouse + Keyboard) device that uses 2 endpoints for keyboard data is going to need another polling interval for the mouse information, thus increasing the latency by another 7ms in those devices.  If only single endpoints are employed, then the latency gets even higher and can have a negative effect on both devices.

FWIW,  the KeyWiz doesn't have a latency (delay) anywhere near the 37ms(44+ms for a combo device?) when an input is activated.  The speed of a device has many more factors than the type of port it's designed for.

RandyT

AndyWarne

  • Trade Count: (+18)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 1638
    • Ultimarc
Re: I-PAC / Keyboard Encoder polling rate?
« Reply #26 on: April 07, 2007, 04:48:04 pm »
The USB polling rate is approx 7ms. I am not sure any benefit would be noticed by increasing this although it could be done using the software utility. All currently-pressed keys are sent at a very high rate (compared to PS/2) so the overall bandwith is much higher although there could be a USB max latency of 7ms.

And that's the difference between USB and PS/2.  At every poll, USB keyboards must always sends the state of possible keypresses, whether pressed or not, as well as other "houskeeping" data. 
This is irrelevant. The "housekeeping data" is actually 13 bytes. The speed of the interface is 1.5Mb/sec. I am not even going to bother working out how much time that takes (or indeed the full data packet) to be sent over the wire as its so short to be unimportant. Its much shorter than the time taken for one PS/2 keypress to be sent.
Quote
PS/2 sends only the changed state of a given key and is interrupt based, meaning that it sends nothing until the state of an input changes. 
I am not sure what you mean here. The only place that interrupts figure in PS/2 protocol where the keyboard controller on the motherboard would be allocated an interrupt on the CPU. The keyboard controller is now buried in the motherboard chipset and does not have its own interrupt, but shares interrupts and logic with other on-board functions. The direct nature of PS/2 went out some time ago, along with hot-pluggability.
Quote
 
Also, a combo (mouse + Keyboard) device that uses 2 endpoints for keyboard data is going to need another polling interval for the mouse information, thus increasing the latency by another 7ms in those devices.  If only single endpoints are employed, then the latency gets even higher and can have a negative effect on both devices.
This is incorrect. I could post a screen shot from a USB bus analyzer which shows that when 2 endpoints are used, each endpoint is alternately polled at 3.5ms intervals.
Quote

FWIW,  the KeyWiz doesn't have a latency (delay) anywhere near the 37ms(44+ms for a combo device?) when an input is activated.  The speed of a device has many more factors than the type of port it's designed for.
Where do you get 37ms from? I thought it was agreed that the latency is 7ms. There is no significant additional latency involved. De-bounce is not applicable on the initial key-down transition.
Quote

By the way I must apologise to all for the resurrection of this old chestnut! In fact its all quite dull as none of this would ever be noticed in gameplay but I just could not let this one go I'm afraid. I will not post anything further on this thread.

Andy




RandyT

  • Trade Count: (+14)
  • Full Member
  • ***
  • Online Online
  • Posts: 5560
  • Friends don't let friends hack keyboards.
    • GroovyGameGear.com
Re: I-PAC / Keyboard Encoder polling rate?
« Reply #27 on: April 07, 2007, 10:26:42 pm »
This is irrelevant. The "housekeeping data" is actually 13 bytes. The speed of the interface is 1.5Mb/sec. I am not even going to bother working out how much time that takes (or indeed the full data packet) to be sent over the wire as its so short to be unimportant. Its much shorter than the time taken for one PS/2 keypress to be sent.

Again, the 1.5 Mbs is the theoretical maximum for a "low-speed USB" device.  Most "low-speed" devices don't operate anywhere near that speed, nor are they required to in order to meet spec.  What would be required to know what can absolutely be expected from a "low-speed" device would be a "minimum speed" specification, which I can't seem to find. 

It's important to note that the keyboards PS/2 bus is dedicated only to a single keyboard,  so it doesn't require the scads of bandwidth USB needs to share amongst all of the other devices it can have attached to it.  Several hundred keyspresses per second can be streamed over the PS/2 bus, so bandwidth isn't an issue.

Quote
I am not sure what you mean here. The only place that interrupts figure in PS/2 protocol where the keyboard controller on the motherboard would be allocated an interrupt on the CPU. The keyboard controller is now buried in the motherboard chipset and does not have its own interrupt, but shares interrupts and logic with other on-board functions. The direct nature of PS/2 went out some time ago, along with hot-pluggability.

Sorry I wasn't clear.  Unlike USB, the PS/2 bus is "quiet" unless something has changed at the inputs, or in the rare event that the PC wants to send something like LED states to the keyboard..  The interrupt I was referring to is the one triggered at the chipset when the device (keyboard encoder) signals that it has data to send, so it is serviced quite quickly and efficiently.  Just because the functionality is buried in a chipset doesn't change the way it operates. 

Also, to my knowledge hot-plugability was never part of the PS/2 spec. so it couldn't really have "gone out".  But it has been pretty safe to do  with anything manufactured for the last 5-6 years now.  If anything, it's something somewhat recent for PS/2 :)

On a side note, another issue I've seen written regarding USB key reports is that the individual keys in the same report can't be counted on being processed in any particular order.  As the data is delivered in packetized form, the host processes it in any order it wishes.  This could give one player an inappropriate "victory" over another if the two press their buttons within the same polling interval.  USB sends multiple-key state packets serially, while PS/2 sends individual keypress states serially.  While this would probably only be a possible issue with a head-to-head type game between two human players, it's still a difference in the way the input data appears to be handled.
 
Quote
This is incorrect. I could post a screen shot from a USB bus analyzer which shows that when 2 endpoints are used, each endpoint is alternately polled at 3.5ms intervals.

Is this screen shot from your combo device or a generic one?

Quote
Where do you get 37ms from? I thought it was agreed that the latency is 7ms. There is no significant additional latency involved. De-bounce is not applicable on the initial key-down transition.

Again, sorry for not being more clear.  The next same keypress sent would take 30ms, plus whatever time was left before the next poll, up to an additional 7ms.  Agreed that this is probably not much of an issue for most games.  But while nobody could sustain constant firing at that rate, very short and quickly repeated bursts with a leaf-switch based button could be a different story.  There are also non-gaming applications (machine control, pulse counting, etc) where cycling of the inputs can and does happen at intervals shorter than 30ms.  Again, a PS/2 KeyWiz can have it's inputs cycled, on average, 4-5  times faster.

But as you said, much of the difference is "nuance" and if the user is happy with the way things are functioning for them during installation and gameplay, little else matters.

RandyT
« Last Edit: April 07, 2007, 11:31:25 pm by RandyT »

  
 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29