GP2X Need Gp2x Joystick Help Not Using Sdl Or Other Sdk


buster2000

Still Fresh
Joined
Feb 25, 2006
Messages
3
I'm currently porting a software 3D engine to my GP2X writing directly to the framebuffer.
Nothing fancy just a spinning textured and lit cube that I did in turbo pascal some years ago.
The problem is I don't have a clue how to get input from the GP2X without using SDL or some other SDK.
I need a way of detecting input so that I can quit back to the menu otherwise the only way I run my program is to stick it in an infinate loop meaning i need to switch off and restart to exit. I'd really apreciate some help finding out how to poll the inputs so that I can just exit back to the menu.
 
Have you looked at Rleyhs Miniaml Library. I think it has some functions to get input.
 
There's two ways to do it... read 4 bytes from /dev/GPIO (the last 2 bytes have the state information, you can play around with it and figure out the mask), or you can read them from the memory registers at 0x1186>>1, 0x1184>>1, and 0x1198>>1 ... when you read it from /dev/GPIO the bits are set when the respective button is pressed, and when you read it from the registers.. the bits are set when the respective button is not pressed. Here's what the memory registers look like:

GPIOD | GPIOC | GPIOM
10000000000000000000000000000000 STICK CLICK
00001000000000000000000000000000 VOL +
00000100000000000000000000000000 VOL -
00000010000000000000000000000000 Y
00000001000000000000000000000000 X
00000000100000000000000000000000 B
00000000010000000000000000000000 A
00000000001000000000000000000000 RIGHT SHOULDER
00000000000100000000000000000000 LEFT SHOULDER
00000000000010000000000000000000 SEL
00000000000001000000000000000000 START
00000000000000100000000000000000 UP-RIGHT
00000000000000010000000000000000 RIGHT
00000000000000001000000000000000 DOWN-RIGHT
00000000000000000100000000000000 DOWN
00000000000000000010000000000000 DOWN-LEFT
00000000000000000001000000000000 LEFT
00000000000000000000100000000000 UP-LEFT
00000000000000000000010000000000 UP

Mind you that it is actually the opposite in memory.. you have to use the tilde (~ ones compliment -- to swap the bit values .. for convinence).

You'll get the above result doing something like this:

~(((mem[0x1186>>1] & 0x08C0) << 20) |
((mem[0x1184>>1] & 0xFF00) << 10) |
((mem[0x1198>>1] & 0x00FF) << 10));
 
What are all the bit shifting on the mem registers for?
int mem;
unsigned short uMem;
mem = open("/dev/mem", O_RDWR);
uMem=(unsigned short *)mmap(0, 4*sizeof(unsigned short),PROT_WRITE, MAP_SHARED, mem, 0);

is this the four bytes you mean?
 
The numbers are memory address offsets, but you're accessing them through an array of 16-bit integers. Dividing the offset by two is necessary in that case because the compiler will multiply up by two again behind the scenes.

I don't much like that system - in Allegro I just used an inline function or macro (not sure which at the moment) which does the maths itself. e.g. *(unsigned short *)((int)uMem + register_offset). It feels cleaner this way, to me anyway.
 
Back
Top