Waveshare Game Hat - thoughts.

...

Rookervik

I also have been thinking about grabbing this. The Analog stick replacing the D-Pad is a massive turnoff for me. But to be honest, it might fix some problems I've had with projects lately. I built my GameboyZero from the AIO board... and even tho all the connections match up perfect, I can't press Right on the D-Pad. It just doesn't make connection. An analog would alleviate that completely.

I'd probably want to hook a Pi2 to this to save as much power as possible. I might grab it since the price is reasonable. Thanks for sharing this link.

EDIT: Ordered one. But looks like it will be a month or two before it arrives. Soooo... maybe a late birthday present? LOL

...

...

BuZz

Got one of these now.

Currently setting it up - Their drivers pack is a bit hacky. They have modified the source of mk_arcade_joystick_rpi rather than just providing a custom config. No need to use anything from their drivers so far.

You can use the mk_arcade_joystick_rpi driver from retropie-setup. Once it is installed go to /etc/modprobe.d/mk_arcade_joystick_rpi.conf and change it to

options mk_arcade_joystick_rpi map=5 gpio=5,6,13,19,21,4,26,12,23,20,16,18

these values were extracted from their hacked driver.

BuZz

Their default config.txt has a 640x480 which doesn't match the actual display resolution. They also have the custom screen mode set to 4:3 ratio which seems wrong but maybe it matches taking the pixel ratio into context. A custom screen of 480x320 didn't seem to work anyway - but a mode double that does. Going to have a play about with the display settings.

Arptastic

@BuZz thanks for the posts, very useful as someone putting this together for the first time.

For the resolution side of things, I have this working in config.txt:

framebuffer_width=512
framebuffer_height=384
...
hdmi_group=2
hdmi_mode=87
hdmi_cvt=512 384 60

I went with the smallest 4:3 mod8 resolution that worked... My theory being that the smaller the resolution the better in terms of performance - seems to be behaving itself.

I did try 3:2 to keep it in-line with the screens (apparent) aspect ratio but it didn't provide good results on PSX (wasn't making full use of the screen).

This is in my config.

hdmi_drive=2

hdmi_force_hotplug=1

hdmi_force_edid_audio=1

hdmi_group=2

hdmi_mode=87

hdmi_cvt=480 320 60 1 0 0 0

disable_overscan=1

overscan_scale=0

avoid_warnings=1

I use 480x320, system-wide. I found anything lower didn't look as sharp as native res.

Arptastic

@John_RM_70 had a quick go with your config but was getting the blank screen issue...

Will try again in the near future though, glad you've got it set properly :)

BuZz

@John_RM_70 maybe the screens or controller board are not all the same as my screen does not like running at native Res. (No output). Which is a shame.

...

nogolem

I stick with the hardware 4:3 option you can find in the IPS screen menu, so Two vertical black lines, but aspect ratio is respected.

I have issues with it's battery : It is an "MX JOE" 18650 battery, mainly used in Ecigs... NOT so good ..(rewraped they say)
this battery is advertised at 3000mah with a max instant current draw of 35 Amps.
I do NOT think It is true though, since I have not a long Time to play before I see the small bolt upright.
I think I am going to swap for a Sony VTC6 battery that seems to be a little better after reading tests on ECIGS forums...
this hat only uses 1 Slot for a 18650, and I was wondering If I could put a 2 batteries slot (in paralel) to get a better autonomy...
I admit I do NOT know anything about electronics and I was wondering If this could fry either the hat or the pie...
Does anyone have an advice about that ?
I know It is retropie forum and It Is NOT related to hardware. But maybe someone in this huge community has the answer....
voilà !
Please pardon my bad English...
good day everyone !
merci !

ParadoxGBB

I just got my WaveShare GameHAT and hooked it up earlier this week --- here’s a few notes from my side that might be able to help some folks.

Folks looking at the screen shots here and comparing them with the shots on the product webpage will be rightfully confused --- this is a open space concept with boards sandwiching the Pi and battery, and allowing crunched but pass-able access to the USB ports on the side. Not sure where folks got the black plastic full enclosure case, but for me I wouldn’t want it because of the use case I want (more on that later). Although there’s a foam indentation for it in the packaging, a 18650 battery was not included. You’ll also need grab the manual yourself from their website if you need it, although there isn't much in there to help you.

This was really attractive for me because it’s a no-soldering solution at a very attractive price point that will allow me to use the hardware in a hybrid sense. I was looking at the PiGrrl 2 and I would probably much prefer that form factor over this one (especially the D-Pad over an analog stick) --- but with the case and parts it would run you about 2x as much for a case that you’d probably have to modify to get USB access --- and on top of that it might complicate input switching.

For context on my use case, my RetroPie is our primary TV media control box via Kodi, booting into that by default, and I have three gamepads/joysticks, one Rii TV remote with gyroscopes, and one keyboard / mousepad / joystick hybrid that I use for DOS and terminal cases. I configured different P1 / P2 precedence preferences based on the emulator architecture I have running. I thought it’d be super awesome to have this running as it always does plugged into the TV, and then when I travel I can unplug the power, HDMI, and joysticks, plug in the HDMI adapter, get some amusement on a plane if need be with a battery brick, and then have the ability to plug this into a TV in a hotel room to continue to use Kodi. Although I suppose you could also achieve something similar with two Pis and switching cards, or bring a more compact device like TV stick --- for me I was thinking it’d be preferable to have a truly universal device.

So, I need access to the USB ports, and having the ability to pop in and out the HDMI adapter to reroute audio and video was very attractive, too. I’m hoping that the open nature of the case doesn’t cause any issues as far as debris goes, but I’m planning to look into getting PSP or Nintendo Switch style clamshell case to transport it without banging it around too much or getting stuff in there.

I definitely agree that the assembly instructions are not descriptive at all and it’s easy to mess up (but with little consequence) --- there’s a cut out square in the back panel, and while it could be a bit more comfortable to have it on the side of your analog stick to allow you to get your fingers a bit of additional stabilization --- it can be oriented only one way to allow better access to the SD card slot, and I’m fairly certain that’s the intention.

I plopped in my card and plugged it into my TV first and things worked great --- the HDMI output worked with both audio and video. If you want to use the audio jack this way, you’ll need to plug it into the Pi audio jack, not the HAT one, because the audio isn’t going to be rerouted until you plug in the HDMI adapter. There’s a few quirks around power that I think is more of a feature of the Pi in general --- both micro USB ports are exposed. Optimally, you’d plug in the HAT one even while running off a TV to keep the battery charged up, but I found that if you do that the lightning bolt icon shows so there’s not enough voltage to make that happen. Instead, you can plug both in.

Thanks to the thread here, configuring the HAT joystick was straightforward without messing with their customized drivers. Observant people will notice that the button positions for START and SELECT are swapped on the HAT compared to every other gamepad out there, so when you map them, be sure to swap them back unless you want to mess with your muscle memory.

I haven’t messed too much with the screen yet.

Given this overall experience, I think there’s a real opportunity to think about whether it makes sense to implement the concept of hardware profiles. I haven’t had the chance to do it yet, but I’m thinking about adding a simple script to swap retroarch configuration files via a menu item on the fly so that P1 is toggled between the configured joypads and the GPIO controller in the HAT. If folks reading here has any insights around this, I’d love to hear them.

The pros:

Very easy to assemble
Very attractive price point for turning your Pi mobile --- for comparison, you can get a cheap knockoff like the Retro-Bit Go for roughly the same price.
Input switching straightforward with HDMI adapter and USB access

The cons:

Some USB ports have crunched access, but do-able
I along with a lot of other people would very much prefer a D-pad over an analog stick.
The plastic boards came covered in what appears to be removable wax paper film, but I couldn’t tell whether you really can scrape it off. I’m thinking maybe not because the top panel for the controls didn’t have it. While that’s a bummer I don’t think it’s a gamestopper.

botnik

@ParadoxGBB
Hi, i just found your post and we may have the exact same thought about the game hat. I got the game hat this week an have to get to know the retropie software and all around. Because of the open case design it is possible to use the raspie as console, handheld or media player without dismantle any case. If you make any progress with different config settings or scripts to start the system in handheld- or console mode i would be very interested too. I did not have much time to try around yet but i am very positive about the idea. If i make any progress i will let you know.

botnik

Hello guys!

I have a question according to the analog pad. Is it mapped with the waveshare driver as a analog-pad or d-pad. I tried an external xbox controller by use the "configure controller" from the gui. This worked quite fine but when i wanted to remap the gpio controller i could not define the "left analog" pad because it has to be mapped at first as d-pad and is "already taken". This leads to a d-pad only funktional analog stick which makes the analog stick even more improper. I know most of the retro games are designed for d-pad input but for n64 or psx games a working analog-pad would be fine. For the other emulators i would try the analog to d-pad funktion from retroarch.

Additional to that i do not think the left thumb button (clicking on the analog pad) is working. It is not mentioned in the waveshares user manual as well. I will check if it is connected to an gpio input soon so it can be maybe mapped in the future.

In order to create a clean solution i have to study the config files and definetly will check the driver mentioned prevoius in this thread. But i am relativly new to retropie and this maybe take me a while. I hope this thread will continue so we can profit from each other.

I installed the image from waveshare and spent a lot of time setting the system up to fit my needs (themes, roms, updates, scraper). I know it is not recommended to use third party images but i do not think that waveshare changed a lot.

scruss

I have one too, and was impressing the old game nerds at TPUG with it the other night.

BuZz's early comments really helped with setup. It would be really nice if the mk_arcade_joystick_rpi driver were upgraded when the kernel was, but apart from that, it's solid. I'm using a 3A+ and a cheap Rii mini wireless keyboard for a nice portable setup.

Just a note to avoid some of the 3D printed case designs on Thingiverse. The most popular one has no holes to mount the board, it's missing a place for the power switch, and the should button locations are utterly wrong.

Personally, I'm okay with the analogue stick because this fiddly dpad stuff is way before my time. Sure, I might not be able to hit the perfect Big Leggy platform jump in Manic Miner like I used to, but I can't even see the pixels on the Game Hat to be able to attempt that in the first place.

Also, it's way easier to build than a PiGrrl. I tried when I worked for an Adafruit reseller, and we could never get all the bits to work together reliably.

botnik

Hi guys,

as mentioned earlier i want to use my game hat as a console as well. With the waveshares display settings it is not possible to use the hdmi of the raspberry with TVs. I testet it on 2 TVs without success. Maybe casual TVs are not compatible with the low resolution. I wanted to use the native resolution of different TV for crispy look anyways.
I edited the raspberry config.txt in the root directory to following:

[EDID=RTK-32V3H-H6A]

overscan_scale=1
hdmi_force_hotplug=1
hdmi_group=2
hdmi_mode=87
hdmi_cvt=640 480 60 1 0 0 0
disable_overscan=1

[all]
dtparam=audio=on
gpu_mem_256=128
gpu_mem_512=256
gpu_mem_1024=256

I tried the settings from "A Former User" without success. All config lines between [EDID=RTK-32V3H-H6A] ... and ... [all] only apply when the HDMI U-shaped adapter is connected. If there are any different screen controller boards mounted on the gamehat you can easily check your device with following command: ( F4 on keyboard to enter)

tvservice -n

just change the [EDID=*******] to your output.

You have to restart your device when switching between TV and waveshare display.

I am using two xbox 360 controller with the usb dongle and the standard configuration process and it is working great. Even the waveshare controller works.
I will try to overclock my raspi only when a tv is connected to have full power on high resolutions and max battery life on the go. This maybe work with adding "arm_freq=800" in [all] and "arm_freq=700" in to the [EDID=*]. Not tried that jet. Maybe later with useful parameters.

Do you guys have the same power issue? I am using a 3A power adapter and still get the flash for under voltage. I tried different power supplies.

For detailed infos about Conditional Filters

ParadoxGBB

Hello folks,

Finally had a bit of time to return to this and run a few more tests.

But first, folks here seem to be rather fixated on the video settings and how they're incompatible with TVs, but I never had any problems just using the default settings to my existing RetroPie card and plugging it in as-is in the GameHAT. The only setting I see that changes when when I swap between displays when I do file diffs is that Kodi's video setting oscillates between presumably optimal values:

<setting id="videoscreen.resolution">43</setting>
<setting id="videoscreen.resolution">38</setting>

This is of course assuming you shut down the pi before you swap the display. Also, let's face it --- this is a retro machine so most of the stuff I load on it is low res anyway, so maybe my bar is lower than folks here.

Regarding power, I have a 3A adapter with a toggle button on the cable (https://www.amazon.com/gp/product/B01N336XEU/ref=oh_aui_search_asin_title?ie=UTF8&psc=1). Like I mentioned before, to run in console mode with the added requirements of the TV, I need to plug in directly to the Pi's micro USB port, not the GameHAT's. If you want to charge the GameHat at the same time, you need to plug that port in via another cable --- to do so has less power requirements.

For the input, it should be fairly straightforward to write a script that swaps out input configurations to toggle between "console mode" and "mobile mode". I ran some tests --- after adding the GameHat's GPIO joystick, apparently the configuration editor tool gets confused which index of each of the joysticks, which is a bummer if you need to want to fine tune them in a convenient way and a keyboard is not around. Adding the GPIO connector added the joystick as instance 3 (starting at 0 after my three existing USB controllers), but the tool reports it as instance 1. I'm going to have to read up a bit more about this because I'm not sure where RetroArch grabs the joystick offsets from since both of these outputs seem different from EmulationStation's es_input.cfg file. However, if you just edit or swap the files by hand everything keeps working fine.

My general proposal is to "opt in" to a new hardware profile by forking specific CFG files (and maybe SH files for the the autostart.sh file to swap between starting in Kodi and EmulationStation). The script would back up any file that it encounters with that special extension tag and replace it with that file. Then it would swap it back when run again.

The most obvious application is to swap the retroarch configuration files to change the following setting:

input_player1_joypad_index = "0"

Because when you unplug everything and head out the door with your GameHAT, all the other joysticks are gone and the GPIO connector is in index 0.

For now, I'm probably going to test the script in "ports" but I also saw the following post that mentioned steps on how to map a hotkey to a script's execution, which seems intriguing:

https://retropie.org.uk/forum/topic/21155/solved-how-to-bind-a-shell-command-to-a-hotkey-raspi2png

However just as a FYI I ran some tests with evtest and the button at the center of the analog joystick on the GameHAT doesn't seem to be mapped to anything (at least with the current driver settings), so that wouldn't be an option as a way to do a swap --- but even it was, I tend to think it'd make it too likely to bump or accidentally toggle. But I'd love to hear opinions here on this or usability thoughts in general.

Also I have to do some thinking around all of the customized DOSBOX games that I have customized input mappings for. This approach may not be the best --- right now I think I'll have to look closer at leveraging LR-DOSBOX instead, which I'm currently not.

ParadoxGBB

Been using this for a while and it works great. Copy it over to your ports folder or wherever you want it.

Disclaimer: I don't script in bash much at all so apologies for style quirks.
__

#!/bin/bash

##########

GLOBALS

##########
profileName="mobileprofile"
baseScanPath="/opt/retropie/configs"
testMode=false

function logInfo() {
echo [$(date)] $1
}

#######

MAIN

#######

potentialTargets=$(find $baseScanPath -name *$profileName)
for currentPotentialTarget in $potentialTargets; do
#logInfo "Considering: [$currentPotentialTarget]"

potentialOriginalFile=${currentPotentialTarget//".$profileName"/$nul}
potentialOriginalBackupFile="$potentialOriginalFile.backup"

if [ ! -f $potentialOriginalFile ]; then
	logInfo "File not found: [$potentialOriginalFile]"
	continue
fi

if [ -f $potentialOriginalBackupFile ]
then
	logInfo "RESTORE: [$potentialOriginalBackupFile] --> [$potentialOriginalFile]"

	if [ $testMode == true ]; then
		mv -f -T $potentialOriginalBackupFile $potentialOriginalFile
	fi

else
	logInfo "BACKUP: [$potentialOriginalFile] --> [$potentialOriginalBackupFile]"
	logInfo "COPY: [$currentPotentialTarget] --> [$potentialOriginalFile]"

	if [ $testMode == true ]; then
		mv -f -T $potentialOriginalFile $potentialOriginalBackupFile
		cp -f -T $currentPotentialTarget $potentialOriginalFile
	fi

fi

done

read -n1 -t5 -p "Press any key to continue (or wait 5 seconds)..."

Matt73

@ParadoxGBB said in Waveshare Game Hat - thoughts.:

Been using this for a while and it works great. Copy it over to your ports folder or wherever you want it.

Disclaimer: I don't script in bash much at all so apologies for style quirks.
__

#!/bin/bash

##########

GLOBALS

##########
profileName="mobileprofile"
baseScanPath="/opt/retropie/configs"
testMode=false

function logInfo() {
echo [$(date)] $1
}

#######

MAIN

#######

potentialTargets=$(find $baseScanPath -name *$profileName)
for currentPotentialTarget in $potentialTargets; do
#logInfo "Considering: [$currentPotentialTarget]"

potentialOriginalFile=${currentPotentialTarget//".$profileName"/$nul}
potentialOriginalBackupFile="$potentialOriginalFile.backup"

if [ ! -f $potentialOriginalFile ]; then
logInfo "File not found: [$potentialOriginalFile]"
continue
fi

if [ -f $potentialOriginalBackupFile ]
then
logInfo "RESTORE: [$potentialOriginalBackupFile] --> [$potentialOriginalFile]"
  if [ $testMode == true ]; then
  	mv -f -T $potentialOriginalBackupFile $potentialOriginalFile
  fi
else
logInfo "BACKUP: [$potentialOriginalFile] --> [$potentialOriginalBackupFile]"
logInfo "COPY: [$currentPotentialTarget] --> [$potentialOriginalFile]"
  if [ $testMode == true ]; then
  	mv -f -T $potentialOriginalFile $potentialOriginalBackupFile
  	cp -f -T $currentPotentialTarget $potentialOriginalFile
  fi
fi
done

read -n1 -t5 -p "Press any key to continue (or wait 5 seconds)..."

I was looking for a script that at the start, would make the user choose the video resolution to use on game hat (3.5 'or tvHdmi). If I understand correctly, did you succeed?