Il s’agit une console portable basée sur un raspberry pi et faisant tourner Retropie. Oui, encore une…
Effectivement, c’est un exercice DIY qui rencontre pas mal de succès sur le Net. C’est également mon 3e projet du genre, l’objectif est donc avant tout d’améliorer le concept et de le faire coller à mes exigences.
Voici la liste des points sur lesquels s’est porté mon attention :
l’Écran
Mon 1er projet utilisait la sortie SVideo du Pi et le 2e l’interface SPI. La qualité avec le SVidéo est vraiment décevante alors qu’avec l’interface SPI, ce sont les performances qui en pâtissent. Aussi, j’ai décidé d’utiliser l’interface DPI (RGB) du Raspberry ce qui est déjà un peu moins courant. L’avantage du DPI est la rapidité d’affichage (60Hz), une bonne qualité d’image (c’est du numérique et non de l’analogique comme le SVideo), et la possibilité de piloter l’affichage directement par le Raspberry sans composant supplémentaire. L’inconvénient étant que cela consomme beaucoup de GPIO. Ça dépend du mode choisi mais pour du 24 bits (8 bits par composantes RGB) il faut déjà 24 GPIO pour les données.
le Raspberry Pi
Mon intention est de faire un terminal le plus portable possible, je cherche donc à limiter l’encombrement. De plus, je n’ai pas envie de charcuter une carte existante. Cela met de côté le RPI3 ne serait-ce pour ne pas être gêné par les ports inutiles. J’aime beaucoup le RPI zero pour sa compacité mais il est tout de même un peu juste en termes de puissance et limite les émulateurs utilisables.
Je suis donc parti sur un Raspberry CM3+ qui dispose de la puissance du Raspberry 3 tout en permettant une bonne intégration. La console mesure au final 147x68x18 mm. L’autre avantage étant le nombre important de GPIO disponibles. Effectivement, et contrairement aux autres Raspberry, sur le CM3 l’ensemble des GPIO du BCM2837 sont disponibles.
le démarrage et l’extinction
Autre chose qui me dérange dans mes précédents projets, et la plupart de ceux que je trouve sur Internet, est le fait que la gestion de l’alimentation est totalement déconnectée du Raspberry. En résulte le besoin de lancer l’extinction du système logiciellement puis une fois le Pi éteint, de couper le courant de l’engin. Je souhaite avoir un comportement comparable à une console standard, c’est à dire : une pression sur le bouton PWR à l’état OFF allume et démarre le système, la même chose à l’état ON lance une extinction propre du Pi et coupe l’alimentation.
Pour la gestion de l’alimentation, j’utilise un microcontrôleur ATtiny85. Son nombre de GPIO est pile ce dont j’ai besoin pour cet usage, sa taille est contenue et il ne nécessite pas de cristal ou d’autres composants pour fonctionner.
le Son
Sur ce point, j’ai toujours été déçu des sorties son via PWM sur le Pi zero. J’ai essayé de faire des filtres passe-bandes mais le résultat n’a jamais été convaincant. Sur ce projet, je voudrais quelque chose de plus qualitatif et j’ai donc décidé d’utiliser un DAC. J’ai pu utiliser la breakout board d’Adafruit basée sur le circuit MAX9357 et je trouve ce dernier particulièrement adapté à ce type d’utilisation. Les produits d’Adafruit sont opensource et cela est vraiment top pour apprendre et améliorer ses propres réalisations. Aussi, j’ai repris leur travail pour réaliser mon DAC basé sur le même circuit intégré.
J’ai commencé mes expérimentations avec la compute module IO board de WaveShare. Cela me donne accès à l’ensemble des ports de la carte de façon simple et rapide. J’ai pu ainsi valider les différents modules (hors alimentation) que je souhaitais utiliser.
Le plus important d’entre-eux est l’écran. Il n’a clairement pas été facile de trouver l’affichage qui me convenait. J’ai du passer de long moments sur Aliexpress a demander des infos aux vendeurs pour avoir des caractéristiques fiables. Il a également fallu étudier les documentations de ces écrans afin de bien comprendre leur fonctionnement et adapter la configuration du Raspberry de façon adéquate.
En effet, j’utilise sur ce projet l’interface DPI du Raspberry qui est une simple interface parallèle qui envoie les données de couleur de chaque pixels en même temps sur l’ensemble des ports. Plus on utilise de ports et plus la couleur sera juste.
Le Raspberry peut aller jusqu’à 24 bits mais j’ai préféré me contenter de 18 bits pour garder assez de GPIO de disponibles pour le reste. L’interface est contrôlée par le GPU et on utilise le fichier config.txt pour adapter la sortie aux caractéristiques de l’écran.
J’ai essayé plusieurs écrans et j’ai fini par choisir un 3.5" format 4/3 qui est facilement trouvable sur Internet : LQ035NC111.
Je me suis également fabriqué une petite manette de fortune pour pouvoir effectuer les premiers tests.
Pour le son, comme indiqué dans le précédent post, j’utilise la breakout board d’Adafruit “MAX98357 I2S Amp Breakout” ainsi qu’un HP de Gameboy SP. Il s’agit donc d’un décodeur numérique vers analogique et également d’un amplificateur et permet ainsi de connecter directement un mini HP. L’ampli peut délivrer jusqu’à 3W en fonction de l’impédance du HP, de l’alimentation utilisée et de la distorsion tolérée. Il peut en effet être alimenté avec une tension comprise entre 2.7 et 5.5 V.
Concernant la configuration du raspberry, j’ai commencé par créer mon propre “device tree” afin de définir l’utilisation des GPIO que je voulais avoir.
Les 22 premières sont utilisées pour l’affichage DPI de l’écran sur 18 bits (6 par couleur plus 4 pour le signal d’horloge et la position)
4 sont définies pour l’interface I2S pour le son (je n’en ai besoin que de 3)
12 sont utilisées pour les contrôles (4 boutons de direction, 4 boutons action, 2 gâchettes et start/select)
2 seront utilisées pour la gestion de l’extinction
Au-delà du fichier dt-blob.bin créé, j’appelle dans mon fichier config.txt différents overlays pour compléter ma config :
i2s-gpio28-31 et hifiberry-dac : pour envoyer le son au format PCM au DAC
gpio-shutdown : pour que le raspberry puisse avertir qu’il a fini de s’éteindre
gpio-poweroff : pour ordonner au raspberry de s’éteindre
gamepad : celui-ci est un overlay que j’ai créé afin que l’utilisation des GPIO dédiées aux contrôles simulent les touches d’un clavier.
Le microcontrôleur est connecté à la batterie par l’intermédiaire du bouton d’allumage. Lorsque le bouton PWR est pressé cela l’alimente et il démarre.
Le code de l’ATtiny est très simple. Une fois démarré, il attend environ 2 secondes puis passe à l’état haut le pin PWR_CTRL ce qui active le convertisseur de tension U2 et alimente l’ATtiny. La boucle est bouclée, on peut relâcher le bouton, l’ATtiny reste allumé.
Ensuite, le code passe à l’état haut le pin PWR_SYS ce qui va allumer tout le système et donc le Raspberry.
Une fois la séquence de démarrage passée, le code scrute l’utilisation du bouton PWR, à l’aide du pin BTN_OFF, ainsi que le pin POWEROFF. Lorsque BTN_OFF passe à l’état bas pendant environ 1.5 sec, le pin SHUTDOWN est passé à l’état haut ce qui ordonne au Raspberry de s’éteindre (overlay shutdown).
Une fois la séquence d’extinction du Rasbpberry terminée, celui-ci passe le pin POWEROFF à l’état haut et l’ATtiny éteint tout le système en coupant les pin PWR_SYS et PWR_CTRL (ce dernier a pour effet d’éteindre l’ATtiny lui-même).
Au niveau de l’alimentation, je suis parti sur un circuit intégré utilisé dans les power bank : IP5306.
L’avantage consiste à un unique IC pour gérer la charge, la décharge et la protection de la battery de type LiPo mais également pour booster la tension à 5V. La tension fournie par la batterie variant de 4.2V à ~2.8V suivant sa charge. De plus, cet IC permet de piloter jusqu’à 4 LED pour indiquer le niveau de charge de la batterie.
Le CM3+ nécessite 3 tensions différentes pour fonctionner correctement : 5V, 3.3V et 1.8V. La documentation fait également mention d’une tension de 2.5V mais celle-ci n’est nécessaire que pour la sortie vidéo composite que je n’utilise pas.
Je pars donc de la tension de 5V et utilise des régulateurs de tension pour obtenir les 2 autres.
Pour alimenter le rétroéclairage de l’écran, il faut alimenter 6 LED en série. J’ai donc besoin d’une tension plus élevée pour ce module : ~19V. J’utilise pour ça un boost-converter basé sur l’IC PT4103.
Pour la partie alimentation, je suis resté sur les préconisations de la datasheet de l’IP5306 et ai réalisé un premier PCB permettant de tester les options choisies.
il faut être vigilant à l’implémentation du connecteur d’écran. Oui, sur cette version, je l’ai inversé…
nécessité d’une résistance de rappel pour que l’IP5306 s’arrête une fois le système éteint.
les 4 LED permettant de connaître l’état de charge de la batterie ne sont pas utiles. 2 LED suffisent pour connaître l’état de charge ou de décharge
d’autres petites choses qu’il n’est pas intéressant de mentionner ici.
J’ai également ajouté à ce PCB des jumper afin d’être en mesure d’isoler certaines parties du circuit et ainsi plus facilement débusquer les problèmes.
Ce prototype a également été l’occasion pour moi d’affiner le code de l’ATtiny et de tester en condition réelles l’allumage et l’extinction du système.
J’ai pu alors me lancer dans la réalisation du PCB définitif.
Je suis pour cela parti sur des switches ALPS SKRRABE010 dont je suis vraiment fan du feeling. Pour le D-Pad, j’ai voulu utilisé un switch multi-directionnel ALPS SKRHAAE010 également pour le feeling qu’il procure. Cela me rappelle la NeoGeo Pocket Color qui est une console que j’ai particulièrement apprécié pour ce point.
Une fois cette partie terminée, il a donc fallu attendre la réception du PCB. Cependant, la modélisation du boitier pouvait débuter. La première chose à faire consistait à réaliser le PCB sous Fusion 360 à partir des images ci-dessus.
Une fois le PCB modélisé, il faut s’occuper des autres éléments afin d’être en mesure faire un boitier aux bonnes dimensions. Pour cela, je cherche autant que je peux sur le Net les fichiers 3D de mes composants et modules et quand je ne trouve pas, je prend les mesures et fait moi-même une modélisation sommaire me permettant de reporter les principales côtes sur lesquelles m’appuyer.
Je n’ai évidemment pas besoin d’avoir tous les éléments de modélisés. Les éléments les plus importants étant : l’écran, la batterie, le port USB, les switches et le HP.
Ce n’est pas le rendu le plus récent et j’ai déjà apporté de nouvelles modifications comme l’évent arrière permettant une meilleure dissipation de la chaleur produite par le processeur.
La modélisation doit toujours se faire en ayant en tête l’impression qui suivra. En effet, toute modélisation n’est pas imprimable et prendre en compte la façon dont fonctionne une imprimante 3D au moment de la modélisation permet d’avoir de meilleurs résultats.
Concernant la soudure des composants, il est clair qu’un heat gun est plus que conseillé. J’ai également utilisé un stencil pour déposer la pâte à souder pour le socket de DDR2-SODIMM devant accueillir le CM3. Il y a tout de même 200 pin et après mettre arraché les cheveux pour le souder sur le premier prototype, j’ai préféré me faciliter la vie pour le PCB final et par la même occasion obtenir un bien meilleur rendu.
Au final, les différents éléments prêts pour le montage :
Il ne me reste plus qu’à poster quelques photos du résultat final.
Il faut que mette en peinture le boitier pour vraiment terminer ce projet mais je n’ai pas la possibilité de faire cela maintenant et je commence déjà à réfléchir à certaines modifications afin d’aller un peu plus loin.
Ce projet a bien évidemment été inspiré par nombre d’autres consoles de retro-gaming comme notamment la Retro-CM3 ou la Freeplay CM3. J’ai beaucoup appris en construisant cette console et même si le résultat n’est pas du niveau d’un produit commercialisé, il est vraiment fun à jouer.
Concernant les émulateurs, j’ai pu joué à des jeux PS1, N64 ou PSP ce qui n’est pas possible avec un Pi zero. Les jeux GameBoy Advance passent vraiment super bien, ce qui était mon premier objectif.
C’est juste bluffant. Tu m’épates.
Pour moi, ça mérite amplement un article sur le site tellement ça fait plaisir à partager. En voyant le pad, j’ai eu un doute sur la jouabilité d’un si petit thumbstick, mais en voyant Metal Slug, je me suis dit, “Olala c’est énorme !”.
Est-ce que ce pad est analogique ?
et si oui, est-ce qu’il est facile de contrôler la différence en marcher et courir ?
enfin, comment fais-tu pour reproduire tes schémas en 3D ? Tu mesures au pied à coulisse ? ça doit te prendre un temps impressionnant
Merci !
Merci pour ton commentaire, c’est très sympa. Pour répondre à tes questions, le pad n’est pas analogique et il n’y a donc pas de dosage possible. Le stick me fait vraiment penser à celui de la NGPC avec ce petit cliquetis tellement satisfaisant !
Concernant l’importation de mon PCB sous Fusion 360, c’est très simple et rapide : je fais juste un export sous forme d’image puis je l’importe dans Fusion en le “collant” à une face de mon objet PCB. En faisant attention de bien toujours être à l’échelle, je peux alors m’appuyer sur cette représentation pour placer mes éléments.
Pour répondre à cemoileroi, je ne prévoit pas de refaire une console pour l’instant car je suis sur d’autres projets.
