(2021, June 2) Just before falling asleep I got a mysterious idea to do a stock Amiga 500 compatible joypad with as many buttons as possible, and without using ICs (mcu/mux/sh.reg) inside the joypad. It looked like about 7 buttons might possible by using the two analog lines to get 4 additional buttons. However, there's a problem with this. Unlike an MCU, the Amiga uses a capacitor charge counter system to measure variable resistors. This process can last a frame or so. What if half the time passes then a button state changes, starting or stopping the count. Then the count will be off. So, the system likely won't be reliable. I realised this late when doing this page and had to redact. I put in a CD32 circuit instead, but with a simplified thumb button area as I'm no good with 4 button arrays. This is a compact design so the center nub is reachable (about as far in as a 360 right nub). SNES pad for scale. I can't really fit anymore buttons unless I add another shoulder level (L2, R2, or Ears as C= called them).
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. Fire goes off to a CIA. These three special pins can be configured by the Amiga and are used by the CD32, but you can also support other circuits in software. I added a switch which enables a regular analog stick instead for driving/flying games (this would disable L1,R1,X,Y). I never saw any analog sticks which also had say 4 buttons for the normal directions, but maybe it was done.
My Pause and Menu buttons uses the two impossible +pad directions.
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.
• Handle impossible directions for Pause and Menu and decode as extra buttons. Because these type of buttons are not used in play it doesn't matter that they disable/corrupt the +pad. I wonder if the V-drop from the diodes will cause problems reading a digital press...
Only flightsims supported an analog stick, but UDLRF are wired as normal, except that some old games might go bonkers when Pause or Menu are pressed. But, this project was more about pushing the old port to the limit before it derailed. I added a mode for supporting digital mode buttons for the pots but removed it when going for the CD32 circuit, as it uses Fire, XPot, YPot. Those needed to be rerouted through a DPDT switch, or preferably a 4PDT but those are harder to get so I opted for a mechanical solution using two switches. It's cheaper to buy components in bulk (on tape, and less tape types speed up manufacturing) and the little SMD switches are cheaper. There's a little 555 autofire thing too. It's a circuit that I built for other projects, using a wheel for speed adjustment. I ran out of front board space and couldn't add pads for supporting other ICs like muxes. The traces could be laid out in a bus structure like I did on my general purpose NES pad PCB.
Amiga 500 schematics for reference: IMG LINK ...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 (internal when in digital mode, someone said). The potentiometer charges a capacitor at varying speeds and this makes the ADC counter go. In the Amiga the pot lines got 0.047uF to audio GND (maybe these are the analog counter caps, somewhat small, which explains why the paddles need a 500K pot (possibly arcade boards used this system too?). There are also some 100pF to normal GND... maybe for debounce as these are also buttons. Possibly it softens the noise in Paula's ADC? Screen mode affects the ADC counters as the count builds up during a blank.
There's much EMI filtering and I understand none of it. The long joystick cords can pick up interference and I think stuff like ferrite beads filter that, and there were also strict regulations at the time for radio emissions.
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. I don't know what the appropriate resistor values might be yet. Also no clue how to access Paula's pots in AMOS for debug purposes. Maybe Deeking some locations? A clue. AMOS is open source now afaik, and it seems someone updated it with potgo. By adding through-hole as well as SMD pads, and maybe exposed points on the back of the PCB, it could be quite moddable.
Since Fire and the Pot pins can be configured as in/out in software, it's apparently possible to make a matrix with UDLR but you'll lose the analogs then.
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).
Proto board rocking some buttons. The "+pad" sits on a pivot point and is sewn in place. Unfortunately I have no 500K pots in stock atm, and there's no easy way to "multiply" one. I also don't have double point buttons which could be useful. Four-legged tacts join all of the legs. Could use narrow ones side by side, but it'll double-click.To finish with a detour, here's a floppy-case in DVD format:
I got this joystick for free long ago and thought I could make it work with the Amiga (which isn't mentioned on the box even though a datecode says 88 and the serial 89). However, something about it didn't work and I've forgotten what it was. Perhaps I expected it to support multiple buttons, but looking at it now I see... well... let's take a look at the box first:
Wow, look at all these features! Six buttons! Four sliding switches! And a DISPLAY!
I opened it up as a kid and never put it back together, losing the screws. The switches seemingly look nice. The buttons push on a spring, kind of like a microswitch. Single-sided PCB with jumpers. Note that the display thing is not connected to the joystick itself, but has a little piezo speaker.
The buttons have springs. While the top of the base has a fake (plastic) rubber ring, the bottom half actually does have a rubber ring.
Now to the meat of this beast. But is it a beast? No, it's all bark and no bite. The display is just an egg clock and has nothing to do with the joystick, such as displaying autofire BPM, settings or such. The buttons... are all the same button. That's right, this is a 1 button joystick, but the sliding switches can select which buttons are... currently functional? That's what it looks like. Likely it was designed for systems with more buttons, then downgraded for the Atari standard. Aside from being divided in Left and right and stick groups, the buttons are also divided in A (upper, thumb) and B (lower, index), each with their own 150r... uh, limiting resistor? It's not consistent which part of the switches is Common GND.
In Atari mode, 5V goes to some transistors and caps which I'm guessing is the autofire circuit. It appears the stick sliding switch turns it on regardless of whether any button is held. The circuit doesn't go GND/NC like a mechanical button, but LOW, HIGH using the 5V supply. The speed options are (according to my multimeter, I didn't scope it) 17Hz, 27Hz and 41Hz, the latter so fast it looks like PWM dimming on an LED. I think a lower Hz setting could've been more useful, for games which are sensitive to spam. But maybe 41Hz was useful in sports type games or when the extra spam assured a shot came at the earliest possible frame.
CPC 464 mode leaves 5V unconnected. That pin can be used as a second fire button but here they didn't bother to support that from what I can tell.
I noticed a solder splatter blob crossing two tracks so maybe that was a problem, despite the (Q.C.PASSED) sticker.
The plug confirms that this is indeed not wired for Pot X & Y, which are either used as digital buttons or analog paddles.
In conclusion: I suppose this joystick would be easy to modify, cutting and rewiring a few traces. With a new cable it could be given 2-3 Amiga buttons. Or, one could wire everything into a 32U4 MCU, turning it into a USB or whatever joystick... pointless as it would be. A more practical use would be as a fancy looking alarm ~ a conversation piece ~ It can do 1-99 minute ranges.
This is a gameport joystick I got for using with the terrible mid-late '90s racing games that came bundled with home PCs.
Look at the size of this. Well, I suppose it has to be sturdy to handle a stick rather than a nub. It uses 100K potentiometers (perhaps standard for gameport) with calibration offset nubs on the outside. Kind of offloads some of the burden on the game developer because writing calibration UI stuff is a real chore. Some modern analog sticks are voltage dividers using all three pot pins, but here, like in the Amiga, only the two pot pins are used (giving a single resistor value). The gameport used a similar capacitor counter circuit as the Amiga/Atari but apparently the polling implementation was shit like with all things PC, resulting in significant CPU load.
The auto-righting mechanism uses a single spring and a center stop. The axis cradle system seems similar to the modern ones. There's an autofire IC-blob in the handle.