Je me suis rendu compte récemment que le fait de faire mes projets en stream me bouffait toute mon énergie, ce qui avait pour conséquence un très faible nombre de billets de blog publiés ces dernières années. Il est peut-être temps pour moi de prendre le temps, justement, de documenter certains projets sur ce blog car après tout c'est bien fait pour cela, un blog.
C'est l'occasion de présenter un projet qui m'a occupé une bonne partie de l'année 2025 et qui a commencé comme souvent par un achat inutile et une idée à la noix: le hack d'une console à moins de 10 euros trouvée sur AliExpress.
AliExpress pulule de consoles «rétro-gaming» qui se ressemblent vraiment presque toutes, avec leurs croix directionnelles, leurs 7 boutons et une connectique USB utilisée pour y brancher une manette externe. Elles possèdent une batterie, un écran TFT couleur, et proposent plus de 400 jeux rétro !
En réalité, elles utilisent toutes une puce spécialisée (ASIC, encadrée en vert ci-dessous) capable d'émuler des jeux NES stockés dans une mémoire Flash (encadrée en rouge ci-dessous),
La puce spécialisée est documentée et il doit bien y avoir moyen d'aller bidouiller la mémoire Flash pour modifier les ROMs qui s'y trouvent, mais je trouvais tout de même ça un peu limité. Vu qu'on a un boîtier, des boutons, une batterie et un écran, pourquoi ne pas remplacer la puce spécialisée par un ESP32 et faire de l'émulation de consoles plus funs que la NES, comme la (ou le) Game Boy ou encore une Master System ? L'idée semblait très intéressante, et la perspective de hacker cette console peu onéreuse était très tentante.
Cependant, le premier obstacle rencontré est bien l'écran TFT utilisé: impossible de trouver de documentation à partir des marquages, il va donc falloir essayer de discuter avec lui afin de déterminer le contrôleur qu'il emploie (en espérant qu'il soit documenté) mais surtout développer du code sur mesure. En effet, la plupart des projets d'émulation de consoles sur ESP32 utilisent des écrans TFT communiquant en SPI (une interface électronique utilisant 4 fils), alors que le modèle présent dans la console en utilise une vingtaine.
Des recherches sur Internet ont permis d'identifier des écrans similaires et notamment le brochage du connecteur. Sur cette base, j'ai pu y connecter un ESP32 supportant l'interface Intel I8080 avec un bus de données de 16 bits car c'est bien celle-ci qui est utilisée. Les commandes étant généralement standards, j'ai pu récupérer le code identifiant le contrôleur et valider qu'il s'agissait bien d'un contrôleur GC9306. Ayant acheté un lot de consoles (une habitude, j'en casse généralement au moins une lors des bidouilles), j'ai aussi pu valider que tous les écrans employaient des écrans avec le même contrôleur !
Afin de me faciliter la vie, j'ai conçu un PCB sur mesure pour y connecter un écran issu d'une console à un ESP32, avec au passage de quoi y connecter des boutons poussoirs pour tester un futur émulateur. La conception du PCB a été un peu laborieuse, il y a eu des ratés dans le routage, mais j'ai pu avoir un système fonctionnel.
Et après beaucoup de tests avec l'environnement ESP-IDF d'Espressif et de tentatives loupées, j'ai réussi à afficher ce que je voulais sur cet écran !
Afficher des images c'est bien mais pouvoir réagir sur des appuis de boutons c'est mieux ! Une fois le contrôleur d'écran contrôlé par l'ESP32, je me suis attaqué aux boutons. Vu le nombre de _GPIOs_ restant, je me suis orienté vers un multiplexeur d'entrées/sorties en I2C que je connaissais assez bien, le MCP23017 (déjà utilisé avec un Raspberry Pi). Le PCB du prototype s'est ainsi vu greffer une version minuscule de ce chip (package VQFN), et le code permettant de gérer les appuis sur les boutons poussoirs reliés au MCP23017 a été assez rapidement écrit.
À partir de là, le plus dur était fait: j'avais terminé le code permettant de dessiner des pixels à l'écran et de savoir si des boutons sont appuyés. Enfin, c'est ce que je croyais jusqu'au moment où je me suis intéressé au logiciel qui allait me servir de base pour l'émulation des jeux...
Le meilleur projet d'émulation que j'ai trouvé est l'excellent Retro-Go (https://github.com/ducalex/retro-go) de Ducalex, et je me suis donc attelé à la création d'un fork pour intégrer mon prototype de console (oui, celui sous forme de grand PCB tout vert). Et ça n'a pas été sans mal.
En effet, afficher une image sur un écran TFT en pilotant le contrôleur GC9306 tout seul se passait plutôt bien, mais il se trouve que Retro-Go n'utilise que des écrans communiquant via une interface SPI et que son code (enfin, celui des composants de retro-core qui fait partie de Retro-Go) est optimisé pour un fonctionnement avec ce type d'écran. Il a donc fallu passer d'un code assez simple à un véritable driver d'écran optimisé permettant d'avoir à la fois une fréquence de rafraîchissement d'écran acceptable tout en s'accomodant du code de base des différents émulateurs et leur façon d'interagir avec l'affichage. Ce n'a pas été une mince affaire, mais après pas mal de galères je suis arrivé à un résultat acceptable. Ce n'est pas parfait car il y a encore quelques artefacts causés par les algorithmes de mise à l'échelle et de lissage, mais une fois le logiciel configuré c'est très fluide et réactif. Le support des boutons a quant à lui été une formalité, ne posant que quelques soucis à cause d'un GPIO mal configuré.
Afin de m'éviter un long et pénible travail de création de PCB complet permettant de remplacer celui de la console, j'ai pris la tangente et ai créé un ensemble de trois circuits inter-connectés qui viennent se greffer au circuit existant de la console, évitant ainsi de gérer la charge de la batterie et l'alimentation. L'installation de ce mod a été laborieuse, mais les photos ci-dessous donnent une idée du résultat final.
La soudure des fils émaillés utilisés pour aller «piquer» l'état des boutons de la console, le découpage à la barbare du circuit d'origine pour avoir suffisamment d'espace pour y loger un ESP32 et les placements dispersés des différents PCB pour cause d'espace vraiment restreint ont rendu la réalisation de ce mod assez complexe. Au final, ça m'aura coûté moins cher qu'un PCB complet entièrement refait, mais l'utilisation a montré que dans certains cas la console redémarre sans crier gare, certainement à cause d'un mauvais contact. J'ai par ailleurs ajouté la possibilité d'utiliser une carte micro-SD, en utilisant les derniers GPIOs disponibles sur le module ESP32. J'ai mis la console moddée dans les mains de mes ados durant les fêtes de fin d'année, et ils ont bien aimé pouvoir y jouer malgré les quelques défauts identifiés.
J'ai pris le temps de faire une version bien propre des trois PCBs utilisés dans mon mod, si jamais il prenait l'envie à certains de vouloir reproduire cette bidouille. J'en ai profité pour documenter ce projet sur un site dédié (https://virtualabs.github.io/tsing-tao-console-mod/), la console moddée ayant été baptisée TsingTao sur une idée de Tix.
Cependant, plusieurs choses ne vont pas avec ce mod:
J'ai donc entrepris au début de cette année 2026 de voir ce que peut donner un circuit imprimé complet qui viendrait remplacer celui vraiment cheap présent dans la console d'origine. Pour ce faire, j'ai modélisé la console en question sous FreeCAD pour avoir une idée précise de la forme de ce dernier et des emplacements des supports de vis, afin qu'il rentre parfaitement dans la console. C'était l'occasion d'expérimenter un peu plus la modélisation avec FreeCAD et les moyens de le faire collaborer avec KiCad !
Les prochaines semaines seront normalement consacrées à la conception et l'assemblage d'un tel circuit imprimé, avec je l'espère un test concluant !
Je traînais à Gifi avant les fêtes de Noël lorsque je suis tombé sur une montre connectée à un peu plus de 10 euros. Elle m'a rappelée mes déboires avec certaines smartwatches trouvées sur AliExpress, à la fois dans sa forme et dans les fonctionnalités suggérées par les photos de cette dernière affichées sur la boîte. Je me suis donc délesté d'une dizaine d'euros et suis reparti avec, dans l'idée de l'analyser durant un live Twitch. Et je n'ai pas été déçu !
Je planifie début janvier 2025 un live Twitch en annonçant que je vais m'amuser à analyser cette montre connectée, que ce soit au niveau de son électronique ou de son application associée. Je suis relativement curieux de savoir comment toutes ces fonctionnalités sont possibles dans une montre à moins de 15€.
Une fois la boîte ouverte, je me retrouve avec une montre qui semble d'assez bonne facture, avec un bracelet silicone plutôt agréable à porter, un chargeur magnétique et une notice d'utilisation. La notice indique de charger la montre à bloc avant le premier démarrage, cependant elle ne réagit pas à mes manipulations. Je la laisse se charger pendant une bonne demi-heure, et elle fonctionne alors comme prévu. Peut-être était-ce du au fait que je n'y ai pas touché pendant un mois ? En tout cas le niveau de batterie en sortie de boîte semble être relativement faible.
J'installe en parallèle l'application mobile associée, Lefun Health, sur mon smartphone (même pas peur !), crée un compte pour l'application et appaire ma montre avec cette dernière. Elle est reconnue sans problème, et la mise à jour automatique de l'heure et de la date se fait bien. Cependant, l'application mobile requiert tout une floppée de permissions assez intrusives comme l'accès au carnets de contacts, mais vu que la montre est censée pouvoir afficher les appels reçus, il est possible que ce soit normal.
L'application propose toute une floppée de thèmes de cadrans (ou watch face) sur la montre, mais à ma grande surprise la plupart sont payants et impossible d'en installer via mon smartphone qui tourne sous /e/OS.
Un aspect de la montre m'a tout de même intrigué. Comme l'expliquait Stéphane Marty dans son excellente vidéo intitulée Montre connectée intelligente à 2€ : anatomie d'une arnaque Aliexpress, les capteurs permettant de mesurer la saturation en oxygène dans le sang, ainsi que ceux mesurant le rythme cardiaque par exemple sont relativement coûteux et sont composés de plusieurs éléments miniaturisés dont des récepteurs photosensibles qui doivent être visibles sous le boîtier.
En regardant de plus près le boîtier de la montre, on observe la présence de quatres lentilles qui peuvent correspondre à ce type de capteurs. Néanmoins, il est difficile sans ouvrir ladite montre de savoir exactement quelle technologie est utilisée.
Je fais une série de mesure avec la motre portée sur mon bras, et elle donne des résultats qui semblent être acceptables. Lorsque les fonctions de mesure sont utilisées, que ce soit le rythme cardiaque, la saturation en oxygène ou la pression artérielle, les lentilles au dos du boîtier de la montre clignotent en rouge.
Je décide afin de tester la fiabilité de ces capteurs de placer la montre sur mon tapis silicone, utilisé habituellement pour les travaux de soudure, et de voir si déjà la montre se rend compte qu'il y a comme un souci. J'active le mode d'analyse de fréquence cardiaque et pose la montre à plat sur le tapis: après plusieurs secondes d'analyse, l'écran affiche différentes valeurs et enfin la synthèse des mesures.
Mon tapis serait-il ... vivant ? Je fais de même avec la mesure de saturation en oxygène, et la mesure de pression artérielle: à chaque fois la montre arrive à obtenir des mesures bien qu'elle ne soit pas portée sur un bras.
Je décide alors, pour en avoir le cœur net, d'ouvrir purement et simplement la montre afin de mettre à nu son électronique, exactement comme Stéphane Marty l'avait fait avec une smartwatch en provenance d'AliExpress.
L'ouverture du boîtier de la montre est un peu laborieux, je m'y attendais car il est marqué sur le site du distributeur (Gifi) que cette dernière est étanche:
Cependant, après quelques efforts à base de scalpel et d'outil adapté, j'arrive dans un premier temps à retirer le cache situé sur l'arrière du boîtier, celui se trouvant au contact de la peau du bras, et découvre la présence de quatre LEDs sur un circuit flexible, avec une sérigraphie indiquant "TS12-3_L21_KEY+LED_V1.0". Aucun capteur biométrique de présent, simplement des LEDs et un bouton poussoir connecté sur un PCB flexible !
Pour vous donner une idée, la photo ci-dessous montre un ensemble de capteurs de la Fitbit Surge où l'on peut voir des LEDs et un capteur photosensible utilisé pour mesurer les pulsations cardiaques (entre autres).
Je réussis ensuite à retirer l'écran et découvrir l'intérieur de la montre, et à ce moment la supercherie ne tient plus. La montre possède une petite batterie (annoncée à 200mAh) reliée à un petit circuit imprimé, auquel est aussi connecté un écran avec dalle tactile, un vibreur, un haut-parleur et un microphone. Pas de trace de capteur, juste ce qui ressemble à un système-sur-puce JieLi AC6958C6 en charge de la gestion de l'écran, de l'audio, de la connectivité Bluetooth, ainsi que des entrées utilisateurs.
Le circuit contient aussi un accéléromètre (utilisé par exemple pour déclencher des photos lorsque la montre est secouée) et une puce gérant la dalle tactile (BL6133).
Aucune trace de puce électronique ressemblant à un capteur de rythme cardiaque ou de mesure de saturation d'oxygène dans le sang, ni de capteur photosensible. Il y a fort à parier que les valeurs affichées par la montre sont tout simplement générées de façon aléatoire dans une plage de valeurs considérées comme normales.
Une smartwatch à 12 euros, cela semblait alléchant mais ce n'est au final pas bien différent de celles vendues sur AliExpress et qui ne correspondent pas aux promesses faites par le fabricant. Là où je suis étonné, c'est de trouver ce type de produit en rayon chez Gifi.
J'ai parcouru la notice en long et en large, et celle-ci mentionne pourtant des fonctionnalités qui sont simplement absentes du produit, mais qui semblent être simulées par ce dernier, en particulier les fonctions de suivi de santé. La notice mentionne certes que les données mesurées ne doivent pas être utilisées à des fins médicales, ambulatoires ou diététiques. Je peux comprendre pourquoi.
Le projet CutcutGo, qui vise à fournir un firmware de remplacement pour la Maker de Cricut, avance plutôt bien. En effet, j'ai pu boucler le développement d'un bootloader permettant la mise-à-jour du firmware de la machine via USB, ce qui permet une maintenance plus simple et évite de devoir utiliser le connecteur situé sous la machine pour déployer une nouvelle version du logiciel.
C'était à mon sens une des premières fonctionnalités critiques que je devais implémenter pour permettre aux beta-testeurs de tester facilement les versions en cours de développement et de pouvoir restauter une version fonctionnelle en cas de souci, et cela sans avoir à sortir un programmateur.
J'ai aussi pu améliorer la façon dont le micro-logiciel gère le démarrage et l'arrêt de la machine ainsi que la calibration automatique du moteur de l'axe X afin de pouvoir s'adapter aux légères différences qu'il existe entre les machines. On s'approche de plus en plus de quelque chose d'utilisable, même si certaines fonctionnalités sont encore manquantes... Il n'est pas encore possible d'utiliser une connexion Bluetooth Low Energy pour piloter la machine, et la fonctionnalité de print then cut disponible sur la machine d'origine est loin d'être implémentée. Ceci dit, je suis très satisfait du résultat et de comment le projet avance, sachant que je le développe seulement durant les streams (à raison d'une soirée par semaine).
Ce projet est quasi terminé, mais comme dans tous mes projets c'est la fin qui est très difficile à gérer. J'ai un prototype entièrement fonctionnel, que je vais passer à des collègues dans un futur très proche pour qu'ils le testent et me donnent leur avis sur la complexité et l'originalité des tâches à réaliser, sachant que cela doit convenir au débutant tout comme au reverser confirmé.
Je pense attaquer la finalisation de ce projet courant novembre, mais à mon humble avis il ne sera pas bouclé avant janvier 2024. Ça me fait mal de l'écrire, mais je sais que la fin d'année va être pas mal remplie donc je ne prévois pas grand chose pour décembre.
J'avais pris une bonne résolution en janvier de cette année, celle de ne pas m'éparpiller dans mes projets comme je le fais d'habitude, sans rien terminer (qui a dit ADHD ? -- faudra qu'on en parle un des ces jours par ailleurs...). Et je crois que pour le moment, à l'exception d'un ou deux streams Twitch où il fallait absolument que je me change les idées, j'ai pour le moment réussi à m'y tenir.
Cependant, je dois avouer que ce n'est vraiment pas simple. J'accumule du matériel acheté au cours de l'année dans une boîte, la boîte des "trucs à bidouiller plus tard", qui commence à être bien remplie. J'ai de quoi hacker pour faire des consoles portables à base d'ESP32, un téléphone opensource, des trucs permettant de hacker des protocoles radios, des badges électroniques cools, et plus encore. Mais globalement pas assez de temps pour ne faire que 10% de tout cela.
Et ça ne va pas s'arranger, car il y a tout le temps un truc qui capte mon attention et me tend les bras en attendant que je cède à la nouveauté et qu'il vienne s'ajouter à la longue liste de trucs super intéressants que je dois faire mais qu'en fait non, car je lutte pas mal pour rester sur mes deux projets principaux. Sauf que j'ai fait une rechute, récemment.
J'ai cédé à un caprice technologique, aucune idée du pourquoi. Un jour, je traînais sur Amazon et je suis tombé sur un clavier Qwerty 60%. Un petit clavier mécanique, avec des beaux switchs et un format très intéressant. Et je me suis dit que ça serait une bonne idée de me mettre à un clavier qwerty, et tant qu'à faire tester ce clavier. Oui, ça fait des années que des collègues me demandent pourquoi je n'utilise pas de clavier Qwerty pour le développement, et effectivement, pourquoi ? Alors j'ai craqué. J'ai acheté ce petit clavier 60%, ai reconfiguré tous mes systèmes pour l'utiliser, et ai passé une rude semaine à passer mes habitudes de Azerty à Qwerty. Pas simple, mais pas si éprouvant que cela.
Aujourd'hui, je ne regrette absolument pas d'avoir franchi le pas. Oui, le clavier Qwerty est une bénédiction pour le développeur: tous les caractères spéciaux utilisés dans les différents langages de programmations sont accessibles directement, le pavé numérique est inutile, et les caractères accentués ne sont pas si nécessaires que cela. Seul hic: mon clavier de laptop du boulot qui est en Azerty et qui m'embrouille de temps à autre le cerveau.
Alors oui, je suis content avec mon clavier 60%, mais il y a des choses que j'aimerais améliorer dessus. L'absence de flèches directionnelles se fait parfois sentir, tout comme les touches Page Up et Page Down. Et là je découvre qu'il existe des claviers 65% qui possèdent ces touches, et qui sont opensource de surcroit ! C'est un enfer. Je vais me fabriquer mon clavier 65% from scratch et je suis super content de cela. Non, je n'aurais jamais du mettre les doigts sur ce type de claviers, je me suis fait happé et je suis parti pour des années de customisation de layout et de discussions autour des différentes marques et types de switches mécaniques... Fuyez, pauvres fous !
Sans compter que ça va de fait casser mon assiduité à mes projets principaux.