A computer for retrogaming

Notes published the
11 - 14 minutes to read, 2725 words
Categories: assembly debian games linux
Keywords: assembly debian games linux reuse

Another task for an old PC

Follow more or less the notes for installing a minimal Debian version.

But this time, instead of installing Kodi and using one old PC as a media center, I want to use it for "gaming".


The main program running will be RetroArch.

It makes it possible (and relatively easy) to configure many emulators and controllers behind a homogenous interface.

Install Debian package

RetroArch is packaged for Debian, but not yet quite usable.

Debian packages should be complete; they should not need to download additional data to work correctly. If they do, such data should be packaged and installed through the package manager.

For example, Firefox packaged for Debian (and many other Linux distributions) does not have an integrated updater.

This also holds for RetroArch; so far so good.

RetroArch uses a plugin system for managing many different platforms, and those plugins are downloaded. And they are not packaged in Debian.

This does not mean that the Debian package is useless, as some plugins might have been packaged.

But if you want to use a core (the name of those plugins), you need to re-enable the download manager.

This can be done by editing the configuration file; enabling the download manager, and changing some paths to point to a non-system location (otherwise the download manager would not be able to extract the data)

sed -i -e 's/menu_show_core_updater = "false"/menu_show_core_updater = "true"/g' -e 's|libretro_directory =.*|libretro_directory = "~/.config/retroarch/cores"|g' -e 's|assets_directory =.*|assets_directory = "~/.config/retroarch/assets"|g' -e 's|audio_filter_dir =.*|audio_filter_dir = "~/.config/retroarch/filters/audio/"|g'  -e 's|video_filter_dir =.*|video_filter_dir = "~/.config/retroarch/filters/video/"|g' -e 's|rgui_browser_directory =.*|rgui_browser_directory = "~/Games/"|g' ~/.config/retroarch/retroarch.cfg

Install "vanilla" RetroArch

Instead of mixing the packaged version of RetroArch with non-packaged cores, it might be easier to use the upstream stable version.

As it comes packaged as an AppImage (if possible, avoid the Flatpak), it’s just one file to download, with a caveat: you should unset (if set) the variables XDG_DATA_HOME, XDG_CACHE_HOME, and XDG_CONFIG_HOME.

The reason is that inside the AppImage, $HOME is overwritten, and thus the config data will be scattered at the wrong locations (as the predefined data will not be located at the right place).

Set up some cores

After starting RetroArch, the first thing one might do is to set up a core.

A core is a plugin responsible for emulating a platform.

A platform might be a physical platform, like the Game Boy, or a PlayStation, but not necessarily. It can be an emulator for an operating system, like DOSBox, or even something more akin to a game engine, like ScummVM, or OpenLara.

Installing a core is as easy as clicking on View  Main Menu  Online Updater  Update Cores, and choose the core from the list.

For example, there are multiple cores for the Game Boy family:

Nintendo - Game Boy / Color (Gambatte)
Nintendo - Game Boy / Color (Gearboy)
Nintendo - Game Boy / Color (SameBoy)
Nintendo - Game Boy / Color (TGB Dual)
Nintendo - Game Boy Advance (gpSP)
Nintendo - Game Boy Advance (mGBA)
Nintendo - Game Boy Advance (VBA Next)
Nintendo - Game Boy Advance (VBA-M)

Personally, I’ve installed the mGBA core for multiple reasons:

  • it should be the current state of the art for GameBoy emulation

  • It can emulate multiple (similar) platforms: the GameBoy Advance, GameBoy, and GameBoy Color (and it also supports the Super Game Boy)

  • it is packaged for Debian (as a standalone emulator, and as core for retroarch)

  • It is available as a standalone emulator for Windows, Mac, and even some consoles. Only a standalone Android version seems to be missing, but at least it is available through RetroArch on Android.

The fact that there is a standalone emulator, means that it is possible to use saved games from RetroArch on another machine without necessarily using RetroArch.

RetroArch makes a nice experience for a dedicated set-up, but sometimes it is more practical to double-click on a file and start the game immediately, without navigating RetroArch menus.

The cores currently packaged for Debian are

libretro-beetle-pce-fast         - Libretro wrapper for the Beetle PCE FAST core
libretro-beetle-psx              - Libretro wrapper for the Beetle PSX core
libretro-beetle-vb               - Libretro wrapper for the Beetle VB core
libretro-beetle-wswan            - Libretro wrapper for the Beetle WSWAN core
libretro-bsnes-mercury-balanced  - Libretro wrapper for bsnes-mercury balanced core
libretro-desmume                 - Libretro wrapper for DeSmuME
libretro-gambatte                - Libretro wrapper for Gambatte
libretro-genesisplusgx           - Libretro wrapper for Genesis Plus GX
libretro-mgba                    - Libretro wrapper for mGBA
libretro-nestopia                - libretro wrapper for Nestopia
libretro-snes9x                  - Libretro wrapper for Snes9x

Thus if you want to use at least one core not packaged for Debian, either download RetroArch from the official website or change the configuration as described.

Get the games

If you have some old games on cartridges, you should be able to dump them with appropriate hardware. For other consoles, dumping games can be easier. For example on some consoles, after unlocking them, it is possible to copy the data from there.

dumping.guide and wiki.no-intro.org have a lot of useful resources for this task.

Otherwise, games for the GameBoy are still made, and other consoles too. For those "modern retro games", it is possible to download those games (eventually after paying) on your PC, no need to dump them!

I am not aware of any "real retro game" that can be downloaded directly on the PC. For example, Nintendo has a virtual store where to buy games for older consoles, but they are intended to be downloaded an played on the Nintendo Switch (and previously on the Wii and Wii U).

Some (non-affiliated) places to obtain games that can be played on RetroArch are

And surely many other sites can be found with any decent search engine.

Some games might even be open source, like Anguna, …​

Add games to RetroArch

You can put all the ROMs in a folder.

Personally, I put every game in its folder. The main reason is that with a game file, there might be additional material, like screenshots, savegames, handbooks, cheat sheets, and so on.

In RetroArch, you should first update your local database; go to View  Main Menu  Online updater  Update Databases. You can also update everything else, but it’s not required.

Then, go to View  Import Content  Scan Directory, enter the directory where to start the search, and select <Scan This Directory>. RetroArch will also search games in subfolder and zip archives.

My game is not recognized, what can I do?

Most commercial games should be recognized without issues, as long as your dump is unmodified. RetroArch calculates hash values and compares those to a database.

In case you add new games after the initial scan, you have to repeat this process, RetroArch will not scan the folder again on its own.

If a game is not recognized it might be because the hash values do not match, or because the game is missing from the database.

There might also be a third option. You have an unmodified copy of the game, but the database maintainers saved hashes for an original copy.

The reason behind such decision is that some file formats used for storing game dumps can contain metadata, and the format used in the database might not be the same of the one used for virtual releases.

Long-term solution

The first, and most long-term solution, is to provide the hash values upstream so that anyone can benefit from it.

Either provide the data at libretro-database or probably even better, provide the data directly at No-Intro, Redump. or similar websites.

Short-term solution

The second and fastest option is to play the game without adding it to the database.

Go to View  Main Menu  Load Content and search the ROM file in the filesystem.

Once the game is started, it will be added to the history, so that at least you do not have to search it again in the filesystem. You can also add it to your favorites.

This is cumbersome if you have many games that are not recognized. The easiest way to overcome this situation is to edit manually the playlist file located in the playlist folder.

For example, if you want to add an unrecognized game for the Nintendo DS console, add the following entry to ~/.config/retroarch/playlists/Nintendo - Nintendo DS.lpl (adapt the path to where your RetroArch config file is located)

	"path": "/absolute/path/to/game.nds",
	"label": "Title of game to show in UI",
	"core_path": "DETECT",
	"core_name": "DETECT",
	"crc32": "00000000|crc",
	"db_name": ""

The content of db_name is optional, and a valid crc32 value is optional too.

In case you do not have such a file, because none of your games for the Nintendo DS were recognized, it should look like

  "version": "1.5",
  "default_core_path": "",
  "default_core_name": "",
  "label_display_mode": 0,
  "right_thumbnail_mode": 0,
  "left_thumbnail_mode": 0,
  "sort_mode": 0,
  "items": [
      "path": "/absolute/path/to/game1.nds",
      "label": "Title1 of game to show in UI",
      "core_path": "DETECT",
      "core_name": "DETECT",
      "crc32": "00000000|crc",
      "db_name": ""
      "path": "/absolute/path/to/game2.nds",
      "label": "Title2 of game to show in UI",
      "core_path": "DETECT",
      "core_name": "DETECT",
      "crc32": "00000000|crc",
      "db_name": ""

as described in the documentation

After adding the games this way, you’ll immediately notice that something is missing; there are no images for the games you added manually.

Also in this case, the documentation has you covered

Thumbnails should be stored in subfolders within the configured RetroArch thumbnails directory within a subfolder named exactly the same as the playlist, except without .lpl at the end. Example: If your playlist is named Atari - 2600.lpl, then your Atari 2600 root thumbnail folder should be called thumbnails/Atari - 2600/.

Within this root thumbnail folder called Atari - 2600, you should then create subfolders named Named_Boxarts, Named_Snaps, or Named_Titles for boxart/cover art, in-game snapshots, and title screens, respectively.

The thumbnail filename should exactly match the game’s title as listed in the playlist with an important exception. The following characters in playlist titles must be replaced with _ in the corresponding thumbnail filename: &*/:<>?\|`

— thumbnails
from the documentation

Custom Playlists

After adding your games, you’ll see that they are organized by platform.

It is a sensible organization, but not necessarily the one you prefer when looking at your games.

Just like you can add elements to an existing playlist, it is possible to add custom playlists.

Set up remotes

If you have a wiimote, do not install xserver-xorg-input-xwiimote on your machine.

It makes it possible to use the Wiimote with some applications, but it makes RetroArch unusable with a Wiimote.

Apart from this issue everything worked out of the box. Even with other controllers, there was nothing to configure, except for pairing the remotes via Bluetooth with the operating system, or plugging the cable.

In case you want to customize the remote settings, the documentation has you covered.

Why setting up a PC for console games and not native games

I wanted to use an old PC hooked to the TV for playing games.

Many Games that require mouse or keyboard are not really comfortable to play on a couch in front on the TV.

Games written for consoles work pretty well, with no need for a mouse or keyboard; and RetroArch setups out of the box most if not all controllers.

Thus the idea of putting on the machine mostly games written for consoles and emulators.

Just like there are distributions like LibreELEC with everything preconfigured for specific devices, there are distributions for retro-gaming: RetroPie, Batocera.linux, Lakka, and so on.

Again, if the device has only that one job, and there is an image for it, it might make sense.

But I like to use a PC for multiple things, so having behind the GUI a complete OS is my preferred way to set it up.

In fact, you can merge these notes and the one for a media center, and use an old PC for both tasks.

Also, playing in emulated platforms has other nice features out of the box, which many "native" games do not have.

The first advantage is that those games, even if written for "old" hardware, will work on multiple platforms.

Want to release a game that works on Windows, Max, GNU/Linux, Android, and other systems? Write it for the Game Boy or SNES; those platforms are emulated on more or less all devices.

The second advantage is the ability to save the current game status. Emulated platforms add different features that the real platforms do not support. And one of those is savestates, which is more or less the ability to save the state of the game at any moment, and being able to resume it. If the same emulator is available on multiple platforms, chances are good that you can even start playing on one platform, save the state, transfer the state to another platform, and continue playing from there. If statefiles are not supported on multiple platforms, chances are high that you can still use the in-game save feature.

Another advantage is support for multiple controllers.

On a PC you can connect more or less all Bluetooth remotes you can find, even those developed for consoles, like the Playstation Controller or Wiimote. Your game does not need to support it, as long as the controller has enough buttons, any controller can be used.

Retro games are also sandboxed by definition.

Executing "unknown" programs on a machine always carries a certain risk.

Since those games are executed in an emulated environment, the chances of having some undesired side effects are really low.

You need to get a ROM that takes advantage of a bug in an emulator before being able to interact with your system.

It is not impossible, but much harder than executing a program locally.


In case you want to share your gaming experience with other people, you might want to look at RetroAchievements, which is already integrated in Retroarch.

Unfortunately, it does not work offline.

More modern consoles

Cores for modern consoles are missing for multiple reasons.

The first one is that a capable emulator might simply not exist yet, or not be stable enough.

But even if such an emulator existed, it should be open source, or probably no one working on RetroArch is going to spend time on it.

And even if such core exists and is open source, maintaining it requires additional work⁠[1], unless the team developing the emulator also maintains the core.

Thus for some systems, using a dedicated program might make more sense, even if it is not possible to hide it behind a uniform interface (just like most regular desktop games).

Granted, for an old PC the main issue will be that such an emulator won’t have enough resources.

Do you want to share your opinion? Or is there an error, some parts that are not clear enough?

You can contact me anytime.