Gamecube Build - Early Days
That's the i/o board delivered today, only some very basic tests done so far. I opted for this cheap version (half the price of the official board). Good news is the Compute Module runs the stock 2/3 image with no problems.
Quickly threw a few roms over; performance so far is the same as a pi3 which is hardly surprising.
Next job is to get it powered from the original gamecube power regulator and hook up the controller board.
Some progress! Power supply looks to be a good; a solid 4.98v irrespective of load on the Pi. Next time I'm testing I'll add a few more USB devices to really stress it.
I followed this pin-out (after testing first of course), all correct.
Next to hook up the controller board...
Controller up and running, but as some have noted, there's the odd phantom inputs - more on that later. I'm ignoring the reset button for now but that will come later.
As I've said, intention is to use the original flat flex cable from the controller daughter board. Luckily the connector is just a standard12-way 1mm pitch FFC connector - I picked a few up from RS (Stock No. 515-1484)
Pin-out as below (credit to the original author), note that there are only 12-ways on the connector cable - not a typo above.
I'm doing the remainder of the testing on regular pi-3 - hopefully shouldn't make a difference to the configuration but it makes it a little easier for me to play with. For the controllers the 5v connection is only needed for rumble functionality so it could be omitted, however, since I've leaving the daughter board intact it would be preferable to have the LED working - which it does!
Now on to those phantom controller inputs; the jtest function shows the below. Note the bounded box shows inputs from the C-stick that I didn't make! A little more testing I think...
After a fair bit of testing it turns out not as straight forward as I first assumed.
Reading around (chiefly here and here) there are potentially a few issues to be resolved but some of the solutions are contradictory. I tried implementing a few of the proposed solutions but to little affect.
First up, check and disable any cpu throttling :
> cat cpu0/cpufreq/scaling_governor ondemand
sudo sh -c "echo performance > cpu0/cpufreq/scaling_governor"
Then it gets a bit more involved - having to change some parameters in the source and recompile. If anyone wants a step-by-step run through of this let me know, otherwise I'll gloss over it for now. The actual changes are in the above links anyway.
An important point to note is that I'm using a 3rd party controller so this in itself may be a source of some problems. As such, I'm putting off any further testing until I can get hold of an official controller.
This should just be a case of tweaking the code, the hardware aspects of connecting the controllers is pretty much proven. I'll keep working on the hardware side while waiting on a new controller - I'm move onto a safe shutdown system tomorrow.
Took a little longer to get hold of a original controller (or at least one at a reasonable price). In any case, it wasn't the quick fix I was expecting - if anything the response from the original controller is worse.
Hopefully this comes across in the below capture but if not the inputs are now fluttering much more frequently - a few times a second up from a couple of times a minute. Also there's now some wavering of the shoulder buttons that wasn't present on the 3rd party controller.
It's possible these extra "problems" are age related because it was a second hand controller of unknown history. I might have to check a new controller but for now I'll just try some more tweaks in the code.
@jackal123uk it's definitely possible that the controller has some faulty sticks and triggers i would suggest replacing the stick boxes and the triggers variable resistors before jumping to the more expensive solution
@Superman550 Thanks for the heads up! To be honest I'd put the controller troubleshooting on the back burner to concentrate on the rest of the project. I figured it must either by something in the controller hardware or in the software reading the inputs - neither of which should affect the rest of the build.
I'm just finalising the board ready to go to fabrication hopefully over the weekend (I'll post an update on this later). Once that's out of the way I'll be taking a screwdriver to those controllers!
Almost there! Progress is slow due to real life getting in the way but I'll hopefully get it sent for fabrication over the weekend.
I've included the option of adding a header to break out the gpio connections just in case I've made a mistake in my hook up or I wanted to add anything else in future.
I'm still undecided as to what (if anything) to use the serial port connections for, but since I took the time to measure out the footprints I wanted to include them. I've also added option to break these out to headers just in case I decide to use them at some point in the future.
Boards finally arrived this weekend - looking good so far...
After a few teething troubles, mainly due to some silly mistakes on my part (more on those later), I'm happy to report that it's alive!
Unfortunately I'd overwritten the SD card I'd used when setting up the controllers so I haven't been able to check all that yet but everything works as it should through USB.
I've been meaning to provide an update for the for a while so here goes.
I still haven't fully resolved the issues with the controllers but I've not really had a good stab at it yet.
A few more photos; generally I'm happy. When reassembled the fan blows straight across the compute module (which was the idea) so adding a heat sink so keep it nice and cool.
The HDMI port in not fully aligned - not a major problem but the perfectionist in me doesn't like it - that on the list of changes if there's ever a next version. Also, I'm not too keen on the empty hole to the right, might be an idea to add another USB port in future.
Front USB port fits nicely into a slightly modified memory card port but doesn't sit at the correct height - something else to be tweaked.
As for the next version, this is on hold for now. One of the original aims for using the Compute Module was future upgradability base on the assumption future Compute Modules would keep the same interface/footprint. The ultimate hope was the come CM4 or CM5 the power might be there for GameCube emulation.
However, I've read that future versions might deviate from the SO-DIMM 200 interface, hence I'll hold off on making any more hardware changes with this until there's more clarity on what the future holds. It's been a fun process and has taught me a lot on the way - which was the real aim anyway!