Gp2x Joystick Exposed - The Internals

[scorpio]

Hi,

These intermediate direction are very narrow and are ignored by most software. It's safe to assume that they just don't exists. There is a small improvements using DaveC's scheme 5 but it's really improves handling only marginally.

I would like to reply to your points tomorrow after I've had a chance to install Python and try out your code.

Apologies if I came across earlier as disregarding your work, but I've only just got my broadband back after a couple of weeks of jerking around with ntl, and I've been on a kind of GP2X information overload for the last day or so! Sorry if it seemed I was ignoring your ideas, I'd read it all and taken it on board, but it's all a bit of a blur at the moment... I think I'm actually starting to care about this platform, and I don't even have my own one yet!

(FWIW, my thoughts on my preference for the GP2X are in my intermittent blog at www.xdi.nu)

 

[Epicenter]

Hm, still waiting on my Gp2x so I am unable to comment on what I think of the stick's operation in 4-way games or 8-way games. However, it seems to me the best course of action I can take in the top-scrolling shooter engine I'm writing is to use all 16 directions. In any case, it'll mean the most precise control of any shooter I've ever played. That seems the most effective way to avoid the quirks of this stick-- it's quite simply a stick made for its own breed of games, not games for consoles with an entirely different means of control.

That said, since I do plan to run my share of emulators on the machine, it'd be excellent if a solution was worked out to take the edge off the problems with poor precision in games made for a 4-way D-Pad... I'm sure a good solution will arise if everyone has patience and doesn't catastrophize the situation.

 

[GP40]

Couldn't you use a slim plastic washer (or maybe just thin plastic) and something like http://tinyurl.com/rsm5m inbetween the joystick contact and the body contacts. You could draw whatever contact shapes you wanted on the top side then? :unsure:

 

[nickspoon]

I've started tweaking OpenGlad2X code for case configurations... I hope I can get that released at some point, it keeps locking up for some reason. I've added extra response on the ordinals (can't remember what case config that is), and it seems to be responding better. Thanks Hanz for the SDL2X ref.

On a related note, DaveC's cap arrived today, and the difference is amazing. It looks great and works great too, though the drawings in the manual went right over my head for the most part, not being a hardware guy Thanks Dave.

 

[Ravnos]

I hope the manual is better than the one for the Afterburner.

 

[scorpio]

Following up on my comments earlier about the joystick, I've finally had a chance to try the python scripts by Radek, and the tester by Miquel, and I have to admit I can't really see the time filters working as they stand now. However, that's only in the context of a pure input-to-screen demo, perhaps if it was implemented in a program then that might be able to prove the theory to conclusion, one way or another.

(As an aside, after re-reading this thread for the umptheenth time, I also noticed that ant512 had already mentioned reshaping the contactor in the switch before I had. I wish there was a way of just dumping a whole thread into a PDF so I could print it out to read when I'm awake!)

"joytest" was a strange one. I couldn't get the binary to work - I got a black screen for a second (even though the PNGs were in the data directory) and then it dropped back to the menu. So, I took the plunge and installed the devkit, code::blocks, all the libs, and then recompiled it. It built with no errors or warnings, which I was happy with, and at least this time it came up with the layout screen, but just hung there.

I upgraded the firmware to cramfs 1.4 (kudos to the oddbots!), and it made no difference. Tried it again when I got home this evening and still no luck, so I put some debug "fprintf()"s throughout and tried again, and it worked! I took the debug stuff back out and recompiled, and now it still works. I haven't a clue what's going on there! Teething troubles I think. It always takes a little time to get used to the quirks of a new platform I suppose.

Anyhow, I think that case 2 is closest to how I personally want the stick to work, but it's still too biased towards the diagonals for my liking.

I now think a big part of the problem is that there is no tactile or audible feedback from the controller that lets me know that the stick is now selecting a different direction, so in most games (e.g. Gradius) while I'm trying to keep banging the fire button and select the power-up, my ship has suddenly hit the ground or part of the scenery. That's bloody frustrating (excuse the language, please), and not part of the experience I'm looking for.

Reluctantly, I'm going to have to side with Radek on the total replacement of the stick. I say reluctantly, because ideally you need something which requires minimal modification, to encourage the largest number of people to do it. If we have to end up ripping out the existing joystick, and then bodging in a d-pad or a custom 4-way mini-microswtich affair (after all, why not?), how many GP2X owners out there are going to do this, or pay someone the extra to do it for them? I know if I was going into this cold, and though I was going to have to make a major hardware mod just to be able to play games properly, I'd probably pass on it and try and make do with my PSP or DS.

Radek, in the circuit you made, you're using 8 AND and 4 NOR gates? I think you could get by with 4 AND and 4 triple-input XOR gates, which should help reduce the component spread. Perhaps a PLD or GAL may be more suitable as an end-user component, if it was to prove popular? I was also wondering if the logic could be powered from the controller switching voltages, reducing the need for fly leads to the voltage supply, and this would hopefully minimise power consumption.

I don't know about anyone else, but I could care less about the switch under the stick. Most of the time it gets pressed by accident anyway, as you really have to push on the stick to make sure it doesn't slip.

I'm also thinking of casting a copy of a GBA d-pad out of polymorph (low melting-point thermoplastic) as a quick test, to mount on the brass stick. Then I hope to also build up a cross-shaped surround to go around it to restrict its motion. Hard to explain, but if I get the time to do it, I'll post pics should anybody be interested. I'm thinking that there should be enough freedom on the two axes to allow the stick to hit diagonals when you need to, but not so much as to have the slop that the current configuration has.

I don't get much time to do any of this, so it's mostly a few hours here and there during the week, and the last thing I want to have to do when I get home is to use my brain again! I hope to be able to get something done by the weekend.

Perhaps it's time to dig out some of my game ideas from 15-20 years back for some inspiration!

This is all assuming that anybody is interested in my ideas, and that I haven't just repeated what somebody said in another thread!

PS. Ravnos, did you try an Afterburner mod yourself? I was never happy with mine, and it shows a very bad horizontal moire pattern for some reason. :-(

 

[DaveC]

I've started tweaking OpenGlad2X code for case configurations... I hope I can get that released at some point, it keeps locking up for some reason. I've added extra response on the ordinals (can't remember what case config that is)

​

It is case 2. It basicaly narrows the diagonal target to the smallest possible. Because of the size of the contacts the stick normally has a diagonal bias. This is Alps fault, I don't know why they designed it that way. No control devices other than the arcade game Q*bert has a diagonal bias. When case 2 is used there is not much bias and all 8 logical zones are close to equal. All sticks and pads have ordinal bias on emulated sysems with digital controls though so it still could improve if the stick ass'y was rotated 45° but that is a different story.

 

[Ravnos]

PS. Ravnos, did you try an Afterburner mod yourself? I was never happy with mine, and it shows a very bad horizontal moire pattern for some reason. :-(

​

No, I bought one but as soon as I opened the package I lost one of the pieces. I'm probably going to pick on up again here, though. I like my original GBA more than the SP and the controls are better laid out for GBA games than my DS. Even with a bad horizontal pattern it has to be better than the dark screen as is.

 

[Radek]

Following up on my comments earlier about the joystick, I've finally had a chance to try the python scripts by Radek, and the tester by Miquel, and I have to admit I can't really see the time filters working as they stand now. However, that's only in the context of a pure input-to-screen demo, perhaps if it was implemented in a program then that might be able to prove the theory to conclusion, one way or another.

I suggest then to get the Castaway Atari ST emulator and try to play Prince Of Persia in it. Then go back to my timegate (not the timegate3 - it's overcomplicated junk - I myself I can not really setup it properly!) and set the "dynamic gating" to half and "diagonal relase" to half too. Now try up -> right movement (for an example) and you will see that upper left diagonal will not get registered unless you stay at it for moment longer.

Such behavior would (I think) improve handling games what are using upper diagonal for jumping tremendously. For now in games like PrinceOfPersia it's rather tormenting than actual playing...

(As an aside, after re-reading this thread for the umptheenth time, I also noticed that ant512 had already mentioned reshaping the contactor in the switch before I had. I wish there was a way of just dumping a whole thread into a PDF so I could print it out to read when I'm awake!)

"joytest" was a strange one. I couldn't get the binary to work - I got a black screen for a second (even though the PNGs were in the data directory) and then it dropped back to the menu. So, I took the plunge and installed the devkit, code::blocks, all the libs, and then recompiled it. It built with no errors or warnings, which I was happy with, and at least this time it came up with the layout screen, but just hung there.

I upgraded the firmware to cramfs 1.4 (kudos to the oddbots!), and it made no difference. Tried it again when I got home this evening and still no luck, so I put some debug "fprintf()"s throughout and tried again, and it worked! I took the debug stuff back out and recompiled, and now it still works. I haven't a clue what's going on there! Teething troubles I think. It always takes a little time to get used to the quirks of a new platform I suppose.

Anyhow, I think that case 2 is closest to how I personally want the stick to work, but it's still too biased towards the diagonals for my liking.

I now think a big part of the problem is that there is no tactile or audible feedback from the controller that lets me know that the stick is now selecting a different direction, so in most games (e.g. Gradius) while I'm trying to keep banging the fire button and select the power-up, my ship has suddenly hit the ground or part of the scenery. That's bloody frustrating (excuse the language, please), and not part of the experience I'm looking for.

Reluctantly, I'm going to have to side with Radek on the total replacement of the stick. I say reluctantly, because ideally you need something which requires minimal modification, to encourage the largest number of people to do it. If we have to end up ripping out the existing joystick, and then bodging in a d-pad or a custom 4-way mini-microswtich affair (after all, why not?), how many GP2X owners out there are going to do this, or pay someone the extra to do it for them? I know if I was going into this cold, and though I was going to have to make a major hardware mod just to be able to play games properly, I'd probably pass on it and try and make do with my PSP or DS.

Radek, in the circuit you made, you're using 8 AND and 4 NOR gates? I think you

My final design is using 8 dual input NAND gates and 2 dual inputs NOR gates.

I can do the same using 8 NAND gates plus one 1 quad input AND gate (9 gates)

I was thinking about other configurations as well however there always have to be 3 DIP14 chips anyway.

I'm after FOUR different version of PCB boards too. I was really thinking about it to make it optimal as possible.

Below is an image of the first prototype:

It does fit inside GP2x without problems.

could get by with 4 AND and 4 triple-input XOR gates, which should help reduce the

I was thinking about that too - still 3 DIP14 chips needed.

component spread. Perhaps a PLD or GAL may be more suitable as an end-user component, if it was to prove popular? I was also wondering if the logic could be powered from the controller switching voltages, reducing the need for fly leads to the voltage supply, and this would hopefully minimise power consumption.

My design is powered directly from batteries in the GP2x. It can work just from 1.5V and thankfully so because connecting to the built in GP2x's voltage regulator could complicated everything.

There is another possible aproach what would be just one chip. But I haven't such one and could not test it (it's DIP24). But it might be worse because it has much more gates inside, solidstate switches and couldn't have so wide tolerance for voltages.

Anyway my circuit could be much smaller using double sided pcb and SMD chips.
(assuming there would be demand and it's small enough already as it is)

I will risk to say it's optimal enough.

The other options are eproms and microcontrollers but they might not work powered directly from two AA (to little voltage) and would be more expensive, would eat more energy possibly too.

 

[SpinaL-TaP]

What about using only one 4 to 16 multiplexer chip?

My design is powered directly from batteries in the GP2x. It can work just from 1.5V and thankfully so because connecting to the built in GP2x's voltage regulator could complicated everything.

Can you explain why it would be more difficult to use the output of the regulator of the GP2x?