I meant to add this to the OP as well. What I meant by doing my own janky cable assembly to the DB15 connector on the PC - this can explain a lot of things (not all?). I used the numbers as per the pinout on the male joystick connector seen here:
https://allpinouts.org/pinouts/connectors/inp … ck-pc-gameport/

EDIT - fixed a previous error, the 5th pin from the top goes to pin 7 of the joystick male connector, which is button 2 (was previously marked NC)

I'd probably start looking at the two slide switches. The button and dpad signals will get routed through those, so dirty contacts would break things and might be intermittent. I'm guessing they're 4 pole double throw (4pdt) switches, so check resistance between the poles (probably pins in the 2nd and 5th columns) and the pins to either side. You should get 0 ohms (or very close to 0) to the pins to the left with the switch in one position, then 0 to the pins to the right with the switch in the other position.

Awesome, that's really helpful in simplifying the scenarios in my head.

Here's the rapid-shot mode (switch to bottom left) where each individual color is tied together. I also generally used the button color they're supposed to deal with.

Pin 3 goes nowhere
Pins 1,2,6,7,8 all work to make the yellow button 'B2' and not act as rapid autofire since there's no transistor involved.
Pins 10,11 go to the green button and make it act as 'B2 autofire' and are tied to Q4, works under testing
Pins 4,5 - I'm guessing it's supposed to make it act as 'B1 autofire' and is tied to Q3, but it doesn't work under testing. It's not continuous to the external cable's 6th pin from the top (from my 2nd post here)
Pin 12 goes to the external cable's 8th pin (2nd post here) but that's NC to the external cable. I'm guessing it would act as 'B4' in the other mode

What I call 'Pin 0' is the footing of the switch's external case and I'd like to say it's a ground, but it's not connected to the obvious main ground of the PCB. It also goes to the 7th pin of the external cable which is NC with regard to the male external joystick connector.

Next up, single fire mode (bottom switch to the right)...

single fire mode (bottom switch to the right)

Pins 2,3,8,9 go to the yellow button and would attempt to tie it to the 7th external cable pin from the top (2nd post here), which is NC. I'm guessing it's a failed attempt at making 'B3' work and it should go to the DB15 joystick connector pin 10
Pins 1, 5, 6 go to the blue button and make it act as 'B2' and it works when tested.
Pins 11,12 go to the green button and would attempt to tie it to the 8th external cable from the top (2nd post here), which is NC. I'm guessing it's a failed attempt at making 'B4' work and it should go to the DB15 joystick connector pin 14

Thoughs on B1: it's always associated to the red button and is never routed through that switch, so it only depends on ground and what should be 5 V, but it's getting less because of its connection to a...faulty Q3? This can also explain the blue button's refusal to work in rapid-fire mode (presumably 'B1 autofire').

Mu0n wrote on 2021-09-07, 19:44:

Thoughs on B1: it's always associated to 'B1' and is never routed through that switch, so it only depends on ground and what should be 5 V, but it's getting less because of its connection to a...faulty Q3? This can also explain the blue button's refusal to work in rapid-fire mode (presumably 'B1 autofire').

Hi, Q3 is a transistor, yes ? 😅
- I'm asking, because sometimes in German schematics both xtals and switching transistors are using the "Q" symbol,
while ordinary transistors for amplification etc are using "T".

If it's a pipolar transistor, I'd desolder it and measure it with a multimeter or one of these multi testers..

Edit: I'm using one of these: https://www.youtube.com/watch?v=07FH6tjzwWg

It has a colourful LCD and with the graphics does remind a bit of a tricorder from Star Trek Next Generation.. 😉

Anyway, I don't mean to mess up your thread.
You may already know these things, but I wasn't sure, so I replied nevertheless.

I wish you good look. This thread/topic has been very interesting to read so far.
I think it's cool that the classic Gravis Gamepad gets some attention, also. 😎

I've just realised that the problem may be in the cable, given how many N/C connections there are. My guess is that the 4 digital inputs on the gameport are used for the 4 buttons, then 2 of the x/y axis analogue inputs are used for the dpad (e.g. 0V for Left, 5V for Right, software decides if a threshold has been passed to count as an input).

So, numbering from pin 1 at the top of the header to pin 8 at the bottom, and using what you've already tested, then my guess for connections to the gameport dsub15 would be:

1Header Gameport Function
2 1        1     Vcc
3 2        3     X-axis (L/R)
4 3        6     Y-axis (U/D)
5 4        4     Gnd
6 5        7     Button B
7 6        2     Button A
8 7       10     Button C
9 8       14     Button D

Try unplugging the cable from the header on the PCB, then testing to see what pins on the header connect to what pins on the gameport connector. I'm not sure about the order of the buttons, and it may also be worth checking for any connections to pin 11 and 13 on the dsub15 in case it's using the second set of the analogue inputs.

I'd need to draw out the schematic from the PCB to actually understand what's going on, but I don't know when I'd be able to do that.

Wiring my own external cable is next on the list.

In-circuit testing, I find:
Q1 and Q2 (tied to the dpad) are PNP MPS3906 transistors, and both unidirections work as intended.
Q3 and Q4 (tied to autofiring) are NPN MPS3904, both unidirections work.

I'm putting off doing some other stuff, so drew up the schematic instead...

I put the values you have for the the two resistors and the capacitor around the 555 in to this calculator: https://www.allaboutcircuits.com/tools/555-ti … stable-circuit/ and that gives a frequency of 10Hz. So given various tolerances then your measure 8Hz doesn't sound too far out.

The dpad is using the analog inputs, pulling them to +5V through either 0, 1 or 2 47k resistors. How the resistance gets sensed on the PC side probably varies, but you should see the voltage change from +5V when pushing Down, something lower when pushing Up, and something halfway between when not pushing either.

The resistor networks (RN1, RN2) are arranged as 3 47k resistors, between pins 1&2,3&4,5&6.

Mind that I've only quickly drawn the schematics so there will be mistakes, particularly around the transistor pin numbering (they seem to be back to front), and I've drawn the resistor networks and the 4pdt switches as separate components, so the numbering is a bit off. Hopefully it helps with the troubleshooting, although I'm still thinking the cable/connectors are the problem.

[edit regarding the dpad schematic: One day I'll learn to add up. 47+47 is of course 94 and not 96]

Haha, wow. That should drive me all the way through the finish line. Saves me a ton of time for the dpad section which I was going to verify later. Thanks!

When I have time, I'll attack the homemade header cable.

I cut the cable right after the right angle bend near the exit inside the case, and tested all the wires in the remaining section. Yup, the problems were probably in that area. To make sure it wasn't a weird crimping problem inside the plastic header casing, continuity was verified on both sides now that it is isolated. Works.

Nice, I just had to fix the same type of thing in my headphone cable.
Though I have found some older cables do get brittle, I haven't noticed it with my gravis gamepad. The break point looks like just where the controller could've got tugged or moved around a lot? There's certainly not much to go wrong in that controller otherwise 😀

after soldering the wires directly on the pins of the exposed socket, I ran into 2 issues:

-horiz and vert were reversed, so there's a small mistake to fix in the table that was suggested by snufkin (see bottom of this post)
-B1, B2 didn't work

I noticed the green cable was dangling loose, so I fixed that, and swapped the white and yellow cables. Everything seemed to work....until a few minutes later, well after everything was screwed together, B1 refused to work, no matter what.

so I poked, prodded, checked continuity and I came to the conclusion as to why this button in particular is so difficult: the cable was probably wrapped tight very often, creating cracks in one or more places, some wires being affected more than others. If you don't wrap your cable right, twists occur and after close to 30 years, that's gotta create problems. For a more robust solution, I'm going to have to buy a male DB15 connector and some quality wires inside a flexible protective outer cable one of these days. The quick and dirty solution is to unravel the cable and attempt to find a twisty-position that makes it work. Currently, I revived the cable just fine and everything works as it should.

Thanks for all the help you guys provided!

1
2Header Gameport Function
3 1        1     Vcc
4 2        3     Y-axis (U/D)
5 3        6     X-axis (L/R)
6 4        4     Gnd
7 5        7     Button B (blue)
8 6        2     Button A (red)
9 7       10     Button C (yellow)
10 8       14     Button D (green)

Mu0n wrote on 2021-09-10, 04:43:

-horiz and vert were reversed, so there's a small mistake to fix in the table that was suggested by snufkin (see bottom of this post)

Doesn't everyone hold game pads vertically?
At least I got it the right way round in the schematic. I think.

For a more robust solution, I'm going to have to buy a male DB15 connector and some quality wires inside a flexible protective outer cable one of these days.

Since it's 8 core, if you've got an ethernet patch cable lying around then you might be able to use that. Crosstalk might be a issue causing phantom button presses, but it's not like the original cable kept any connections screened off so I think it'd be ok.

Good work fixing it, now what do you play with it?

I must humbly admire the amount of effort and investigation folks are willing to dedicate to fix a rather common (and rather crappy) gamepad. 😀

Congratulations on a job well done. 👍

I mean:

1)you can't deny it's a classic and it's absolutely iconic for early 90's pc gaming

2) electronics and investigation is *chef kiss*

As for what I'll use it for: there are plenty of games where left/right is used and not up/down, like many of those Apogee sidescrollers. I tried it with Duke Nukum [sic] yesterday and it was fiiiine.

Mu0n wrote on 2021-09-10, 13:52:

1)you can't deny it's a classic and it's absolutely iconic for early 90's pc gaming

Indeed I cannot. That's why I went and got one myself quite a few years back, even though I never use it and can't stand gamepads in general. 🤣

Mu0n wrote on 2021-09-10, 13:52:

I tried it with Duke Nukum [sic] yesterday and it was fiiiine.

Oh, yeah, I also have that version where they temporarily changed the name to 'Duke Nukum' to avoid "infringing" on the Captain Planet villain. I still prefer Duke Nukem II. 😁

And actually, what prompted this whole deal about getting a W in electronics repair as my to-do-list steadily grows is I wanted to make a simple Logo Writer program that messes with joystick input and remains super simple for my kids, especially my son who can be in a position to tinker with code soon at 7.5 year old.

Awesome! I think that these skills should all be taught to kids who exhibit interest in tinkering, and the earlier, the better. 😀

I was able to use the schematics from this post mostly recreate the Gravis Gamepad on a breadboard. I'm attemping to build a SNES controller to Gameport converter. I have it working, but I ran into a problem. if any of the 4 buttons is pressed, the computer will not register a down or right on the dpad. Any idea why that might be? The dpad directions all work if none of the buttons are pressed.