Hi,

So it's not quite a bartop, but a semi-bartop running Recalbox.

I got an X-Arcade 15 years ago, I try to use it again every 2 years and I finally cracked ... Fed up with the Din PS2 keyboard interface , its Y connexion even on the upgraded USB board , I decided to wipe-out everything and put a controller XinMo.

For this recipe, externally I have

• a LaCie 20 inch 1600x1200 display
• a Boston 2.1 system for sound
• a Ducky keyboard with a SA Carbon set (this is for the anecdote because not really useful here)
• a CE power cable

For the intern,

• a Raspberry pi2 and its case
• a 2.5A power supply
• a power socket with an RFI filter
• a remote socket HDMI + USB
• USB remote jack + audio jack
• a remote USB socket 2 front (by default for Pi2 BT + Wifi dongles)
• an RJ45 remote socket for the network
• a USB A remote socket for the controller
• a 2-player 18-pin XinMo card and all its wires
• velcro, scotch, Araldite

• a short USB cable A - USB B

The idea is to integrate a Raspberry with a Recalbox distribution in the XArcade in order to have a "standalone" terminal by looping one of the USB outputs on the USB A socket of XinMo, or use the joystick only on a more powerful PC or Raspberry.

Genuine X-Arcade

Former interior

Former Controler PS2

for the power supply...

For USB front

The rear sockets (including failures ...)

Power socket with RFI filtering

Test of the internal layout with the Raspberry and the remote sockets

Added wires of the XinMo controller

Always difficult to work with a GrisMouth watching

Same with a RoukMouth

Wiring more or less finished

Details left

Details right

The controller card and the diagram of the pins

Finished back cover (with a Matlab cover on the ugly hole)

Front

... seen from above, no change from the original

Once installed

Configuration of Kodi under the watchful eye of Newton

Small update of the power supply and the welds following a problem with the Pi2.

Still things to do. At the GPIO level :

• connect the joystick LED to the GPIO to have a Raspberry power indicator,
• connect the back button to use it as a reset button.

Initially I wanted to use it as a hotkey but the limitation of the number of player 1 buttons on the XinMo does not allow me to do it. (There is an additional pinout on the player 2, but the configuration of the recalbox for P2 is the mirror of the player 1, so this additional button is unusable in this environment: /)

@voljega usually they are even. The red one is smarter but the grey one is stronger

@substring said in MAJ Pi 3B+ ??:

@tofbx le mieux est que ce soit moi qui réponde à ce genre de sujet, puisque qu'il n'y a que moi qui connaisse tous les tenants et aboutissants de cette histoire de 3b+. Je l'ai répété bien 100 fois depuis le début ... Allons pour la 101-eme :

• Il faut mettre à jour le kernel de recalbox
• Pour mettre à jour le kernel de la Recalbox, il faut changer le processus de maj de Recalbox
• Si on ne met pas à jour le.processus de maj de recalbox, on brick toutes les recalbox lors d'un upgrade

Le 3e point n'a rien de rejouissant hein ? Je n'ai pas envie de me faire insulter par un demi-million d'utilisateurs de recalbox, je pense que tu peux le comprendre ... Sinon, autant que je rende mon tablier et me mette à la poterie ou la faïence.

Maintenant que le contexte est expliqué, on a quoi comme solutions ?

• Le nouveau process de muse à jour est écrit. Il doit etre parfait (participe passé, pas adjectif), testé de long en large parce que le jour où il est déployé, j'aimerais autant qu'il marche sinon toutes les recalbox redteront surnle carreau sans pouvoir se maj
• L'autre problème c'est la mise en place de la maj qui supportera le 3b+ ... Elle est loin être anodine parce que c'est un chantier que j'ai commencé en Novembre, et qui concerne une mise à jour d'à peu près tout ce qui compose Recalbox. Il n'y a donc pas le pi de concerné, mais toutes les architectures actuellement supportées. Je pense même qu'on pourra suppirter la tinkerboardet la rock64. Donc ca représente une très longue phase de test pas encore commencée (à cause de cette histoire de maj)
• Il faut, au final, que l'infrastructure de maj qu'on a faite soit capable de dire "tu n'es pas à la version qui a la maj du script, je ne te propose pas la dernière version". Et c'est aussi là que ca coince : le seul capable de faire la maj sur la config web impactée n'a pas le temps (ca fait juste 1 mois que je réclame)
• L'équipe Recalbox a pu tester la version pour 3b+ qui marche parfaitement sauf la psp. Une broutille ...

Reste la dernière question qu'on me pose tout le temps : "mais pk tu ne diffuses pas cette version de Recalbox ?" Simple :

• Je ne travaille pas dessus en ce moment, donc ne la maintiens pas
• Elle passerait par un circuit de bidouillage pour les maj
• Elle n'est pas finalisée
• J'en fais déjà bien assez sur Recalbox (plusieurs heures par jour hein ... Entre le support, le dev, et l'animation de l'équipe Recalbox, je crois qu'aucun d'entre vous ne realise que passer facile 5h par jour dessus tout en ayant un boulot et des enfants, c'est ultra chronophage)

À l'égard de TOUS ces points, je ne vois aucun intérêt à diffuser une image beta, et suis incapable de te donner une date. Pas pour vous énerver hein, juste parce que je ne maitrise pas le temps libre des autres membres de la.team. ils ont une vie, font leur choix, je n'interviens pas dedans pour dire "mec, t'as 4 jours pour me finaliser l'infra web pour la grose maj" ...

Voilà, fin du débat, tant pis si ca ne vous plaît pas.

Hello,
merci pour cette réponse complète. Ne passant pas dans le coin très souvent, je me demandais pourquoi l'upgrade était si compliquée alors que le 3B+ devait avoir moins de différences avec le 3, que le 3 avec le 2... Je n'avais pas saisi que le gros du sujet est le kernel de l'OS sous-jacent plus que celui de l'emulstation et autre sur-couches.
Diffuser des versions beta : bad ideas, c'est sur. S'il faut assurer la maintenance et l'install de ce genre de pre-release....
Je n'ai pas encore d'exemplaires du 3B+ sous la main, mais j'attendrais votre mise à jour pour upgrader mon Rpi2 en 3B+.
En rebondissant sur le sujet, sans vouloir polémiquer, je me demandais si vos mise-à-jour de manière générale ne sont pas devenue trop fréquentes (avec le risque d'avoir une contre mise-à-jour deux jours après). Peut-être partir de grosses releases semestrielles ou trimestrielle, et ne faire que des updates soft intermédiaires.

J'ai eu le même soucis sur une installation neuve.
Ecriture de l'ISO sur la carte SD,
configuration des partages SMB sur le NAS avec Putty,
et le reste de la configuration via l'interface Web (nom de la box, les wifis shaders and co, jeux parsés only),
j'upload les Bios via l'interface,
reboot et hop je retombe sur l'image d'origine.

Les shares sont dans la config mais pas lu, et tous les autres settings sont à zero.
Les settings n'ont pas été paumés qu'au 5e cycle de configuration et reboot. Et là tout a fonctionné normalement.

Hello,
La nouvelle image ne serait pas en Read-Only ?
A chaque fois que je reboote après avoir configuré le recalbox-boot.conf ou les settings dans Recalbox je retombe sur une image neuve... (settings d'origine, directory Bios vide)...

@lejux84 said in Comment trier les versions de ROMS FBA ?:

bonjour
Je me joinds sur votre sujet pour poser une question (surement a la con:)) mais j'ai vu que depuis la dernière MAJ de Recalbox le romset FBA Libretro est passé en version 0.2.97.42
or je voudrais le trier en rom parent only mais dans clrmame pro il n'y a que le fichier .dat de la version 0.2.97.40 ,donc je me demande je dois utiliser celui ci
Merci

Si tu as fait la mise à jour en ligne, ce sont sans doute les anciens fichiers dat de tes répertoires de Rom que tu vois.
Si tu n'arrives vraiment pas à récupérer les nouveaux, tu peux toujours t'installer un nouveau Recalbox sur une petite carte vite fait juste pour copier ces fichiers.
Comme je ne laisse rien sur mes Raspberry (les roms sont soit en USB soit sur mon NAS), j'ai préféré réinstaller le Recalbox en entier, ça allait aussi vite.

Oki donc ça doit bien venir du fichier dat

Je tourne en rond avec cette histoire de sous-directory. Je pense que c'est le fichier dat 42 qui est incomplet par rapport aux plus anciennes versions, car en utilisant RomCenter j'ai là aussi une liste très réduite :

Hello,

J'ai extrait les neogeo du set pour les mettre dans le directory /neogeo
en utilisant le fichier FB_Alpha_v0.2.97.42_neogeo_only_noclone.dat

Puis sur le reste, j'utilise le fichier FB_Alpha_v0.2.97.42_parent_only_no_neogeo.dat mais je n'ai que ça qui apparait dans les liste des systèmes :

Ça m'étonne car j'ai vu des roms CPS 1 à 3 dans le directory (1941 et 1944 par exemple)...

Pour relancer la question, depuis la dernière mise à jour et les changements de set de roms ...
J'ai updaté le set FBA en 0.2.9.42 (celui qui est dans \fba_libretro),
j'ai toujours un set neogeo qui traine dans son propre directory \neogeo
et le set Mame 0.78 qui contient également du neogeo...

Sachant que je ne connais pas le numéro de version de mon pack neogeo d'origine, et que je n'ai pas envie de garder des doublons, est-ce que je n'ai pas intérêt à cleaner le Mame 0.78 en retirant ses neogeo, virer le contenu du directory neogeo et extraire les neogeo du fba 42 pour les mettre dans ce directory ?
J'aimerais aussi, après avoir retiré les clones, séparer les roms de FBA par plateforme technique (cps1, cps2, cave, konami, etc...). On doit pouvoir le faire avec ClrMamePro. Si je me retrouve avec :
\fba_libretro\cps1
\fba_libretro\cps2
\fba_libretro\cps3
\fba_libretro\neogeo
\fba_libretro\pacman .... etc...
Est-ce que je peux lancer un scraping avec UXS depuis la racine de \fba_libretro et n'avoir qu'un seul fichier gamelist.xml , ou bien il faudrait le faire machine par machine ?

Bonjour,

J'ai vu sur plusieurs vidéos des gens ayant monté des versions de Recalbox avec des jeux de plateformes différentes dans le même directory et un menu séparé dans l'interface ES (par exemple un ensemble Mario qui aurait regroupé des roms nes, snes, game watch, nintendo64, gb etc..., un ensemble Mortal Kombat ou un best off de shoot'em'up). J'ai vu pas mal de gens faire ça mais je n'ai pas réussi à mettre la main sur la doc afférente.

Est-ce que le directory doit avoir une syntaxe particulière ? (est-ce qu'il est possible de l'appeler par exemple \share\roms_Mario ?)
A quel endroit déclarer ce menu supplémentaire pour qu'il apparaisse dans ES ?
Au lieu de dupliquer ces roms dans ce directory propre, est-ce qu'il est possible d'utiliser des liens symboliques vers ces fichiers ?

Merci par avance !

@screech Ok c'est bon à savoir, je n'en étais pas certain à 100%.
Après je ne sais pas quelles sont les libertés au niveau du fichier gamelist.xml, mais je me demandais s'il ne serait pas intéressant d'y stocker dans un champs le résultat du hash afin de pouvoir refaire un scan de rafraichissement (uniquement textuel) sans avoir la lecture de la rom entière (ou peut- être du game ID si on reste sur la même source, mais il manquerait le champs plateforme).

J'ai remarqué que le scraping via recalbox sur le site screenscraper donnait des fichiers images 2 à 4 fois plus gros que via UXS, alors que les résolutions ont l'air proche (c'est peut-être l'effet bombé de l'écran sur l'outil interne qui fait ça).