gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

Coding > Keypad IRQ?

#92576 - devmelon - Thu Jul 13, 2006 11:41 pm

Hello. I'm in the middle of writing a basic wrapper around some of the functionality in the GBA. Im wondering how the Keypad IRQ works. The GBATEK has little information about this :/

http://www.work.de/nocash/gbatek.htm#keypadinput

Do you only get interrupts when a button is pressed? Not released? Is it continous or does it only get interrupted on a state change?

Thanks for your interest.

#92929 - poslundc - Sat Jul 15, 2006 6:24 pm

Without having used the key interrupts much, I'm pretty sure the interrupt fires whenever the requested keys are in the down state.

So if I set it to trigger when A and B are held down together, and the interrupt triggers, if I keep the keys held down they will trigger again the moment I clear the current interrupt.

For the record, it is a very bad idea to use interrupts for general input polling. Pretty much the only place I would ever recommend using it is for allowing a reset combination (eg. A+B+Start+Select). I've heard the argument for high-velocity DDR games and whatnot to use them as well, but I don't really buy it.

Dan.

#92936 - tepples - Sat Jul 15, 2006 7:09 pm

poslundc wrote:
So if I set it to trigger when A and B are held down together, and the interrupt triggers, if I keep the keys held down they will trigger again the moment I clear the current interrupt.

No they don't, at least not on a Game Boy Advance. They trigger once or a few times (due to key bounce), and then they don't trigger again for a given key until you release it and press it again.

Quote:
Pretty much the only place I would ever recommend using it is for allowing a reset combination (eg. A+B+Start+Select). I've heard the argument for high-velocity DDR games and whatnot to use them as well, but I don't really buy it.

If you don't use interrupts for a game that needs really precise input timing (e.g. DDR or Street Fighter), you'll need to poll at 180 Hz using vcount ISRs.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#93126 - Ant6n - Mon Jul 17, 2006 3:06 am

tepples wrote:
... you'll need to poll at 180 Hz using vcount ISRs.


do games actually read the keys that often? do you have recommendations for how often people should poll for different types of games?
anton

#93288 - devmelon - Tue Jul 18, 2006 10:52 am

Heh, our game polls it once a frame. We had a discussion about wether or not to use IRQs, but we thought that if it was to fire IRQs all the time, it wouldn't be worth it. The main reason to why we are interested in IRQs is that they work very well with our OO design. But if they work as tepples mentioned it, we might have to reconsider. Although, we're interested in sensing when a key is lost (released) aswell, so I assume we have to do the standard polling. But tieing it with hblank interrupt (it's not a very fast game) might actually cut what we're trying to achieve. Or a timer irq. What do you guys propose? Should we go on polling the registers each frame or make some sort of interrupt scheme? We're using subscriber patterns for callbacks. And no whine about overhead with C++ please. :)

#93325 - tepples - Tue Jul 18, 2006 5:41 pm

A relatively slow game should be able to get away with polling. All NES games used polling.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#93621 - Ant6n - Thu Jul 20, 2006 4:40 am

i was once thinking it could make sense to enable keypad irq's, but once one fires it should be disabled for the next couple of microseconds (using timer irq) to get rid of the key bounce effect. that way one could have very fast key response. But still, if the keypad doesnt recognize an 'up', then i guess it don't matter...

#93624 - tepples - Thu Jul 20, 2006 5:49 am

My anti-bounce solution is to allow the keypad ISR to push a key down (and timestamp it with VCOUNT), but only recognize released keys using polling (which shouldn't be bouncy).
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#93639 - keldon - Thu Jul 20, 2006 9:17 am

tepples wrote:
My anti-bounce solution is to allow the keypad ISR to push a key down (and timestamp it with VCOUNT), but only recognize released keys using polling (which shouldn't be bouncy).


i thought of something similar too. will say when i dont have ice cream in one hand