Showing posts with label +. Show all posts
Showing posts with label +. Show all posts

Sunday, January 16, 2022

Play ET: Legacy on Raspberry Pi [FPS]

🕐🕐 Duration: A few hours
🔧 Difficulty: Easy
🌟🌟🌟🌟 Interest: Hours of fun

Monday, January 10, 2022

Raspberry Pi & Friends

🕐🕐🕐 Duration: Up to one day (kernel + wine + box86)
🔧🔧 Difficulty: Easy to Medium
🌟🌟🌟🌟 Interest: Hours of fun

Thursday, January 6, 2022

Sound issues inventory

Hello,

I figured out that sound issues on Raspberry Pi and more generally Linux installations are often a difficult problem to deal with and the reason is that the causes vary much. The goal of this post is to answer your sound issue according to its cause. This post will be regularly updated as I notice new causes.

Using HDMI

  • in /boot/config.txt make sure to set
    hdmi_drive=2
    dtparam=audio=on
  • Avoid this fix if you are using jack audio it will have a reverse effect

RetroPie

  • Make sure pulseaudio is not installed as it conflict with RetroPie setting.
    sudo apt-get remove pulseaudio
  • Make sure that Audio_Card (should be default) and Audio_Device (should be HDMI if you have an HDMI cable or PCM if you are using a jack) are set correctly in /opt/retropie/configs/all/emulationstation/es_settings.cfg
    • You can change these settings also through RetroPie context menu

Alsa, devices and drivers

  • If you lost /dev/snd/ this is the worst case as actually I haven't found any other way than reinstalling your OS through PINN. However you can always try removing and reinstalling alsa-utils and libasound2:
    sudo apt-get remove alsa-utils pulseaudio libasound2
    sudo apt-get install alsa-utils libasound2
    speaker-test

Wine

  • Failed to initialize DirectX Audio
    • This often happens in RPGMaker games
    • It's actually a misleading message. When reading this and searching internet you often find that DirectX is missing. This is not true. This message can actually happen:
      • If DirectX is missing
      • If the version of DirectX is incompatible with your executable (might be actually too new for your executable and not too old)
      • If your sound system can't make a pipe (test it with aplay or paplay)
      • If you are cross-executing your Wine binary on another user with "su -l xxxx" from LXDE.
    • Solutions:
      • Make sure aplay/paplay work (eg type speaker-test)
      • Make sure Wine output sounds on other games
      • Make a pristine Wineprefix and don't upgrade DirectX with winetricks.
      • Install your game on that pristine Wineprefix and only the exact needed dependencies
More to be added :-)
 
The pi gamer

 

Wednesday, January 5, 2022

A teaser for 2022 and for the birthday of this blog


Dear readers-players,

Happy new year to you all and happy birthday to this blog (I opened it Dec 30, 2020 exactly)

I haven't been publishing new posts lately for mainly 4 reasons:

  • I've been working on my MMO page
  • I've started a new job
  • I've failed installations 😢
  • I've been playing Darkeden like a hardcore gamer. I mean, I've been playing Darkeden like a hardcore gamer.

That said, the blog has been going well and I'm happy to see how many you are reading my posts ☺ so I'm going to tease a little bit. The next posts will be ...

Nah, first, I'll bore you all with the failed projects here. Let me be a real marketer: failed projects are interesting because they can either give you a challenge or warn you that it will be very difficult if you try it yourself. It's always interesting to know 😉. Nevertheless, you will find teasers just afterwards.

The failed projects

Life as a hobby blogger is not like "define goal and go to it", especially when it's a technical hobby blog. Those articles will "never" see light, well unless someone really requests it. Those are failures which asked hours of work for nothing:
  • Anbox: I didn't find a kernel source which packed the necessary features for Anbox for my Raspberry Pi 3. I planned to add Anbox to my multi-purpose system that already gives Kodi, RetroArch and RPD but it will unfortunately be a no-go. Maybe it will change when I get my hands on a more modern Pi but as everyone knows, the prices are going on fire and some people even resort falling back to buy a Pi 3 instead of a Pi 4 because it has become so damn expensive.
  • Ryzom: If you are a guy like me who loves experimenting, don't step in the trap Ryzom. To keep it short it will take you 2 weeks elapsed to compile, almost 20GB of disk space, a lot of retries and all that to get it running until character creation then freeze to the death. So yeah, there is a sadly zombie post in my draft which is damn long and complete but won't be published because it is useless 😢.
  • Native Meridian 59 and Daimonin: The dependencies are deprecated. Daimonin has a solution through emulation, Meridian 59 is really too difficult (did I say that?). Well there are better games than Meridian 59 anyways and I find it not worth the time for a result which might be on the same wavelength as Ryzom's.
  • Windows on ARM: The sad part with Windows on ARM is that you need a Windows PC to format the SD Card and install it. All my Windows PCs are professional PCs except my girlfriend's and Windows on ARM installer can destroy your hard drive if you misclick. I don't want to take that risk 😞.
  • DietPi and basic xserver: I gave up this one but might return to it in a distant future. Somehow a basic startx wine on Dietpi will not provide driver descriptor and Wine refuses to start. So for now the most minimalist proposition I have is Raspberry Pi OS Lite + minimalist xserver.

Already there: new inspiration sources

When I notice a source that gives me more information and more resources to make the games run and to guide my readers, I always add it to the link page. Don't forget to check the links on a regular basis. All my input is from there. I've also added the amount of links that are listed on that page in its title.

The next posts

The next posts will not be very technical. I plan to give hints to people who just are looking for fun games to play with their friends. This will be the next post as it is almost finished and only needs images and a proofreading. 

And afterwards?

While the Quake III question is quite easy to answer, I plan to make a quick guide "Follow this and you will have fun" about installing Quake III and Fortress 2.2, along with a few recommendations for decently populated servers. And of course I will continue to work on my MMO list. For now I've almost finished the x86 standalone MMO games. I plan to add the browser games afterwards and finally Android games. While Android games are install and play it will be necessary to highlight those that run fine on Raspberry Pi and those who don't.

Stay tuned and don't forget to read (yeah even other sources 😉)

The pi gamer

 


Sunday, January 2, 2022

Play Hostile space revived on Raspberry Pi [MMORPG]

🕐🕐🕐 Duration: Up to one day (kernel + wine + box86)
🔧🔧 Difficulty: Medium
🌟🌟🌟 Interest: Interesting

Tuesday, November 16, 2021

Play DarkEden on Raspberry Pi[MMORPG]

🕐🕐🕐 Duration: Up to one day (kernel + wine + box86)
🔧🔧 Difficulty: Medium
🌟🌟🌟🌟 Interest: Hours of fun

Wednesday, July 21, 2021

Play Helbreath on your Raspberry Pi [MMORPG]

🕐🕐 Duration: 2 to 3 hours
🔧🔧 Difficulty: Medium
🌟🌟🌟🌟 Interest: Hours of fun

Prequisite

Get Wine and Box86 running. Helbreath has been tested with WineHQ-5.0.2.
Download the Helbreath installer.
Install Helbreath with Wine (or install it on a foreign PC and copy the directory to your Pi)

Wednesday, July 14, 2021

MMO List

Dear readers,

I'm currently busy studying the possibility of running native MMO games. I will keep my progress updated on this page: https://thepigamer.blogspot.com/p/mmo-list-1-working.html

I will also publish an article when it's worth it. The next one will be Eternal Lands which has been the first success for me to compile on Raspberry Pi.

Have fun!

The pi gamer


Sunday, July 11, 2021

Friday, May 7, 2021

Should you use Retropie, Lakka or RetroArch on your Raspberry Pi?

When talking about emulation on Raspberry Pi, there are four options:

  • RetroPie and RetroPie-inspired systems (Batocera and Recalbox)
  • Lakka
  • RetroArch on top of Raspberry Pi OS (I've finally decided to split Lakka and RetroArch)
  • Direct emulation (inline or in LXDE/RPD). This will be only briefly discussed in this article as it would otherwise almost need one post per emulator.

Both Lakka and RetroPie have an integrated system and an in-system installation solutions and are really different from each other. This gives its uses to both of them.

While RetroPie focuses on customization and eye candy, Lakka prefers a very simple and clear interface and a thinner layer than emulationstation.  Lakka is also more compatible with drivers like OpenGL.

RetroArch gives a quite complete answer to the uncompleteness of Lakka due to the fact you will truly have access to the OS therefore will be able to install about everything that's not covered in Lakka and execute it via shell scripts.

Retroarch raspberry Pi Raspbian Raspberry Pi OS 32 bits
RetroArch on Raspberry Pi OS 32 Bits
with bash core installed
RetroPie with Wine
emulator entry installed


Performance

Lakka uses a LibreElec base which is faster than RetroPie. Don't get me wrong, RetroPie is still faster than a Raspberry Pi Desktop base but so far:
  • LibreElec is faster
  • Lakka uses OpenGL so is faster than Emulationstation with legacy driver
  • Emulationstation doesn't support KMS on older Pi's (won't start at all)
On newer Pi's, Lakka wins by a short hand on RetroPie. On older Pi's Lakka is just the emulator to use for performance. It's lighter and supports all the graphic drivers including dispmanx for older devices and OpenGL for Pi 3. 
 
However on Lakka since it isn't possible to do scripts, you will not have any control on your CPU governor which can make you sometimes miss an opportunity of using your Pi at its full potential. You can still overclock Lakka in config.txt.  RetroArch being almost the same as Lakka but on top of a Raspberry Pi OS, it scores the same but it has the scripting advantages: you can customize it with bash script and you can overclock or change governor inline before starting the gamebrary.

Scripting and customization

RetroPie wins here, although RetroArch scores very well. Lakka is the last (and by far) of this ranking.

Here Lakka is really far behind because the only way to go to console is through SSH. It doesn't execute shell scripts from its menu basically meaning that you will never be able to create a custom emulator. Actually, only RetroArch cores will run on Lakka which restricts its list of emulators.

RetroArch on top of Raspberry Pi OS defends itself not too bad: it has the same features as Lakka, you can add bash script core to it: https://github.com/SwedishGojira/libretro-bash-launcher

The bash core on RetroArch

This core is pretty easy to install and will allow you to run any linux executable from RetroArch.
This bash core has a good coverage:  you can actually install a xserver on your system if you are in RetroArch and run X based games like all the Wine games and VCMI. The only game that I haven't successfully started so far on bash core is Diablo2-arm. But Diablo2-arm is also very bitchy to start in RetroPie. 
Since RetroArch has a KMS support you won't need to use tvservice or xdotool. You can install an xserver following my new guide: https://thepigamer.blogspot.com/2021/06/making-xwindow-wine-and-box86-work.html

You can also try to install that core on Lakka but you won't be able to run apt-get in Lakka. It means you will not be able to install for example xserver on Lakka. This brings an end to hopes of customizing Lakka further.

DOSBox

I would give it to RetroPie due to easeness of use and customization options.
Indeed, RetroPie will allow you to start a DOSBox standalone quite easy, directly start .exe files and allow .sh files while RetroArch and Lakka only allow .conf and .exe files without the bash script core.

You will also probably meet heavy DOSBox mapper issues when first starting in RetroArch. Think about making saves of your mapper file so you can use them in RetroArch/DOSBox.
You might also want to install a standalone DOSBox in RetroArch and install the bash script core to be able to run shell scripts for DOSBox games: https://github.com/SwedishGojira/libretro-bash-launcher

Other than that, both solutions perform are pretty similar. However Lakka will only follow .conf files or DOS executables leaving shell out of scope. This can annoy you if you like the "perfect DOSBox execution". Dirty games like Ultima 7 who don't have a "quit game" option and which you will quit by interrupting (in current case ALT+X quits Ultima 7 and breaks the running batches) will stay in DOSBox and will not automatically quit to Lakka.

Easeness of setup

For this one, Lakka wins easily:  you just install it from PINN and its done. If you want to install it in-system, download the package and install it this way. Everything works and all the cores are there. 

In RetroPie, you will have to setup your keyboard and then crawl RetroPie-Setup with all the packages you will want to install. Also the configuration options of RetroPie are sometimes unclear and Lakka has a better setup interface although you are more limited in the possible settings. If you try to install RetroPie on top of Raspbian, it will be even worse. You will have to pull a setup script from its git and run it during hours. And in the end, RetroPie will notify you that you have to let your Fake KMS driver and revert to legacy driver in order to get it to start. 

If you are installing RetroArch over Raspberry Pi OS, you will unfortunately have to download your cores manually from https://buildbot.libretro.com/nightly/linux/armhf/latest/. All of them will have to be unzipped and placed in /usr/lib/arm-linux-gnueabihf/libretro/

Useful tip: unzip '*.zip' 

Also note that there are two ways to install RetroArch: with apt-get and by compiling. The apt-get version is quite buggy but works and does what is asked from it.

Finally in RetroArch, you have chances that your keyboard won't be working. In that case you should search for "input_driver" in ~/.config/retroarch/retroarch.cfg and set a working config. I used "udev" but you might try "x" or "sdl2" (the latter didn't work on my machine). 

To conclude, this ranking is a bit odd: Lakka is easier than RetroPie which is easier than RetroArch.

Easeness of use

I would say RetroPie on this one but it can be discussed. 
 
Overall the good points in Lakka is that you don't need to configure your keyboard at the very beginning for browsing the menus. In RetroPie, there's no real keyboard support: you will have to configure it like it was an xbox or a playstation controller. A bit silly and you'll find yourself trying to start a DOSBox game by hitting a key you defined as "east button": this can be S, M,... depending where you have defined the controller buttons on your keyboard.

However once your controller has been defined and you got used to it, RetroPie usually detects roms, sorts them out automatically, and a few arrow keys pressing will guarantee that you will reach and launch the rom.

In Lakka, you will have either to load a core in a long list and then load a rom by browsing your whole filesystem or vice-versa. Thankfully you have an history of roms to run the last ones but the first time that you are going to look for your rom, it will sure take more time to find it. This is a bad downside in my humble opinion.

"Twice Escape" to quit is nice in Lakka.
RetroPie has a bookmarked rom system which I don't use.

Arcade gaming

Lakka already has 4 cores installed by default: Daphne, MAME2003, MAME2010 and FinalBurn Neo. In RetroPie, everything has to be installed through RetroPie setup. All the cores that are available in Lakka can be installed on RetroArch.

Lakka doesn't really give more click-and-play than RetroPie but is less confusing since you don't have to look for emulators and restricting the scope in this case might actually help new arcade players figure things out better.

Also in RetroPie, you will find yourself with 5 arcade emulator entries (Arcade, 3x MAME, Neogeo) in no time losing your mind about where to go to run your rom. Not very tidy. Only advantage so far of RetroPie is support of lr-mame2016. 

I would give it to Lakka/RetroArch here due to tidiness.

Scope

This will give the same results as scripting and customization: since Lakka can't run anything else than what's been ported to libretro, RetroPie will easily win on this one. A lot more emulators and ports will run on RetroPie than Lakka.

Once again everything can be added in RetroArch assuming you install it on top of an OS.

Design

I personally like RetroPie a lot more although Lakka is far from being ugly. RetroArch can here show some problems with icons if it's installed from package. If "look and feel" is an important matter for you, make sure to install RetroArch through compiling. Otherwise you will end disappointed by the glitches on the icons.

And RetroPie as an app?

RetroPie as an app almost has the same features as RetroPie as a system. The main difference is that you will have to install it on your Raspberry Pi OS 32 bits via RetroPie-Setup. It will then work exactly like RetroPie as an OS except that it will be started within Raspberry Pi Desktop. It will not support KMS where RetroPie as an OS didn't. Finally, it will kill your Raspberry Pi OS splash screen and replace it by RetroPie (it kind of sucks since it will look odd to start your Raspberry Pi OS with a RetroPie splash).

Finally, you can force emulationstation to run within Fake-KMS by installing it manually. If you choose to do so you won't have any RetroPie-Setup entry in emulationstation and you will have to add all the emulators in es_systems.cfg by hand, one by one. Not a very friendly solution but you might in the end have the eye candy and the KMS support on your older Pi.

Conclusion

Proud of its emulator and game coverage, RetroPie stays a safe bet for people who want to build up a full gamebrary quite easily with a very beautiful GUI.

Lakka might seem good for the trashbin at the very first glance compared to RetroPie as it suffers much from the concept "Just enough OS for". While LibreElec did an awesome job with Kodi with a plentiful heap of available plugins, Lakka is just lost without any option to customize it and is missing one of the main features of emulation. However if you give a second glance and give a chance to the application version "RetroArch", the game is completely reshuffled.

RetroArch on top of an OS will just give you one of the most lightweight interfaces, will start without RPD/LXDE and will support Fake-KMS. In terms of performance it simply puts RetroPie KO. Considering that you can run bash scripts (and even use startx in your bash script) using this excellent core, you might completely rethink your gamebrary and junk RetroPie to prefer RetroArch as an app on top of a Raspberry Pi OS 32 bits lite. You will certainly have to devote some time installing the GUI, the autoboot and the cores but you will finally get a very interesting and performant result.

The last solution, single emulation, is preferred when you just want to run one game maybe on an arcade machine replica while using a minimum possible OS in order to maximize performance. In that case, you will look for a DietPi or Raspberry Pi OS 32 bits lite base and compile the emulator yourself.

As a summary, just check hereafter the pros and cons for RetroPie, Lakka, RetroArch and Direct emulation

RetroPie

🙌 TEH eye candy
🙌 Many customization options
🙌 Huge game coverage

🙍 KMS support is not full on older versions
🙍 Not the fastest system
🙍 Rom repository is FAT32-based: RetroPie might actually become the #1 enemy of your disk space
🙍 Uneasy to install and configure on "one single OS"
🙍 Scripting with bash core to get xwindow games running is difficult


Lakka

🙌 Neat and clean
🙌 Fast
🙌 Easy to install and to use
🙌 KMS support

🙍 No real customization option besides the provided cores

RetroArch

🙌 Neat and clean
🙌 KMS support
🙌 Raspbian-based: everything can be started
🙌 Best "one single OS" solution: will be the friend of your disk space


🙍 dpkg -i version is a little buggy: some config options don't work, a few icons show black
🙍 Frequent input driver issues (but that can be fixed by editing retroarch.cfg)
🙍 Very manual installation: OS, then Retroarch, then cores
🙍 Scripting can be abit bitchy with bash core to get xwindow games running


Direct emulation

🙌 Meteoric
🙌 Most of time can be compiled with KMS/GL/GLES/... support
🙌 OS-based: everything can be started

🙍 You will have most of the time to compile your emulator manually
🙍 Not an ideal solution to store a whole gamebrary

I must admit I will miss the eye candy when leaving RetroPie. I am nevertheless eager to gain a few more FPS on my Heroes of Might and Magic IV installation when I will run it from RetroArch on top of Raspberry Pi OS 32 bits lite.

The pi gamer

 


Friday, April 30, 2021

Disk space on your SD card: best practices

When you start your career as a Raspberry Pi user you know that you will face at some point the following situations:

  • You will play games
  • You will try OSes
  • You will brag about what you can do on your Pi
  • You will try things that are almost impossible. Almost impossible is not impossible.
  • You will repartition your SD Card
  • You will play games on RetroPie
  • You will reinstall OSes
  • You will run out of SD card disk space

You will eventually run out of SD card disk space and if you are seriously using your Pi, you will have to think to several things on how you manage your storage. Not keeping storage in mind can give you performance and usability issues and if you are caught by surprise you might end having to repartition your SD card and lose some data and some work. Here we are going to browse a few pointers on how to avoid critical disk space situations.

1. Be reasonable in your expectations

First of all, make an inventory of the different storage devices you are going to provide to your Raspberry Pi. 

Here is a quick check-list to help you:
  • Your system storage (SD Card) with 4 to 512 GB (or even more)
  • USB keys that you find in your drawers and realize that you could put them to good use.
  • External hard drive
  • Your desktop PC's hard drives, shared via samba
  • FTP's are mostly out of scope since you can only download and upload from FTP's. From a samba server you can for example operate an executable.
Following how much GBs you have got, you can consider more or less usage.
Be reasonable:
  • For example, don't expect to store lots of games like Final Fantasy VII (4 CDs) if you don't have decent storage like an external hard drive. If you are poor on external storage but have a good hard disk on your desktop PC, you might want to use that hard disk but keep in mind that hard disk+network is the slowest possible storage ever.
  • Keep a decent objective with how many OSes you are going to install on your SD card depending on its size. See next paragraphs "2. Think your storage directly when partitioning" and "4. Repartition your storage if needed" for more info on this.
  • If you are using multiple partitions, store your data and games at one single place. You can either use a project partition from PINN or access a foreign /home/pi from another OS. No need to store your wineprefixes on your 4 OSes; it will just multiply by 4 needed storage and won't bring any added value.

2. Think your storage directly when partitioning

Each partition will divide your original storage when created. Assuming you have a SD card of 64 GB as a system holder, every partition will be of:
 
- 32 GB if you install 2 systems
- 21 GB if you install 3 systems
- 16 GB if you install 4 systems
- .. 8 GB if you install 8 systems

A system where you manage space carefully can live with around 10GB of disk space. If managing space is not your thing, I would not recommend going below 20 GB per system (in case of a 64GB SD card you will install 3 systems)

3. Prefer lean OSes

If you install multiple OS, think about "base". On what is my OS based? 
Example:
  • TwisterOS
  • DietPi
  • Raspberry Pi OS 32 bits
  • Raspberry Pi OS 32 bits lite
  • Raspberry Pi OS 32 bits full
All of these 5 are currently based on Raspbian Buster. Raspberry Pi OS Full and TwisterOS are both extremely demanding in terms of disk space. If you need comfort over all, you should install TwisterOS (or Raspberry Pi OS 32 bits full) alone and leave the others.
If you are more into managing your Pi and going in-depth, you might actually prefer 2 or 3 Raspberry Pi OS 32 bits lite + RPD desktop instead of having TwisterOS and Raspberry Pi OS 32 bits full. DietPi is even more sober considering that but you might have compatibility problems with DietPi that you won't meet with Raspberry Pi OS 32 bits lite.

Keep in mind that everytime you will try a compiling adventure you will probably need to redo your config. This is thus important to start on healthy basis. TwisterOS and Raspberry Pi OS 32 bits lite are two diametrically opposed approaches of the same OS.

    3.a. Consider getting a lean Wine version

    Wine bottles are getting huger and huger as newer Wine versions are implemented. If you are not running complicated programs like RPG Maker RGSS1/2/3, you can avoid installing a late wine-x86. 

4. Repartition your storage if needed

    4.a. Backup your /home/pi and your important files before repartitioning

    Depending on your setting, you will have several choices to backup your folders. From easiest to             hardest:
  • If you have an external device on your Pi:
          cd /media/pi/externaldevice/save/path
            env GZIP=-9 tar cvzf homepi.tar.gz /home/pi
  • You have nothing but your Pi:
    • Make sure you are using less than half of your SD card space. You will have to junk useless files. then go to root and tar your directory.
    • Do as above:
                sudo su
                cd /root
                env GZIP=-9 tar cvzf homepi.tar.gz /home/pi
                chmod 777 homepi.tar.gz
                cd ..
                chmod 777 /root
                exit
  • You can upload your saved homepi.tar.gz to any free cloud service (eg. Google Drive).
  • If you have an external windows PC, you can install samba on your Raspberry Pi and pull the files from your /home/pi. See guide there: https://pimylifeup.com/raspberry-pi-samba/

    4.b. Use one single OS for all

    If you are really short on space, you will want to use one single OS. You have a few choices.
  • TwisterOS has it all but is quite slow and works mainly on Pi4
  • Raspberry Pi OS 32 bits lite and regular are both good alternatives
    • You may install kodi inside this OS:
                    sudo apt-get install kodi
    • Installing RetroPie is a bit out of scope since RetroPie's compatibility is not assured with Fake-KMS so either you will have to use Lakka/Retroarch or you will use a completely manual emulationstation configuration (I don't advise the latter except if you have a lot of time to lose) 
A good alternative to RetroPie is Lakka/Retroarch:
                You can install RetroArch this way.
Beware that it will be quite buggy as foreign install doesn't take in charge all the specificities of the Raspberry Pi. A better way is to clone the git and compile it. I will make an article about it since the disable and enable flags on the configure are subject to a study but for starters you can go there.
    • Debootstrapping meets bugs in Raspbian buster so you might see mikerr's qemu fork if you need debootstrapping
    • Since debootstrapping is not an option, you will have to swap wine versions especially if you play Diablo 2 and x86 games. A full guide to swap wine versions is available on ptitSeb's git: https://github.com/ptitSeb/box86/blob/master/docs/X86WINE.md
    • If you need android, you can install anbox. See guide there: https://snapcraft.io/install/anbox/raspbian
      Use: 
      sudo snap install anbox --edge --devmode
      instead of
      sudo snap install anbox --beta
Anbox is not simply Plug-and-Play. It is a time-consuming experience and you should go to https://anbox.io/ in order to get more information about it, load kernels and run emulated apps. This is out of scope of the current guide.

Also note that most Android apps will have an alternative under Linux/Raspbian. For example, you can mirror your screen to uv4l. It is slightly more difficult to set up than Android Screen Mirroring but its more performant and it doesn't need Android to run. 

  • If you absolutely need debootstrapping (for example if emulating a x86_64 machine), use Mikerr's QEMU stretch Raspbian install from PINN.
    • Kodi and Retroarch install the same way
  • A detailed guide to install a single OS with multiple purpose and multiboot is availlable here.

5. If using multiple partitions, store your data on a common storage instead of in /home/pi/

This part does only apply if you are running multiple Raspberry Pi OS partitions on the same SD card.

You are tinkering your Pi, running x86 games and installing things. If your 3 systems are Twister OS, Raspberry Pi OS and Mikerr's QEMU Raspbian it is useless to install 3x your runnables or copy them to every system. This includes wineprefixes. A well complete wineprefix can size up to 500MB-1GB. If you copy your wineprefix to all 3 systems, you will have used 3GB instead of 1GB. A good option is to use an ext4-fomatted external USB key to hold your transversal bloatware.

Also, data that you store on a common storage won't be erased when you repartition.

6. RetroPie is a false friend

RetroPie allows you to store your roms to an external USB drive or key easily (see here).
The devil is in the details. Notice that sentence in the guide: "Either on linux, or on a PC, format the USB drive to FAT32 (used in this guide as it is the most compatible across different operating systems)". This is very bad because on a FAT32 drive you can't manage permissions with chmod. It means that if you are moving Linux executables on your drive, you won't be able to execute them. FAT32 uses .EXE, .COM, .BAT, .CMD to figure if a file is executable or not. You might rename your Linux executable to .EXE but if it refers a .so library you are screwed.
If you are storing your RetroPie roms on an external drive, better make it ext4 and manage the bind commands manually.

I would advise you against trying to mount your vfat drive in exec mode in /etc/fstab since everytime I tried to edit /etc/fstab, I destroyed my OS and had to reinstall it completely afterwards.

That said, you might consider using a single OS (Raspberry Pi OS 32 bits) with Retroarch installed on it if you want to shrink your OS signature to the maximum (see "3. Repartition your storage if needed")

7. Avoid Android as an OS if possible

I would place Android one step further than TwisterOS. It goes click-and-play all the way but it is even slower and if something doesn't work on Android, there is no single chance that you can think of a devilish plan to make it work (like you would in RetroPie or in Raspberry Pi OS Lite). 

So Android could be a good choice to stream screens or make an Android TV out of a Pi (and that makes a match : Android vs Kodi) but Android also offers a very poor performance on Raspberry Pi and system itself will need 10GB on disk space.

Think about it as Android could really be a pegleg for your diskspace. I personally use Android once per year to stream Pokémon Go to my main screen because I am too lazy to go to uv4l. 

If other systems can give you a solution, avoid Android.
Also Android on Pi doesn't pass Safety Net (bye bye Pokémon Go).
 

8. Keep a map of your storage

This can help you see more clearly: make a plan of all your OS partitions and virtual machines for example on an Excel file or on a sheet of paper. 

Then you can proceed as if you were debloating your house: Do I need this or not? Scrap what you don't really need. Usually, if you don't use something at all or if you did it only for a proof of concept, you can junk the result away. It is much more space-efficient to hold a diary of compilation steps than keeping the sources and the binaries if you don't use them.

9. Useful tools

The shell command "df" will help you know how much space is used and free.
Raspberry Pi df
df is provided on every Linux installation and gives details on
 how much disk space you still have. Here is an example on Fedora.
 Simply type "df" on your Raspberry Pi in console mode
to get a similar result.
The shell command "du" will help you know how much space (in 1K blocks) is used by a directory and all subdirectories.

du fedora
du is also provided on every Linux installation.
Simply type "du" on your Raspberry Pi in console mode to get a similar result.

Finally, the shell command "sudo fdisk -l" will give you a summary of all your storage devices. While it's not directly used in space management, it will have its uses for example when mounting, unmounting and setting a samba server.
sudo fdisk l fedora
sudo fdisk -l gives a summary of your storage devices. Here is a Fedora x86 setting.


I hope these few hints hereabove will help you manage your disk space better and maybe avoid you buying a new SD card or a new disk. I have to admit that I am a bad pupil of my own advices since I recently bought a 256GB SD card so I am having at the moment a humongous disk space but trust me: these advices followed me before while I was "disk space-poor".

The pi gamer

Friday, April 2, 2021

Saturday, March 27, 2021

Test: Atolla powered usb hub U06_SML

At some point you might meet voltage issues on your Raspberry Pi.

Voltage issues if severe can cause disasters but most of time will only freeze your Pi every now and then. 

This may be an issue for performance and stability and you might sometimes end frustrated while playing games. 

There are two ways to power your Raspberry Pi with stability:

  • Official Raspberry Pi power supply
  • Powered USB hub

I didn't choose the former when I first bought my Pi because it lacked an on/off switch. It meant that every time I wanted to reboot my Raspberry Pi I would have to plug off and on which is not a very healthy way to manage one's electronic devices.

However, plugging your Raspberry Pi on a simple smartphone charger with a on/off switch USB wire will always cause voltage issue no matter if you choose a high amperage or not.

The Raspberry Pi in itself doesn't need much amperage. You will most of the time be fine with 1A. Still the Raspberry Pi needs a stable voltage and switches, cable length and cable material (which is often poor in case of pure USB cables) will make it drop and become unstable.

Another advantage of having a powered USB hub is that the USB hub manages the power of your external devices therefore relieves the power needs on your Raspberry Pi.

The U06_SML Atolla USB hub

Atolla USB hub U06_SML Raspberry Pi compatible
Atolla USB hub U06_SML with AC/DC adapter

 

Size
This hub will look like very small (10cm x 4cm / 4in x 1.5in) and quite flat. Actually the USB keys and devices you plug in will most of the time be almost as big as the hub. This makes it a very discreet peripheral that you can hide behind your TV installations.
 
Looks and shape
You like it or not. There is no word to define that shape, I would say that its cylindric, partly round, somewhat edgy, difficult to describe. Still it looks tidy and professional and the blue lights are fun. 
 
Powering
This hub is powered by a classic AC/DC adapter on which there is nothing to really complain about. The wire is 1m - 3ft long which means that your power source mustn't be too far from your installation. I personally find a wire shorter than 1.5m - 5ft somewhat crippling. This wire would definately gain to be a little longer.

Features
This hub has 4 USB 2.0 and 3.0 compatible ports which means you basically won't notice any drop on speed on your peripherals compared to directly plugged in the SBC. 
This hub also has a fast charging port of 2.4A but this port does not have an on/off switch which means you might want to avoid powering your Pi with it if you don't need high amperage.
 
Stability
Tested on Raspberry Pi this hub is very stable no matter if you use the fast charging port or on/off switch port as power source. 

Benchmark test:
Has been tested with:
  • 15 cm / 6 in plain USB cable (no switch) between hub and Raspberry Pi
  • Performance governor
  • PS2 emulator running FFX CD
This has not been tested on Raspberry Pi 4 but in this case it would need an USB-A to USB-C cable between the hub and the Pi 4.
 

Live test:
  • The hub shows its limit when using the on/off switch port and doing heavy compilation. When doing heavy compilation it's recommended to plug your Raspberry Pi on the fast charge port and maybe remove the external hard drive.
  • This is the only case when you have to look for your voltage. All the heavy games run fine. 
Issues
I see 2 main issues for this hub:
  • If you want to use the fast charging port on your Raspberry Pi, you will need a on/off switch USB cable which will be poor quality and will be likely to make you lose the advantage of voltage stability.
  • The USB plugs are so tight that I broke 2 plastic cases in a row from my USB devices. If you plan never to remove your devices this isn't a problem but if you use an USB key to transfer files from your Raspberry Pi to your computer it can be a real annoyance.
Broken USB key
One of the victims of Atolla USB hub's tight plugs

 

Conclusion

This hub is very usable. Stable even if you don't use the charge plug, it definately will make your voltage issues history. You will have to be careful not to break your plastic USB covers while removing them. Best way to avoid this is to remove them from the base of the plug and go very slowly. The difference of price with an official power supply is around 7 €/$ and for this you will have 2 to 3 new USB ports depending how you plug your Pi and the same stability.
 

Purchase links

- US
- UK
 

The pi gamer

Thursday, March 18, 2021

Wednesday, March 10, 2021

Case study: PS2 emulator on Raspberry Pi [Play-]

🕐🕐🕐🕐 Duration: Days
🔧🔧🔧🔧 Difficulty: Difficult
🌟 Interest: Learning or challenge purpose only

Play ET: Legacy on Raspberry Pi [FPS]

🕐🕐 Duration: A few hours 🔧 Difficulty: Easy 🌟🌟🌟🌟 Interest: Hours of fun