Installing should be super easy. And it is. Or not... There are two chances: you get the installation right in one go and everything works fine. Or something fails, and it will take a lot of effort to fix it. Lots of kudos to the RetroPie team, who definitely gone to the max to make it as user friendly as possible. At the time of writing the just released version 3, which again is a huge step forward in user-friendliness. But it is still Linux in the background and that means that almost every unexpected glitch in the installation requires the terminal screen to solve it.
No need to describe the standard installation, as this is already done in many places. Unfortunately there is lot that can go wrong so let's focus on that.
Creating the SD card
Most people will probably start from a Windows PC, download the standard image and and use something like the Win32DiskImager or Fedora ARM Installer create a bootable SD card. Again, this may work for you, it did not for me. Somehow creating the card on a windows machine seems problematic. I had the same problem when I just wanted to create a Raspbian card: it just does not boot. The two LEDs on the board stay on, and nothing happens.Since it is a Linux system after all I suppose it may be more reliable to create the card on a Linux computer. So I plugged into an old laptop on which I previously installed Xubuntu.
So far the best description of the installation using a Linux computer I've found is the RetroPie Installation Guide at LibreGeek. And even that was problematic. I still prefer the the 'easy' GUI-based solutions so I opted for 'GParted' and 'Unetbootin'. Which failed. The firtst time it actually seemed to work. The card booted, but the process ended with a fatal error and that's it.
Somehow the second time Unetbootin only created some files (each containing 0 bytes) but still nothing useable.
So finally I used Gparted to force the whole card to a single partition and formatted it to FAT32. Then I used the terminal and the 'dd' tool to actually create a bootable card.
And, just in case this site ever disappears, here is the required command:
sudo dd bs=4M if=2016-03-12-jessie-minibian.img of=/dev/mmsblk0
'2016-03-12-jessie-minibian.img' is the name of the image.
Display settings (what to do if there's nothing on the screen)
My Pi is connected to a VGA monitor, using a HDMI to VGA converter. So after I finally got a card to boot (which I could see because the LED's on the board were blinking) my monitor did not show anything but an 'Input not Supported' message. Apparently the Pi uses a resolution that my monitor (an ACER 1912, 1280x1024) does not support. I quickly found that the monitor settings are stored in the 'config.txt' file which can be found in the 'boot' section of the SD card. The first two lines of this file :
# uncomment if you get no picture on HDMI for a default "safe" mode #hdmi_safe=1
And indeed, after removing the # from the second line the card boots, and the monitor shows the 'Retropie' logo.
The gamepad
Obviously real gaming is only possible using a gamepad or joystick. A Super Nintendo-like gamepad seemed a nice solution, so I bought a (super cheap) USB gamepad...
.. which turned out also to be super-crappy. The D-Pad requires a lot of pressure, and often even fails to detect any movement to the left. Which is very frustrating in almost every game.
So I bought the Logitech F310 gamepad. Almost three times as expensive, but so much better.
Only one problem: it works fine with the EmulationStation interface, but not in any game. This turned out to be the hardest problem so far. Several forums and the wiki have some information regarding this problem, but nothing seemed to work with RetroPie Version 3.0.
UPDATE 2019: RetroPie 4 and up seem to have solved this problem. If you set the the switch on the Logitech to 'X', everything will work out of the box !
With version 3 it requires some modifications. ( Thanks to 'GhostTree3' )
In version 3 the main configuration of the emulators is stored in the file:
/opt/retropie/configs/all/retroarch.cfg
And it contains the following lines:
# Input device driver. (Valid: linuxraw, sdl, dinput)
input_joypad_driver = sdl2
The tricky part is that the 'comment' is incorrect (or at least incomplete).
After changing
input_joypad_driver = sdl2
to
input_joypad_driver = xinput
Then it works !. (if you set the gamepad to 'xinput' using the switch on the back)
Geen opmerkingen:
Een reactie posten