The Joy of Buttons.

[Arne]

Just before falling asleep I got a mysterious idea to do an Amiga 500 joypad with as many buttons as possible, and without using ICs (mcu/mux/sh.reg) inside the joypad. Unless I made a fundamental mistake it looks like about 7 buttons might possible by using various tricks. This is a compact design so the center nub is reachable (about as far in as a 360 right nub).



I'm not that familiar with the Amiga's joy/mouse port limitations, but there are two unused pot/analog pins going off to Paula. Some binary-value resistors could split them into two buttons each, giving L&X, R&Y. Finally, a multiway switch could enable a regular analog stick instead for driving/flying games (this would disable LXRY).

Afaik the pot values are packed into a 16-bit word so they're only 8 bit each, likely a smaller range due to calibration, +noise. I read that using the pot lines can also mess with the mouse... somehow, maybe?

Obviously this type of joy would require a game programmer to:

• Deal with analog stick calibration stuff (deadzone, offsets, edge limits). I don't think analog nubs were a thing back in 1985. Ideally the calibration would be stored in RTC memory or something so it only has to be done once in a while.

• Unpack the two buttons from the analog value (4 possible combinations). I did this for my handheld project:
http://androidarts.com/EE/Buttics/GameThing.htm
Possibly the buttons might need calibration as well because components and cables are not ideal. Using only two buttons per pot might be safe though. I've used 3-4 but that's with a 1024 level MCU ADC.

• Handle impossible directions for Pause and Menu. Because these type of buttons are not used in play, it doesn't matter that they disable the +pad. I wonder if the V-drop from the diodes will cause problems reading a digital press...

Few/no old games would work with the analog stuff, but UDLRF are wired as normal, except that some old game might go bonkers when Pause or Menu are pressed. But, this project was more about pushing the old port to the limit.

Amiga 500 schematics for reference:
http://androidarts.com/Amiga/AmigaSch2_50.jpg
...scanned from the A500 manual which came with my A500 (rev6A), which was kinda cool but I didn't understand any of it back then. Now, just a little.

It seems UDLR*2 has 4.7K pullups & goes to a 157MUX.


Fire buttons goes to a 8520 CIA. I see no pull-ups (supposedly has internal ones). 100pF maybe for debounce (UDLR gets none but maybe a directional doubletap matters less or the read freq. via mux deals with it).

I see no pull-ups around Paula for the four pots so I'm guessing 5V has to be used hooking the potentiometers up in a kind of standard way. In the Amiga the pot lines got 0.047uF to audio gnd, but also 100pF to normal gnd... maybe for debounce as these are also buttons. Possibly it softens the noise in Paula's ADC?

There's much EMI filtering and I understand none of it.

I'm a bit scared to actually build this even though it's very simple breadboard stuff (I've only done UDLRF sticks so far). Really don't want to mess up some analog current limit or short a line. Also no clue how to access Paula's pots in AMOS for debug purposes. Maybe Deeking some locations?


To finish with a detour, here's a floppy-case in DVD format:

[robinsonb5]

Originally Posted by Arne

Possibly the buttons might need calibration as well because components and cables are not ideal. Using only two buttons per pot might be safe though. I've used 3-4 but that's with a 1024 level MCU ADC.

The buttons probably will need calibration too - also bear in mind that the analogue counters are dependent upon screenmode. As long as a game's running in PAL or NTSC then it'll be consistent, but doublescan screenmodes will give different results. (The counters count how many HSyncs it takes for a capacitor to charge.)

• Handle impossible directions for Pause and Menu. Because these type of buttons are not used in play, it doesn't matter that they disable the +pad.

The original Minimig used this trick to encode its menu button, if memory serves.

I wonder if the V-drop from the diodes will cause problems reading a digital press...

I think that would be more likely to be a problem on the PotX/Y lines if you were using them in digital mode.

I see no pull-ups around Paula for the four pots so I'm guessing 5V has to be used hooking the potentiometers up in a kind of standard way.

There are pullups, but they're internal to Paula, and enabled when using the pins as digital inputs (i.e. mouse buttons)

Also no clue how to access Paula's pots in AMOS for debug purposes. Maybe Deeking some locations?

I think you'll need a vblank interrupt in order to read the POTs reliably. See http://amigadev.elowar.com/read/ADCD.../node0186.html

To finish with a detour, here's a floppy-case in DVD format:

Now that I *really* like!

[Daedalus]

The idea's generally pretty sound, a couple of points to note:
- The analogue pins are used for an analogue joystick, naturally enough, but also for the right mouse button / button 2 (pin 9) and middle mouse button / scroll wheel (pin 5)
- For analogue mode, the pots aren't connected to ground, but float. It's essentially the resistance that's measured by Paula, not the voltage.
- In analogue mode, analogue sticks use the D-pad inputs as button inputs, which will potentially produce the same "impossible" input patterns as the menu and pause buttons, as will a mouse plugged into that port
- For 2-button compatibility in games, it might be nice to have a fallback to using pins 6 and 9 for the two buttons
- The lack of pull-ups is because all three of those pins can be used as outputs as well as inputs. Pull-ups are enabled via software. This could be used to harness the inputs in different ways, for example building a keypad matrix-style controller. Such a setup could potentially allow up to 12 inputs (8 buttons + D-pad), without resorting to reading and interpreting the analogue values.

[Arne]

Super-thanks for the nice info, both!

So, in digital pot button mode if I support that, I'll have to count on Paula's internal pull-ups being up so the joy's button circuit then would only need to be button-to-ground? I saw a schematic which recommended a current limiting resistor to ground for the pot buttons. The multiway switch would need a third position for this but I think it's doable. I don't know what will happens if the joy is in the wrong mode (my analog mode) though.

If using a matrix, I'm assuming it'll also need a few diodes to prevent ghosting/snake-around like on keyboards. I wonder if driving the matrix would require less or more CPU than an analog decode (easy on an MCU but here it's complicated by the scan rate thing and calibration). I don't know what the frequency would be for scanning a matrix. Would also have to work with the MUX reads I guess.

Would this schematic make sense for a Matrix? Since buttons are normally high I'm assuming the in/outputs would sink, each in order?

The Pot trimpot works a bit like a resistor in a 555 circuit if I understand you correctly.





Edit: New schematic... everyone floats now. It seems to me that adding the digital pot button mode means that the XL&YR switches will have to be double contact or things get real complicated. Conductive rubber pads will kind of mush any traces together but I think a flex PCB might work as it allows for some trace isolation. A flex PCB can also be folded up 90deg for the LR buttons, unless those are cheap side mounted tact switches or micro switches. SNES-clone pads use a daughter PCB.

[Adrian Browne]

Cool idea

[Arne]

Maybe cool, maybe insane.

I've edited previous post/image. Had to do a test to see if it all fits on the PCB, and it does. No ICs needed, but since 3D3T sliding switches are quite massive and possibly hard to source, I'm considering some sort of IC or transistor solution, but I'd rather not.

Analog thing and top 90° LR switches are from a 360 controller I ref'd. The 360 LR buttons are a plastic long spring. The rubbers are held in place not by pins going through the PCB, but by the button tubes. I'm sure it's all patented despite not being all that novel.

[robinsonb5]

I have to say the art style in these designs is superb!

I wouldn't use current limiting resistors on the POTX/Y pins in digi mode, because those pins are finicky - on some A1200 motherboards in particular there were problems with microcontroller-based mouse adapters because they couldn't pull those pins low enough to register a button press.

[Arne]

I saw a suggestion of 2-3K for current limiting the digital pots, but maybe it varies by platform/chip. I think I have plenty of space for through-hole components, which would be more moddable. Maybe I can provision for both SMD and through-hole... Edit: Did so.

[BeamCoder]

Interesting! Always wanted to see a direct pin controller with more than 2 buttons.

I assume that since this is direct pin this will have less input lag than a cd32 controller gamepad mode?

Edit:
Just a thought, why not use pins 1,2,3,4 as buttons LRXY, and pins 5,9 as dpad in digi mode and joystick in analogue mode, in that way in analogue mode you could still use LRXYF instead of just F. I don't know if the pause/menu button would still work though. A problem also is this would be incompatible with all amiga games(unless you're ok with using LRXY as directions).

This idea came into my mind because of the dual stick controller being made by the Abstraction guys where they use the dpad pins for action buttons(or maybe its actually the joystick, can't remember)

[ Show youtube player ]

[Arne]

I suppose if you use Pot X,Y in digital mode you get no center value?
__1
0_?_1
__0

In analog mode on mine, the +pad and F can be used in conjunction. Perhaps the +pad could be used to shift gears in driving games. (The center analog nub can be used by either thumb). I also made the analog nub clickable but it won't be useful for Fire spam and taking the thumb off the analog means lost control. Unfortunately the shoulder buttons become unusable in analog nub mode... it would be handy to have those as then you have +pad, analog nub and L1 R1 shoulders at your fingertips. In theory one could add more physical shoulder buttons, second shoulders mapped to say Fire and Up/Jump (or just Left and Right, in which case you can keep the right thumb on the true Fire button and left thumb on the analog nub, whilst using L2/R2 to powerslide/turret turn).

[BeamCoder]

That's a nice example of utilizing the controller for new types of gameplay.

I hope by the time these new controllers come out, there would be Amiga games that use these as the minimum requirement for playing the game. Current Amiga games still go for 4 + 1/2 button scheme as there minimum requirement even when there is already a CD32 which have 6 buttons. I believe this is a factor to what makes SNES/Megadrive games better just because of having more buttons(therefore more actions) regardless of the graphics/sound/power capabilities.

[Bruce Abbott]

Originally Posted by BeamCoder

I hope by the time these new controllers come out, there would be Amiga games that use these as the minimum requirement for playing the game.

What a fantastic idea! Let's makes games which only work on a custom-made controller that you can't buy and probably doesn't work.

I believe this is a factor to what makes SNES/Megadrive games better just because of having more buttons(therefore more actions) regardless of the graphics/sound/power capabilities.

Having more buttons makes them worse, not better. It took me ages to get used to the buttons in the PlayStation version of Tomb Raider, then Crystal Dynamics took over and changed them. The PC version just uses the keyboard, with a sensible mapping which can be reassigned to suit your tastes. So it doesn't have analog sticks - big deal, they just got in the way on the PS controller.

A good game should be controllable with a minimum number of buttons. The CD32 controller has more than enough, is an Amiga standard, and the only Amigas that need it are the CDTV and CD32 (all others have a keyboard). The chips in the CD32 controller are not exotic or hard to use, so why try to make a controller 'without using ICs' when it will end up being more complicated and harder to get working properly?

[BeamCoder]

Originally Posted by Bruce Abbott

What a fantastic idea! Let's makes games which only work on a custom-made controller that you can't buy and probably doesn't work.

I would assume if the game is made to play with a custom made controller then the controller should already be available and works. Even without the custom made controllers, I guess many have a CD32 controller already?

Originally Posted by Bruce Abbott

Having more buttons makes them worse, not better. It took me ages to get used to the buttons in the PlayStation version of Tomb Raider, then Crystal Dynamics took over and changed them. The PC version just uses the keyboard, with a sensible mapping which can be reassigned to suit your tastes. So it doesn't have analog sticks - big deal, they just got in the way on the PS controller.

A good game should be controllable with a minimum number of buttons. The CD32 controller has more than enough, is an Amiga standard, and the only Amigas that need it are the CDTV and CD32 (all others have a keyboard). The chips in the CD32 controller are not exotic or hard to use, so why try to make a controller 'without using ICs' when it will end up being more complicated and harder to get working properly?

It depends on the game genre I suppose. I got used to playing fighting games on a 6 button layout like Street Fighter or a 4 button layout like Tekken. Compared to Shadow Fighter which is a 1/2 button fighting game, SF and Tekken just had a lot more options of attacking/defending just for the fact it has those 2~5 extra buttons.

I would actually be fine with playing on a keyboard, sometimes I'm lazy connecting my arcade stick when playing on PC and just use the keyboard. Some people want to play on a controller though and CD32 is one of their options.

Most people probably are already used to the 4 right thumb buttons games so I don't think it's a bad idea to implement a game with at least 4 buttons as a minimum requirement.

[Arne]

Honestly I feel like two thumb buttons are fine. Like Bruce here, I can't deal with 4 in the -:- orientation. I guess the reason I don't like them is because there is no distinct main or home/rest button (CD32 addressed this a bit with a larger button). However, moving the thumb around causes it to get lost so, to speak (am I just too old?). I don't think games should use a ton of buttons either, but one is not enough and I do think it harmed playability.

Shoulder buttons are a great alternative to extra thumb buttons as they can be used in conjunction with +pad and Fire. They're great for tank controls, dashing, or maybe weapon/item switching and such. They're also spatially distinct. You don't always know where your thumb is and it can be difficult to map that with actions, but there's no mistaking L&R index finger. So, I think a +pad, L1,R1,Fire button could've been fine.

I don't really count Start/Select type buttons as clutter because they're not used in main play. On the Amiga you sometimes had to let go of the joy to hit some key, so that what those buttons would be for.

Keep in mind that my joystick design here should be compatible with existing games in regards to plain old +pad and fire, and possibly games which support digital pot buttons in which case L1/X,L2/Y becomes available, so you have the option of using either the shoulder or thumb buttons. Afaik, the way I wired up the analog nub (with the help from people here) for that mode might also make it compatible with the existing old flight sim games but I'm not sure how well those would control with a nub.

What is not compatible with existing games is the third mode which splits up shoulders and thumb buttons, but you don't have to use it, or Pause&Menu.

---

ANYWAYS: Guess what I found in a closet? It's a six button joystick - the Quickjoy V SUPERBOARD SV-125!


Yeah, well, so that's just one button and an egg-clock. It looks like they had support for separate B/A button groups, maybe for some other platform. Autofire is 41,27,17Hz according to Mr Multimeter. Is that 150 Ohm on the (B&A) Fires? The sliding switches just switch between which groups are functions... kind of weird. The egg-clock really is quite nice.


---

///// EDIT /////
I built a prototype. Then I realized something which likely kills the analog button concept. When I built a similar circuit recently I used an MCU. I was worried that maybe button bounce would affect the values from the voltage divider but it seemed very reliable. An MCU samples pretty quickly, but as I've learned in this thread, it actually takes some time for the Amiga pot caps to go brrr. So, if a pot is polled and a button press comes or leaves in the middle of the frame, then the count will be off and that will decode wrong. I'll have to skip that mode or replace with something more traditional.

[Bruce Abbott]

Originally Posted by Arne

So, if a pot is polled and a button press comes or leaves in the middle of the frame, then the count will be off and that will decode wrong. I'll have to skip that mode or replace with something more traditional.

More traditional - like that 'button' on your prototype?

[Arne]

^Pressing these small tact switches with your soft fingertips doesn't work well. Sticking something on top works... okay. Here I added a button with a pivot point in green stuff underneath, and it behaves similar to an actual +pad.

I gave up on the analog buttons as it might not work, and added a CD32 circuit instead, and even a little 555 autofire circuit.



Looking at the schematics, official and otherwise, it doesn't seem like the CD32 would enable XP/9 as a button like it does with Fire(6) in legacy mode. Seen it mentioned though. The DPDT solution is a bit peculiar but I wanted to use only a single type of switch for sourcing and space reasons.

Yes, this pad doesn't have as many buttons as the CD32 pad, but I don't really care for that kind of layout like already mentioned. I don't want more thumb buttons but it might be possible to squeeze in miniscule L2, R2 bottom tact buttons for emergencies (kind of indented and hard to press by mistake).