| Main > Main Forum |
| I-PAC / Keyboard Encoder polling rate? |
| << < (3/6) > >> |
| Beley:
--- Quote from: TheManuel on May 30, 2003, 04:01:16 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. --- End quote --- 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:
--- Quote from: Beley on May 30, 2003, 04:46:09 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 --- End quote --- 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? |
| toilet:
--- Quote from: TheManuel on May 30, 2003, 04:01:16 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. --- End quote --- 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:
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:
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->) |
| Navigation |
| Message Index |
| Next page |
| Previous page |