まこと　の　ブログ

IR « Light » Gun avec Arduino - Mundo Yakara -

makoto — Fri, 08 May 2026 12:22:00 +0200

Pour faire suite à mes travaux précédents :

Ah wé quand même ! Presque deux ans et demi, et je n'avais pas pensé en parler ici…
J'en ai oublié comment j'ai trouvé sa première vidéo, mais toujours est−il qu'un camarade Colombien, @MundoYakara sur youtube, s'est inspiré de mon projet pour réaliser sa propre version de flingue !
Et le moins qu'on puisse en dire, c'est qu'elle est extraordinaire, autant que l'enthousiasme avec lequel il décrit, démontre et communique les détails opérationnels pour permettre à chacun·e d'obtenir un résultat similaire, si on veut bien s'en donner la peine !

C'est ça qu'on veut ! C'est une des raisons qui me pousse à partager mes travaux. Les voir repris et parfois améliorés me met en joie

Son site est foisonnant de sujets qui sauront intéresser gamers et bidouilleurheuses ! https://www.mundoyakara.com/

Voici les vidéos qu'il a réalisé sur le sujet :

CAP1 [Camara de Wii]: https://youtu.be/K_C604FbPDc

CAP2 [Codigo arduino]: https://youtu.be/3iE0Odys9mg

CAP3 [Mod de guncon]: https://youtu.be/htQh8Hk19M8

CAP4 [Circuito solenoide]: https://youtu.be/wORQgI4LfjM

CAP5 [imprime en 3d tu propia GUNCON]: https://youtu.be/70oEejEn5gk

Et les pages web associées :

https://www.mundoyakara.com/2023/10/wiimote-en-camara-infraroja-para.html
https://www.mundoyakara.com/2023/10/lightgun-con-arduino-pro-micro.html
https://www.mundoyakara.com/2023/10/convierto-guncon-en-lightgun-arduino.html
https://www.mundoyakara.com/2023/11/circuito-de-solenoide-para-lightgun-cap4.html https://www.mundoyakara.com/2023/11/imprime-en-3d-tu-propia-llghtgun.html

Décapotes -04-, circuit de positionnement d'image pour écran TV

makoto — Sat, 25 Apr 2026 20:56:00 +0200

Suite de la conception précédente :

Pour gagner énormément de temps sur ce sujet, étant donné que je partais de zero, je me suis fait aider par un professeur particulier qui s'appelle Claude, et parfois Gemini aussi.

C'est formidable d'avoir « quelqu'un » qui t'explique les choses, et traduit des exemples de code, ce langage obscure, en Français !

J'ai ainsi pu expérimenter ces prompts et me rendre compte du danger qu'ils représentent en terme de capacités cognitives qu'on pourrait vite perdre. Face à un tel outil, le cerveau humain est particulièrement faible, et vite tenté de déléguer trop le travail, au risque de perdre en capacité de réflexions. Sans compter le temps perdu dans des culs de sacs techniques, qui n'auraient pas dû se présenter…

− Dés que je demandais quelques chose du genre « je voudrais faire ça, dit moi comment faire », ça tournait mal. Beaucoup d'hallucinations, de code testés, de ratés, et parfois de code fonctionnel, mais qui décidément ne faisaient pas exactement ce que je voulais. Ça restait pourtant très séduisant pour cette feignasse de cerveau, malgré que je devenais incapable d'ajuster ce code à mon besoin, tout étant allé trop vite, pas eu le temps d'assimiler, ni de comprendre ce qui se présente. Pris dans ces boucles d'incapacités cognitive, obligé de réitérer sans cesse pour en sortir, mélasse dans la tête… wé, pas ouf.
− Par contre dés que j'exposais une directive claire « je veux faire ça, de telle manière, avec ces paramètres, écrit le−moi », ça se passait tout de suite mieux, et « on » me gratifiait au passage d'un « bravo, vous avez raison, ça fonctionnera bien mieux ainsi ». « Oui, je sais… *soupir* ».

Cantonné à un rôle de traducteur où de prof qui m'explique la technique, c'est très bien et moins coûteux pour l'humain que la méthode autodidacte classique. Évoquer des solutions envisageables passe aussi, mais il vaut mieux ne pas en demander plus, et faire le travail d'ingénierie soit même. Pour éviter de finir abruti et de se perdre…

Bref, à défaut il faudrait vraiment éduquer à employer correctement cette techno, où quelle disparaisse à jamais, ça ne sera pas plus mal.

Un quatrième circuit d'essais :

Allez-allez là, l'actualité ! Trêve de blabla, passons au concret !

Suite aux déconvenues précédentes, et ce qu'elles m'ont permis d'apprendre, j'ai tenté un schéma en − presque − tout numérique et de me passer des circuits vidéo spécialisés :

− Nous avons donc une adaptation de signaux en entrée, car l'IGS−PGM délivre un C−Sync hors normes à 5V d'amplitude.
− Le RP2040 qui va traiter intégralement le signal d'entrée, afin de sortir un nouveau C−Sync déphasable, par action sur le switch et les potentiomètres.
− Une porte ET logique 74HC08 pour réassembler C−Sync en sortie.
− Et un switch double pour inhiber le circuit, pour le cas où on ne voudrait pas traiter le signal.

Le programme µPython est disponible ici, et en annexe du billet.^[1]
J'ai aussi fait commenter le code Python afin qu'il soit accessible aux grands débutants.

Description rapide du principe de fonctionnement :

Le signal C−Sync entre sur GP0.
Il est traité par sm4 : StateMachine 0 hsync_flywheel afin « d'extraire » le signal H−Sync. En fait créer un signal respectant la norme vidéo avec une impulsions de 5 µs, calée sur les fronts de C−Sync, et continuant sur ce rythme lorsque les trous formés par V−Sync apparaissent. Le signal est disponible sur GP1 pour débug ou réutilisation opportune.
C−Sync in est utilisé par sm5 : StateMachine 1 vsync_pio pour « extraire » V−Sync. Donc créer une impulsion longue de 512 µs, calée sur les fronts de C−Sync. Le signal est disponible sur GP2.
Ensuite, l'action combinée de sm0 : StateMachine 4 front_montant Horizontal et sm1 : StateMachine 5 front_descendant Horizontal vont permettre, lorsqu'on appuie sur le bouton, de lire la valeur du potentiomètre horizontal et de déphaser le signal H−Sync. Ce signal est disponible sur GP3.
De même avec sm2 : StateMachine 6 front_montant Vertical et sm3 : StateMachine 7 front_descendant Vertical pour déphaser le signal V−Sync. Signal dispo sur GP4.
~~Et enfin, sm6 : StateMachine 2 and_gate effectue une opération ET logique entre les deux signaux déphasés afin de reconstruire notre C−Sync déphasé en sortie.~~ (finalement remplacé par une porte logique physique plus fiable)

Voici quelques chronogrammes (avec un déphasage notable en vertical et horizontal) pour voir ce qu'il en est à chaque étapes clef du circuit :

Et une petite vidéo démonstrative :

Et de deux !

Conclusion de l'expérimentation,

On a donc un programme « full states machines » indépendant du CPU du microcontrôleur, ce qui permet une cadence de génération des signaux très précises.
Le CPU n'est là que pour gérer les boutons et la lecture des potentiomètres.

Tout fonctionne bien et sans gigue, pour ce programme tout à fait adapté à l'IGS−PGM, c'est je pense le montage qui constituera la carte fille que je vais donc intégrer à mon péritel multiple !

À moins que… Hum, j'ai testé le montage sur quelques consoles, Sega ou Nintendo, et ça ne fonctionne pas du tout…
J'ai regardé un peu les signaux émis par ces machines, et j'ai eu quelques surprises qui m'ont d'ailleur fait retarder la publication de ce présent article, et dont je parlerais peut-être une prochaine fois.

À suivre…?

Ressources :
https://rocelec.widen.net/view/pdf/en7p9sshgt/GENNS00351-1.pdf
https://zestedesavoir.com/tutoriels/2256/de-la-logique-aux-processeurs/des-maths-a-lelectronique/
https://www.ti.com/lit/ds/symlink/sn74hc08.pdf
https://www.eurobot.org/wiki/fr/informatics/lire_les_codeurs
https://docs.micropython.org/en/latest/library/rp2.StateMachine.html
https://docs.micropython.org/en/latest/library/rp2.html
https://www.onetransistor.eu/2021/02/rpi-pico-pio-state-machine-square-wave.html
https://tutoduino.fr/pio-rp2040/
https://www.developpez.net/forums/d2149816/general-developpement/programmation-systeme/embarque/raspberry-pi/rpi-pico-utilisation-pio/
https://www.raspberrypi.com/news/what-is-pio/
https://gregchadwick.co.uk/blog/playing-with-the-pico-pt4/
https://pip-assets.raspberrypi.com/categories/610-raspberry-pi-pico/documents/RP-008355-DS-1-raspberry-pi-pico-python-sdk.pdf?disposition=inline
https://pip-assets.raspberrypi.com/categories/814-rp2040/documents/RP-008371-DS-1-rp2040-datasheet.pdf?disposition=inline
https://scanlines.xyz/t/tutorials-for-generating-video-sync-signals-with-arduino/104

Note

[1] ci-dessous

Décapotes -03-, circuit de positionnement d'image pour écran TV

makoto — Sun, 22 Mar 2026 15:42:00 +0100

Suite de la conception précédente :

Avant de tenter de résoudre le problème du trou dans H−Sync, j'ai voulu trouver une solution à la stabilité de la synchro sortante afin d'obtenir une image la plus nette possible, et ce même si le circuit à base de PLL propose une qualité d'image tout à fait correcte.

Mon côté perfectionniste doublé de curiosité m'emmena faire un tour du côté du monde merveilleux de l'Arduino et de l'ESP32. Malheureusement les quelques essais que j'ai pu réaliser n'ont pas donnés les résultats escomptés, et étaient parfois pire qu'avec mon précédent circuit.

Quelques temps ont passés avant que je sois poussé à m'intéresser au Raspberry Pi Pico, et plus particulièrement la carte de WaveShare RP2040-ZERO.

J'étais passé jusqu'alors complètement à côté de cette puce. Certes j'avais eu vent de son existence et de la « mode » entourant sa sortie, beaucoup de monde s'y mettait, sauf moi. Comme souvent j'ai plusieurs trains de retard sur les technos, que je sais laisser passer tranquillement avant d'en avoir réellement besoin. Idem pour tout ce qui est LLM + prompt d'intelligence simulée, pas besoin. Vous lisez un type qui lit encore sa musique classée dans des dossiers, en local sur son appareil. Pas de méta−données, rien. Pas besoin.

Bref. J'ai donc découvert le RP2040 et entrevu une potentielle solution pour mon problème, en comprenant ce qu'il en était des States Machines, ces machines intégrées à la puce à qui on s'adresse en assembleur et qui roulent au rythme des cycles d'horloges, indépendamment du code adressé au processeur.

Vraiment très intéressant, quand on sait la vitesse à laquelle c'est capable de monter sans sourciller.
C'est bien simple, j'ai pu coder des exemples de génération de signaux de manière classique, à travers le processeur et demander la même chose aux States Machines et le résultat à l'oscilloscope était sans équivoque tellement meilleurs avec ces dernières.
Pour plus d'info, il y a cette vidéo qui explique très bien ce qu'il en est des Machines à état et cette page aussi..
Je comprend maintenant l'engouement pour ce Raspberry Pi Pico !

Un troisième circuit d'essais :

J'ai donc envisagé ce schéma, avec une nouvelle fois la structure basée sur le circuit séparateur de synchro LM1881 en entrée, les portes logiques 74LS132 en sortie, mais utilisant le RPi Zero pour le traitement du signal.

Particularité ici très importante, le RP2040 fonctionnant en logique 0−3,3V, il faut impérativement adapter les signaux qu'on lui applique, ce que je fais ici à l'aide d'un circuit basé sur le transistor MOSFET BS170 montés ainsi en adaptateur de niveau logique.

Je dispose maintenant d'un analyseur logique, ce qui est bien pratique pour montrer facilement les signaux. J'en profite donc pour donner un relevé des signaux d'entrée/sortie du LM1881, agrémentés de diverses mesures intéressantes…

Après plusieurs itérations, j'ai pu écrire ce programme µ−python pour le RP2040-Zero (dispo aussi en annexe à ce billet), pour déphaser les signaux.

Il utilise quatre State Machines pour déphaser les signaux. Les potentiomètres et le bouton sont gérés par le CPU. Lorsqu'on appuie sur le bouton, on passe en mode lecture de la valeur des pots, ce qui permet donc de décaler l'image en les réglants, puis de mémoriser ces réglages en rappuyant sur le bouton.

Voyons ce que donnent les signaux :

− En blanc, le C−Sync d'entrée,
− En marron, le V−Sync de sortie du LM1881, qui entre dans le RP2040-Zero en GP5,
− En rouge, le C−Sync de sortie du LM1881, qui entre dans le RP2040-Zero en GP14,
− En orange, le V−Sync déphasé en sortie GP6 du RP2040-Zero, qui entre dans le 74LS132,
− En jaune, le C−Sync déphasé en sortie GP15 du RP2040-Zero, qui entre dans le 74LS132,
− En vert, la sortie du 74LS132, avec V−Sync + C−Sync réassemblés.

Le circuit présente alors évidemment le même problème que le circuit N°1, avec la problématique du double trou…

Ici les signaux zoomés sur les impulsions verticales, la normale (donc indésirable), puis la déphasée.

Et enfin un zoom sur les tops de synchro horizontaux pour apprécier le déphasage obtenu :

Conclusion de l'expérimentation,

J'obtiens ici exactement le même résultat qu'avec le circuit N°1 étudié précédemment à base de monostables, à ceci prés que la sortie vidéo est plus propre et sans gigue problématique !
Le trou est toujours présent donc, et avant d'imaginer traiter le signal au complet avec les States Machines − c'est à dire utiliser uniquement un Pi Zero −, mes compétences en programmation du RP2040 étant très limitées, j'ai voulu continuer avec une solution analogique en entrée.

Une piste intéressante… :

J'ai donc consulté quelques datasheets et vu des oscillogrammes intéressants produit par les puces LMH1980 et EL1883. Ce sont tous deux des séparateurs de synchro, qui ont la particularité, contrairement au LM1881, de sortir non seulement V−Sync, mais aussi H−Sync, avec la promesse que celui-ci soit continu.

Formidable ! Emplit d'espoir, je me suis donc procuré les deux, dans l'idée d'achever ce projet rapidement.

Trouvées uniquement au format CMS, j'ai dû les souder sur des mini-plaquettes adaptatrices.

L'avantage avec ces deux circuits intégrés, c'est qu'ils peuvent être alimentés en 3,3V, rendant l'adaptation en niveau logique inutile, à partir du moment où l'on divise la tension des signaux d'entrée pour ne pas excéder 3,3V. Le 74LS132 pouvant lui aussi fonctionner en 3,3V, on peut se passer définitivement du 5V. J'ai alors élaboré ces schémas de montage grâce à la documentation idoine :

Le montage LMH1980 qui viendrait en remplacement du bloc séparation de synchro et adaptation de niveau logique :

EL1883 qui viendrait en remplacement du bloc séparation de synchro et adaptation de niveau logique :

NB: les filtres RC chroma filter de ces montages ne sont pas utiles dans le cas présent, puisqu'on ne travaille pas en vidéo Composite. On peut donc les omettre.

Conclusion des essais avec ces deux puces,

Déception !
J'y ai cru, mais non… Le signal H−Sync n'est pas continu à l'endroit de l'impulsion V−Sync. En fait au lieu d'un état bas, c'est un état haut qui subsiste à cet endroit, c'est la seule différence avec le signal C−Sync qu'on utilisait avec le LM1881.

À priori, l'explication résiderait dans le fait que le signal de synchro issu du système IGS−PGM ^[1] ne présente pas les « serration & equalization pulses », ce dont auraient besoins ces circuits intégrés pour être capable de générer les impulsions horizontale durant ce temps.

Autre chose notable, les sorties horizontales et verticales des EL1883 et LMH1980 produisent en sortie des impulsions assez différentes, par rapport au signal IGS−PGM entrant.

Voici un tableau récapitulatif :

         |IGS−PGM | LMH1980 | EL1883 | LM1881
—————————————————————————————————————————————
H−Pulses | 6,3 µs |  2,3 µs | 5,2 µs |   5 µs
V−Pulses | 518 µs |  628 µs | 512 µs | 458 µs

Et pourtant ça ne pose pas de problème à l'affichage correcte de l'image sur la TV… On constate donc très bien − comme je l'évoquais dans un billet précédent − que ce circuit ne sépare pas réellement les signaux, mais les recrée en respectant la norme vidéo.

Donc pour reconstruire une synchro pas besoin de mesurer précisément l'impulsion en entrée on peut la fixer arbitrairement !

Une information importante que j'avais perdue de vue, et qui va permettre d'avancer vers une solution basée sur l'utilisation du RP2040-Zero comme unique module de composants nécessaires, remplaçant alors tout ça :

À gauche le circuit N°1, en haut à droite le circuit N°2, à droite le circuit N°3 et les essais sur LMH1980 et EL1883…
En bas à droite le RP2040-Zero !

À suivre…

Note

[1] ni la Megadrive, ni la GameCube d’ailleurs…

Pocket SDVX pico, Makoto's edition -5-

makoto — Sat, 27 Dec 2025 16:55:00 +0100

Suite des précédents travaux :

Je ne me suis pas rendu compte du temps qui passait − autour d'une année lol − assez occupé sur d'autres sujets en partie chroniqués parmi ces pages…
Mais enfin ! J'ai compilé toutes mes sources, apporté les corrections nécessaires et mis tout cela en ordre pour que cela soit digeste et exploitable.
Je vais donc décrire tout ça, en espérant que cela en motive certain·e·s à se lancer dans la reproduction de l'objet, et pourquoi pas dans des améliorations/modifications ou de nouvelles fonctions. Vous me montrerez ça !

Hors usage personnel, la seule condition au repartage étant de respecter la licence CC-BY-SA 4.0 voulue par Speedy Potato, l'auteur originel du contrôleur sur lequel j'ai basé mes travaux, en citant également Woody Tsai (je n'ai pas trouvé de sources le concernant, il ne semble pas partager ses travaux autrement qu'en mode « hey tavu ce que j'ai fait… », la jeunesse en mal de reconnaissance sur les rézo ou bien en mode portfolio d'une activité lucrative, mais puisque je me suis inspiré de son idée de dessin… Voilà).
On trouvera donc en annexe à ce billet deux archives.

Pocket-SDVX-Pico MAKOTO final.zip :

Cette archive contient deux dossiers principaux et une liste des composants électro-mécaniques dans un fichier tableur.

Le dossier PRODUCTION, pour celleux qui souhaiteraient reproduire tel quel mon contrôleur :

− Il y a les fichiers STL pour imprimer les pièces 3D.
− Les fichiers vectoriels SVG pour la découpe laser en PMMA transparent.
− Et les fichiers Gerber dans plusieurs archives zip pour faire fabriquer les plaques. On a besoin de la plaque PCB qui constitue le circuit électronique et la plaque PLATE qui constitue la plaque décorative supérieure.

Cette dernière existe en 3 versions,
− PLATE est celle que je présente ici, depuis le début de ces travaux,
− PLATE2 est quasi identique sauf qu'elle ne présente pas deux grands trous ronds pour les boutons d'encodeur − knob −, mais deux petits trous pour laisser juste dépasser la tige de l'encodeur, donc dans le cas où l'on souhaiterait que le knob soit placé au dessus de la plaque et non incrusté comme c'est le cas avec la PLATE. Ce qui laisse la liberté de choix pour le diamètre des knob !
− PLATE3 est prévue pour être utilisée à la manière des modèles Pocket SDVX Pico v4 ou v5 originels, c'est à dire qu'on va clipser les switchs MX dans cette plaque, et qu'il n'y aura pas d'autres plaque par dessus. J'en parlais dans le premier billet sur le sujet, avant de faire d'autres choix techniques qui m'ont menés à la PLATE.
Donc avec PLATE3 on n'utilisera pas les supports de switch MX imprimé 3D, ni les plaques en découpe laser, Le contrôleur sera alors moins épais et le cadre formant le boîtier n'ira pas avec non-plus. Il faudra que vous bricoliez quelque chose vous-même car je n'ai pas mené cette version à son terme.

Et pour fabriquer tout ça ?? Une petite vidéo sous-titrée !

En complément, je reposte la vidéo de l'assemblage 3D du billet N°3 en bas de cette page.

Le dossier SOURCES, pour celleux qui souhaiteraient modifier quoique ce soit au contrôleur :

− Il y a les ressources Kicad 7 pour la PCB et les PLATE, PLATE2, et PLATE3.
− Les fichiers FreeCAD 1.0 pour la modélisation 3D et 2D.
− Ainsi que les fichiers des graphismes que j'ai mis tant de temps à dessiner,
qui ont permis de fabriquer les ressources du dossier PRODUCTION que j'ai décrites.

Le contenu de l'archive est aussi disponible sur github :

Firmware Pico-Game-Controller-20220705-v4 Makoto-edition.tar.gz :

Comme son nom l'indique, elle contient le firmware du contrôleur USB.

Le binaire à flasher sur le Raspberry Pi Pico se trouve dans le dossier build_uf2

Pour opérer, il suffit de maintenir le bouton poussoir du Rpi Pico enfoncé tout en connectant le câble USB-C à l'ordinateur, puis de relâcher la pression.
Un média amovible est alors monté automatiquement par le système d'exploitation de votre machine, et il suffit alors de glisser le fichier Pico_Game_Controller_Makoto-edition.uf2 dans ce média. Sitôt fait, le média sera automatiquement démonté et le Rpi Pico redémarrera. En principe le contrôleur de jeux doit alors être disponible dans l'ordinateur.

Le reste des fichiers constituent les sources du programme que j'ai modifié pour prendre en charge les leds et boutons supplémentaires, ainsi que les différents modes de couleurs additionnels.
Le SDK Rpi pico est lui aussi inclu, ce qui fait que si on a gcc, cmake et ninja installés sur son ordi, il suffira de lancer depuis le dossier build les commandes :

cd build
cmake ..
ninja

pour obtenir le binaire dans le sous-dossier build/src en fin de compilation.
Si ça se passe bien, on pourra ensuite modifier le programme à loisir en éditant les fichier .c et .h disponibles dans le dossier src présent à la racine.
Sinon, on peut aussi faire ça avec l'usine à gaz Visual Studio code…

Ce programme est donc basé sur le firmware 20220705, à ce que j'ai compris le dernier en date que j'ai trouvé concernant la v4 du contrôleur qui m'a servi de modèle.

Le contenu de l'archive est aussi disponible sur github :

Voilà, je pense que j'ai fait le tour de la question, on termine avec ça :

Pocket SDVX pico, Makoto's edition -4-

makoto — Sat, 13 Dec 2025 20:37:00 +0100

Suite des précédents travaux :

Le fond :

Au départ il était prévu que le dessous de l'appareil soit constitué d'une plaque imprimée 3D, notamment car celle-ci doit venir s'appuyer sur la plaque électronique afin de rigidifier la structure. Pour cela il est nécessaire de prévoir tout un tas de creux dans la plaques afin que la matière ne viennent pas contre les pattes soudées des composants.

J'ai à nouveau dû imprimer la pièce en deux morceaux, ainsi que des petites plaquettes

qui vont servir à consolider le collage à la cyanoacrylate.

Sont prévu les trous pour accueillir des inserts fileté de 4 mm de diamètre à destination des pieds en caoutchouc où des ventouses !

Voici l'intérieur de la plaque avec la vis de la ventouse qui dépasse. Il sera donc coupé à dimension.

On peut donc alterner à loisir entre pieds ou ventouses, à l'aide d'un tournevis pour le premier et en tournant l'objet à la main pour la seconde.
La vis dans le coin est celle qui ferme ce couvercle de fond, et elle sera complémentent cachée par le pieds en caoutchouc.

Plus tard j'ai envisagé la possibilité d'utiliser des plaques de PMMA transparente à la place de l'impression 3D. J'ai simplement eu l'idée de demander la découpe de deux plaques, une de 3 mm d'épaisseurs qui comporterait non pas les creux mais des trous, et l'autre de 2 mm pour venir fermer le tout.

La première plaque de 3 mm, puis la seconde de 2 mm par dessus :

La plaque de 2 mm est tout de même trouée pour laisser passer l'épaisseur du port USB du Rpi Pico qui reste là, et permettre d'appuyer sur son bouton de programmation.

Voulant suivre la même logique pour la fixation des pieds/ventouses, j'avais prévu des trous larges dans la plaque de 3 mm pour y mettre les inserts.

Mais ce fut une idée assez galère, car en fondant le PMMA boursouffle un peu en repoussant la matière fondue à la surface, ce qu'il a fallu gratter afin d'aplanir le périmètre autour de l'insert. Et comme l'insert dépasse dans la plaque de 2 mm, il a fallu élargir et le chanfreiner le trou correspondant… Bref, pas une partie de plaisir, alors qu'il suffisait de prévoir un trou plus petit et de le tarauder pour y créer le filetage qui aurait permis de visser les pieds/ventouses directement dans le PMMA, plastique suffisamment dur pour cela.

Autre déconvenue aussi, je l'évoquais dans ma série sur le pincab, le contour des plaques découpées au laser présente un angle de 3°, ce qui n'avait pas posé de problème pour la plaque de protection du dessus, mais ici, avec 3 + 2 mm d'épaisseur, c'est suffisant pour gêner quelque peu la mise en place des plaques. Il a donc fallu limer les 4 champs des deux plaques, afin de les redresser à 90°.

C'est tout bon, elles rentrent maintenant bien à plat, ouf !

Finitions :

Je l'évoquais plus haut, pour estomper la jointure du cadre du boîtier, j'ai une solution qui ne fonctionne qu'avec du plastique ABS.

En effet, le solvan qui permet de ramollir ce plastique n'est autre que l'acétone, et il est alors aisé de se confectionner du mastique coloré qu'on va utiliser pour combler toutes les imperfections. Une fois bien sec il suffira de limer et poncer jusqu'au résultat attendu. Toutefois il faut faire attention au ratio acétone/quantité de plastique, car j'ai remarqué que si la mixture est trop diluée, en séchant elle laisse des micro-bulles blanches assez disgracieuses.

Alors on verra toujours l'emplacement de la jointure, mais ça jure moins et au toucher, on ne la ressent plus sous les doigts.

On peut aussi pousser la chose jusqu'à poncer toute la pièce, de plus en plus fin…

Et ensuite polir et lustrer la surface jusqu'à obtenir cette brillance !

Une dernière chose à faire, est de chanfreiner les trous sur les plaques en PMMA pour permettre d'engager des vis à tête fraisée à fleur de la surface.

Fonctionnalités :

Une petite vidéo qui montre le montage des ventouses et leurs utilité :

J'ai dû bricoler le firmware d'origine afin de pouvoir attribuer des fonctions aux cinq boutons que j'ai ajouté sur les tranches.
Ceux de la tranche inférieure sont vu comme des boutons de gamepad et pourront servir en cours de partie.
Tandis que ceux de la tranche supérieure sont là pour configurer la déco.

Celui de gauche pour basculer entre le mode « color cycle » qui présente une vague de couleurs défilantes et le mode « turbocharger » qui permet aux « knobs » d'animer la vague de leds en rouge ou en bleu.
Celui de droite incrémente d'une couleurs parmi douze.

Pour bien comprendre, voici tout cela montré dans cette petite vidéo :

Conclusion et démonstration en jeu :

Combien ça coûte tout ça ?
Cher !! Pas en argent, mais en temps passé à créer.

À reproduire par contre ça ne devrait pas poser de difficultés et se faire en quelques heures, plus ou moins selon votre dextérité.

Le plus fatiguant sera je pense de se fournir en matériaux. Commander les plaques, imprimer ou faire imprimer le cadre en plastique, découper ou faire découper les plaques PMMA au laser. Et des heures de magasinage pour trouver les composants électroniques et mécaniques « qui vont bien »…
Mon exemplaire aura coûté 60€, pour info. Bien sûr cela dépend complètement du prix des composants et des tarifs des prestataires, donc c'est vraiment à titre indicatif.

Les sources du projet seront proposés dans le prochain et dernier billet.
Elles contiendront absolument tout, de l'électronique à la 3D, réalisées avec des logiciels libres.
Il y aura une vidéo de l'assemblage complet de l'appareil !

En attendant, on peut profiter !

Vidéo en cour de jeu qui montre les effets lumineux.

Galerie :

Voici quelques clichés des contrôleurs que j'ai réalisé pour moi et mes amis.

Modèle rouge au cadre de 2 mm d'épaisseur, knob de 22 mm argentés :

]
]

Le même, avec des knobs plus petits et colorés :

Changement des pieds :

Démontage :

Modèle gris au cadre de 2 mm d'épaisseur :

Modèle violet au cadre de 3 mm d'épaisseur :

À suivre…

Péritel multiple

makoto — Mon, 24 Nov 2025 21:36:00 +0100

Un peu de contexte,

Il y a bien longtemps, dans les années '90, j'étais l'heureux propriétaire de deux consoles de jeux, une Sega Master System et une PC Engine qu'on appelait plus simplement la NEC à l'époque.
Quasi toutes mes économies amassées au fil du temps y étaient passées, et il ne me restait pas grand chose mais suffisamment pour acheter un accessoire qui aurait dû me simplifier la vie : un quadrupleur de prises péritel.

En effet, celleux qui ont vécu l'époque savent à quel point il était pénible de brancher un appareil sur une télévision, sachant qu'elles étaient souvent disposées dans un coin peu accessible, voire dans un meuble dédié et que la manœuvre consistait alors à se munir de la dite prise péritel, plonger son bras derrière la télé, et à l'aveugle tenter d'aligner la prise dans celle de la TV… Une galère sans nom, sans compter qu'à force d'opérer, la prise de la TV avait tendance à devenir lâche et devenait alors source de faux contacts générant parasitage vidéo, coupe de son et autre nuisances si on n'avait pas pris soin de bien coincer la prise… Et malheur à celui qui toucherait par mégarde au câble péritel, provoquant alors le déséquilibre de ce savant réglage.
Voilà, donc ça, chaque fois qu'on voulait passer du magnétoscope, ou à une des deux consoles, misère !

Au supermaché de mon coin, j'ai donc déboursé 15 Francs, si mes souvenirs sont exacts, pour obtenir l'accessoire qui aurait donc dû me permettre de connecter jusqu'à 4 appareils sur la TV 36 cm à ma disposition.

Sauf que ! Ça n'a jamais fonctionné.
Le simple fait d'avoir plusieurs appareils connectés, même éteints, provoquait une perte de qualité d'image et de son sur l'unique appareil qu'on utilisait.

Débutant à l'époque en électronique, j'ai alors ouvert le quadrupleur et tenté de comprendre l'origine du problème.
Je ne me souviens plus de ce que j'ai conclu alors à la vue du circuit…

Par contre aujourd'hui en regardant cette plaquette en bakélite je peux dire que c'est d'une conception catastrophique !

Les quatre prises comportant 12 signaux sont simplement tous connectés ensembles… C'est à dire par exemple que l'appareil allumé envoyait son signal audio/vidéo à la TV, certes, mais aussi aux autres appareils !!! Et si on en allume plusieurs, c'est tout ce monde qui se « repisse dessus » (jargon d'électronicien) joyeusement, quelle horreur ! Surtout quand on sait aujourd'hui (l'ados de l'époque ne savait pas) qu'en plus de ça, les broches 8 et 16 des péritel envoient chacune 5 et 12 Vots. Heureusement que les puissances de tous ces signaux sont très faibles et n'ont pas détruit de matériel.

Je n'avais pas tout compris, cependant j'avais quand même pensé qu'il faudrait isoler les prises péritel les unes des autres, ce que j'avais fait en coupant le circuit des pistes à la surface de la bakélite.
Puis avec le peu de ressources dont je disposais j'ai imaginé et bricolé d'abord un connecteur à l'aide de dominos… Imaginez un peu, souder des fils sur le bornier de la prise péritel mâle, et d'autres sur le pastilles des broches des péritel femelles.
Ces fils sont ensuite vissés d'un côté du dominos noir pour la péritel mâle, et de l'autre côté, j'ai vissé des clous que j'ai coupé à dimensions. Ce montage devenant alors le connecteur mâle.
Puis les fils provenant des 2 broches péritel femelles sont vissés chacun d'un côté des dominos translucide, pour faire les connecteurs femelles. Suffisait alors d'insérer une des deux femelle sur le mâle, en jouant sur la souplesse du domino, ça n'était pas toujours facile mais ça fonctionnait…

J'ai retrouvé les dit dominos, j'ai tenté de reproduire la scène, imaginez juste les clous ne dépassant que de 5 mm :

J'ai donc dû percer le boîtier pour sortir les bottes de fils, on verra ces trous de plus prés ensuite.
Et oué, quand t'as pas de permis, pas de voiture, pas de magasin à proximité, tu te débrouilles avec ce que tu as sous la main.

Plus tard j'ai découvert l’existance d'un magasin d'électronique accessible en 20 min à pieds de l'école (et 20 min retour…) auprès duquel j'ai pu aller m'acheter des petits interrupteurs inverseurs. J'ai pu disposer du matériel de l'école, me permettant de simplifier mon montage, par une plaquette gravée sur laquelle j'ai soudés tous les fils dont je parlais ci-dessus, afin de les raccorder sur les interrupteurs :

Pour cacher la grand entaille faite dans le boîtier, j'avais collé du carton de chemise colorée. (notez l'isolant en chiffon quadrillé, utilisé là car les seules vis que j'ai trouvé étaient trop grosses et auraient fait court-circuit en touchant les pistes de ma plaquette).
Pour passer d'une péritel à l'autre, au lieu de débrancher un domino pour brancher l'autre, il fallait alors basculer tous les inverseurs dans la position opposée. C'était mieux, mais pas ouf, et on ne disposait là encore que de deux péritel en source audio/vidéo.

Retour à aujourd'hui,

Je l'évoquais dans le billet précédent, j'ai besoin maintenant de brancher plusieurs sources de jeux dans ma borne, dont l'écran est une TV avec sa péritel carrément pas du tout accessible… Même problème trente ans plus tard, mais compétences améliorées et augmentées notamment par l'accès « au net ».

Entre temps j'avais récupéré un autre boîtier « tout fait », avec un bouton pour sélectionner la prise péritel active, mais il ne fonctionne pas bien. Dés que 3 appareils sont branchés dessus, les signaux vidéos sont parasités… Décidément !

J'ai donc ressorti mon vieux quadrupleur avec l'intention de refaire complètement sa plaque !

Et pour cela il me faut une solution technique qui fonctionne correctement.
On trouve de l'info en ligne, et des choses pleines de promesses « spéciales rétro-gaming » à l'achat, mais je m'en suis détourné afin d'expérimenter des trucs, parce-que « c'est amusant ».

Cet été, j'ai donc conçu une première version à base de puces CD4066, que j'avais aperçue en démontant mon second boîtier, et bien mal m'en a pris.
Ce sont des puces qui permettent d'interrompre les signaux qui la traverse grâce à un signal de commande, un interrupteur commandé en somme, ce qui est tout à fait ce dont j'avais besoin, sauf qu'une fois le contact établi il était soumis à une résistant (Ron) d'une centaine d'ohms, ce qui dégrade évidemment la vidéo et le son.
J'ai fait confiance à ce que j'ai vu dans un matos du commerce… Décidément, y faut pas !
Ça fait que des conneries d'ingénierie haha, autant que j'en fais quoi.

Bref, je me suis ensuite tourné vers la vielle puce CBT3244, et visiblement c'est ce que d'autres bidouilleureuses utilisent, alors j'ai voulu vérifier en concevant un second prototype avec, et il fonctionne ! (oui c'est une plaque gravée à la main)

La résistance (Ron) n'est ici que de 3Ω (annoncé, j'ai mesuré parfois un peu plus du genre 5Ω) ce qui n'est pas suffisant pour altérer les signaux, par contre si la coupure des signaux vidéos est franche et sans problème, l'audio pose problème.

Le son, c'est une affaire plus complexe que la vidéo et pourtant on la sous-traite trop souvent. Ce sera le cas ici, je n'ai pas les compétences pour régler le problème qui est le suivant :
− Si on a plusieurs sources audio/vidéo branchées sur le quadrupleur et allumées en même temps, dans les moments de silence on peut entendre de manière ténue et altérée le son provenant des autres sources, malgré le fait que ces signaux soient effectivement bien coupés par le circuit intégré.

Comment s'accommode t'on de ça ?
− Et bah, il suffit d'éteindre les autres sources, évidemment ! Vu qu'on ne peut intrinsèquement utiliser qu'une source à la fois, ça n'a pas de sens de tout allumer en même temps (sauf sur la vidéo en fin d'article, vu que c'est pour la démonstration technique), le but du dispositif c'est vraiment juste de ne plus jamais avoir à brancher/débrancher ces satanées prise péritel des enfers !

Réalisation :

Voici donc le schéma revu et corrigé en cette fin d'année. Le projet Kicad est disponible en annexe à ce billet :

Il était donc maintenant possible de faire produire une jolie plaque vernie :

Souder l'intégralité des composants :

Et d'intégrer la plaque en lieu et place de l'originale en bakélite :

Et j'ai mis à profit les vieux trous que j'avais opéré y'a 30 ans pour passer les câbles utiles à la commande déportée, et d'autres choses dont je parlerais en détail dans un prochain billet :

Car j'ai en effet prévu la possibilité d'ajouter une carte fille de « traitement du signal » à enficher sur ces pinoches. Ainsi placées juste avant la sortie péritel, elle permettrait d’altérer le son et la vidéo suivant des besoins spécifiques, comme par exemple amplifier le son, la vidéo, intervenir sur le signal de synchronisation, etc.

Démo :

Une vidéo de démonstration, sur la borne avec quatre sources vidéos :

Ressources :
− https://github.com/michaelobed/rgb-switcher
− https://github.com/Numbski/open-source-scart-switch/wiki
− https://lite.evernote.com/note/0e0258de-6efd-4e66-9fd4-251252936ab0
− https://www.pcbway.com/project/shareproject/Mini_DIN_9_RGB_Video_Output_adapter_Sega_Mega_Drive_Genesis_2_for_video_mod_3DO_3771fb9e.html

Joystick Arcade pour Nintendo GameCube

makoto — Sat, 22 Nov 2025 21:49:00 +0100

La borne est en travaux !
En plus du PC « mame » je souhaite lui installer deux autres systèmes de jeux, dont l'un est la console GameCube.
Motivation ? Jouer à Ikaruga et SoulCalibur sur la borne avec les sticks arcade.
Sauf que ! Comment faire pour connecter ces derniers à la console ?

Avant de réinventer la roue, j'ai traîné sur le web à la recherche d'une proposition de circuit électronique.
J'ai eu un peu de mal à trouver ce que je cherchai, visiblement ça n'intéresse pas trop les foules… L'occasion de constater au passage que la manette GameCube n'était pas aussi électroniquement simple que ses aînées, et qu'il faudrait un circuit programmable pour faire le travail.

J'ai fini par trouver cette page, qui décrit comment construire un contrôleur maison, avec un Arduino, et surtout l’existence de la bibliothèque logicielle adéquate : https://github.com/NicoHood/Nintendo (que je joins en annexe à ce billet)

Le code C++ est vraiment très simple à adapter grâce aux exemples donnés, et j'ai alors pu assigner les numéros de broches d'un Arduino Pro Mini 5V aux boutons d'une manette GameCube et établir le schéma de câblage suivant :

Une fois un câble de manette de remplacement acheté, restait alors le plus long à faire, câbler les broches sur le joystick.

Ici le brochage est réalisé à l'aide de connecteurs « maisons », qui permettront d'interchanger le joystick entre plusieurs systèmes de jeu (USB ou GameCube pour le moment).

Le brochage du câble de la manette est le suivant :

Couleur  −   Usage 

Jaune    −   5V
Blanc    −   GND
Vert     −   GND
Noir     −   GND
Bleu     −   3,3V
Rouge    −   DATA

Voici le Scketch à inscrire sur l'Arduino, en ayant pris soins de charger la librairie de NicoHood :

https://github.com/makotoworkshop/Joystick_Arcade_GameCube

#include <Nintendo.h>

// Variables
#define Bouton_A  A1
#define Bouton_B  9
#define Bouton_X  A2
#define Bouton_Y  3
#define Bouton_START  A3
#define Bouton_L  7
#define Bouton_R  8
#define Bouton_Z  2
#define Direction_UP  6
#define Direction_DOWN  5
#define Direction_LEFT  A0
#define Direction_RIGHT  4

// Broche de communication vers la console GameCube
CGamecubeConsole gc_console(10);

// Structure de données de la manette
Gamecube_Data_t gc_data = defaultGamecubeData;


void setup() {
//  Serial.begin(115200);
  // Configuration des boutons en entrée avec résistance pull-up
  pinMode(Bouton_A, INPUT_PULLUP);
  pinMode(Bouton_B, INPUT_PULLUP);
  pinMode(Bouton_X, INPUT_PULLUP);
  pinMode(Bouton_Y, INPUT_PULLUP);
  pinMode(Bouton_START, INPUT_PULLUP);
  pinMode(Bouton_L, INPUT_PULLUP);
  pinMode(Bouton_R, INPUT_PULLUP);
  pinMode(Bouton_Z, INPUT_PULLUP);
  pinMode(Direction_UP, INPUT_PULLUP);
  pinMode(Direction_DOWN, INPUT_PULLUP);
  pinMode(Direction_LEFT, INPUT_PULLUP);
  pinMode(Direction_RIGHT, INPUT_PULLUP);
  delay(100);
}

void loop() {
  // Lecture des boutons
  gc_data.report.a      = !digitalRead(Bouton_A);
  gc_data.report.b      = !digitalRead(Bouton_B);
  gc_data.report.x      = !digitalRead(Bouton_X);
  gc_data.report.y      = !digitalRead(Bouton_Y);
  gc_data.report.start  = !digitalRead(Bouton_START);
  gc_data.report.z      = !digitalRead(Bouton_Z);
  gc_data.report.l      = !digitalRead(Bouton_L);
  gc_data.report.r      = !digitalRead(Bouton_R);

  gc_data.report.dup    = !digitalRead(Direction_UP);
  gc_data.report.ddown  = !digitalRead(Direction_DOWN);
  gc_data.report.dleft  = !digitalRead(Direction_LEFT);
  gc_data.report.dright = !digitalRead(Direction_RIGHT);

  // Stick analogique centré
  gc_data.report.xAxis = 128;
  gc_data.report.yAxis = 128;

  // Stick C centré
  gc_data.report.cxAxis = 128;
  gc_data.report.cyAxis = 128;

  // Gâchettes analogiques à 0
  gc_data.report.left = 0;
  gc_data.report.right = 0;

  // Envoi du rapport à la console de jeux
  gc_console.write(gc_data);

//  Serial.print("bouton Y = ");
//  Serial.println(gc_data.report.y);
  
}

RecalStick -2-

makoto — Sat, 15 Nov 2025 19:31:00 +0100

Suite de la création précédent :

Perçage de la ventilation :

Étant donné que le Raspberry pi 4 va chauffer à l'intérieur du boîtier, j'ai pratiqué deux trous de Ø30 mm sur les bords droit et gauche de celui-ci, afin de pouvoir disposer deux ventilateurs.

J'ai dû désaxer la perceuse à colonne car il n'y avait pas suffisamment de place pour cela.

Fixation du Raspberry pi 4 :

Comme évoqué lors de l'épisode précédent, il est malheureusement nécessaire de modifier le boîtier pour permettre au µ-Ordinateur de rentrer en place.

L'opération consiste à déplacer l'ouverture sur la droite, donc à élargir la découpe à droite.

Ensuite il faut coller une « rustine » dans le trou laissé à gauche, que j'ai préparé pour faciliter l'opération.

Une fois la rustine sculptée au ciseau, on peut présenter le Rpi :

J'ai collé deux cales d'épaisseurs pour faire reposer le boîtier/dissipateur thermique du Rpi sans gêner les ventilateurs qui s'exprimeront sur le dessous.

Comme le boîtier du Rpi est en butée dans la gorge de la façade, un bloc vissé à l'opposé suffit à le bloquer un place, pas besoin de chercher plus compliqué.

Câblage :

Sur la lamelle métallique nous avons trois connecteurs. La rallonge VGA, qu'il suffit d'aller brancher sur le VGA666 du Raspberry. La prise Jack d'alimentation, et la prise Jack stéréo pour la sortie sonore.

Sur la prise Jack d'alimentation, j'ai soudé quatre paires de fils − rouges et noirs −, trois équipés de connecteurs JST mâles qui recevront les JST femelles des ventilateurs et un pour alimenter le Raspberry en les soudants directement sur les pastilles adéquates du bus GPIO.
Sur la prise Jack stéréo, sont soudés trois fils − vert, blanc et noir − qui sont eux aussi directement soudés au dos du Rpi. Je réalise malheureusement que je n'en ai pas pris de photos.

Ensuite il s'agit d'attacher un peu tout ça pour y voir plus clair…

J'ai bidouillé les câbles pour interfacer le joystick à la plaquette du circuit USB afin de les faire passer par le gros bouton à quatre inverseurs.

Grâce à lui, les directions vont pouvoir basculer d'un quart de tour comme ceci :

désactivé  |  activé

− Haut     —> Droite
− Bas      —> Gauche
− Gauche   —> Haut
− Droite   —> Bas

Ce qui sera bien utile pour jouer à un jeu vertical sans être obligé de basculer l'écran sur le côté droit !

Quelques détails… :

Respectivement, le bouton inverseur désactivé/activé, le câble USB de la plaquette contrôleur de jeu ainsi que le connecteur HDMI (la prise USB-C attenante ne va finalement pas servir car il n'est pas possible de brancher son câble sur le RPi, pas la place),

la lamelle métallique avec prise d'alimentation 5V, prise sortie VGA, prise sortie sonore, et enfin le Raspberry Pi 4, sur lequel on branchera le câble USB précédemment cité (et tous les autres joystick qu'on souhaiterait pour jouer jusqu'à 4 joueurs·euses).

Et enfin une mise en situation, branché sur un écran cathodique, donc via la prise VGA vers péritel, sortie jack stéréo vers péritel aussi, et la prise USB branchée sur le RPi. Sans oublier l'alimentation 5V nécessaire au RPi et aux ventilateurs:

Je reprécise au passage donc, étant donné que la prise USB du contrôleur de jeu est externe, le RecalStick est aussi utilisable en tant que stick arcade USB passif, à brancher sur un ordinateur ou une console. Dans ce cas, évidemment il n'est pas besoin de l'alimenter un 5V.

Galerie :

Sous un angle plus rasant…

À suivre…

Décapotes -02-, circuit de positionnement d'image pour écran TV

makoto — Mon, 03 Nov 2025 18:59:00 +0100

Suite de la conception précédente :

Le premier circuit ayant donc montré ses limites et défauts, nous allons ici tenter de les corriger.

Un deuxième circuit d'essais :

À force d'expérimentations, j'ai fini par aboutir à ce schéma :

Ce circuit fonctionne relativement bien, mais avant de tirer les conclusions (oui je ne suis pas un politique ou un journaleux qui tire les conséquences, faut arrêter avec ça !), regardons comment il fonctionne, car encore une fois, ce sera salutaire pour la suite à donner.

Nous avons donc à nouveau l'étage de séparation de synchro basé sur le circuit intégré LM1881, nécessaire pour récupérer le signal V−Sync.

Cet étage est cette fois connecté à des PLL (boucle à verrouillage de phase) CD4046, le type de montage à système bouclé dont la théorie me donnait des sueurs froides à l'école… Mais bon c'est plus facile à expérimenter… un peu.

La PLL est ici employée afin de générer un signal carré d'une fréquence égale au signal d'entrée. Une fois la fréquence « accrochée » par le VCO (oscillateur contrôlé en tension), led témoin allumée par l'entremise du potentiomètre, ce système bouclé va nous permettre de déphaser le signal carré en continuant de jouer du potentiomètre. La limite étant le décrochage du VCO au delà d'une certaine plage de fonctionnement où l'on perd alors la fréquence.

Les composants R1, R2 et C1 sont donc calculés et vérifiés expérimentalement pour offrir la plage de fonctionnement la plus large possible sans décrocher de la fréquence d'entrée.
Pour H−Sync et ses 15,625 kHz, R1 = 100 kΩ, R2 = 100 kΩ, C1 = 1 nF.
Pour V−Sync et ses 59 Hz, R1 = 8,2 kΩ, R2 = 18 kΩ, C1 = 1 µF.

Voici une démo vidéo de la phase d'accrochage de la PLL, avec le signal zoomé sur V−Sync, on regarde la sortie 3 du CD4046.

On prend soin d'observer attentivement la valeur de fréquence affichée en bleu sur l'oscilloscope, ainsi que la réaction de la led.

La sortie de chaque PLL est ensuite envoyé à un monostable, pour, comme nous l'avons étudié précédemment, générer une impulsion de largeur fixée grâce au potentiomètre associé.

Voyons cela avec des oscillogrammes :

Ici nous voyons le déphasage obtenu pour H−Sync. Le signal C−Sync (en jaune), la sortie 3 de la PLL (en bleu), et la sortie Q7 du monostable (en vert) qui déclenche son impulsion sur le front montant du signal de sortie du CD4046.

Et de la même manière, nous voyons le déphasage obtenu pour V−Sync. Le signal V−Sync (en jaune), la sortie 3 de la PLL (en bleu), et la sortie Q9 du monostable (en vert).

Une petite vidéo qui montre le résultat en oscillo et en image sur la TV :

On regarde la sortie du premier monostable Q7, puis la sortie du second monostable Q9.

Qu'en est-il concernant le trou dans H−Sync, dont on parlait et qui posait problème pour permettre le décalage vertical de l'image (on se retrouvait avec deux trous dans C−Sync) ?

Voici en jaune le signal C−Sync d'entrée, le signal carré en sortie de la PLL en bleu, et la sortie H−Sync du monostable en vert, à divers niveau de zoom.

On constate que le signal H−Sync est continu à l'emplacement du trou, avec une fréquence correcte annoncée ! Super, la PLL continue le travail et comble le trou !
Mais au fur et à mesure qu'on se rapproche, on voit bien que les impulsions s'éloignent un peu trop les unes des autres, pour finir par découvrir à l'emplacement du trou, que la fréquence est tombée à 13 kHz.
De plus si on regarde ce que donne l'image sur la télé, on se retrouve avec le haut de l'image déformée. Problème que j'ai pu corriger efficacement en choisissant correctement les valeurs des composants du filtre RC qu'il est conseillé d'utiliser sur la pin 13 du CD4046 :

Pourtant j'aurais préféré pouvoir avoir une fréquence correcte durant le « trou », et j'ai bien tenté d'optimiser les valeurs des résistances et condensateurs R1, R2, C1 et du filtre RC mais sans parvenir à une image exploitable.

Un autre problème que j'ai rencontré, c'est la présence d'un vilain artefact en plein milieu de l'image dont je n'ai su comprendre la provenance. Je ne sais plus comment j'en suis venu à cette solution, mais en filtrant l'alimentation du CD4046 dédié au traitement vertical, celui-ci a été éliminé ! Enfin pas complètement, si on y regarde bien, on voit une très légère vague au même endroit. Jugez plutôt, avant/après :

Finalement les signaux H−Sync et V−Sync sont combinés par des portes logiques afin de reconstituer un signal de synchro exploitable.

C'est le travail des portes logiques NAND (74LS132). En entrée 2 c'est H−Sync (en jaune), en entrée 1 V−Sync (en vert) et en sortie 6 le nouveau C−Sync ainsi recrée et prêt à alimenter la TV :

Et une vidéo en action pour comparer le signal C−Sync d'entrée du circuit, avec celui de sortie :

Conclusion des essais sur ce deuxième circuit :

On fait cette fois plus de choses avec ce circuit, et à un composant près on a le même nombre de puces que sur le circuit commercial de référence. On n'est peut-être pas si loin d'avoir deviné son fonctionnement.
L'image est correcte, mais les puristes qui iront coller leurs nez sur l'écran verront qu'il subsiste de la gigue, des vaguelettes dans les traits blanc :

Cependant quelques problèmes persistent, et je n'ai pas essayé, mais j'ai lu que le CD4046 serait plus stable en l'alimentant en 12 Volts. Peut-être même que ça corrigerait les défauts évoqués…

Bref, je pense qu'on est parti pour une troisième version de circuit à étudier prochainement.

À suivre…

Ressources :
https://www.ti.com/lit/an/scha002a/scha002a.pdf?ts=1761285252606
https://sitelec.org/download_page.php?filename=cours/pll2.pdf
https://www.eleccircuit.com/cd4046-datasheet-phase-locked-loop/

IQS−PGM - Labels pour cartouche de jeu DIY

makoto — Wed, 10 Sep 2025 19:32:00 +0200

Suite de l'aventure précédente :
Parlons étiquettes !

Quelques personnes ont réalisés des scans et partagés des créations originales d'étiquettes sur les forums que j'ai visité pour construire tout ça.
Il y a des étiquettes à coller sur les EEPROMS et des étiquettes de tranche de cartouche pour identifier les jeux.

J'ai rassemblé toutes celles qui me plaisaient bien pour en faire une planche A4 (en annexe à ce billet), imprimée sur un papier spécial étiquette.

L'encre est censée résister aux rayures sur ce papier, mais j'ai pu constater sur les petites étiquettes que ce n'était pas si évident. J'ai donc apposé un film transparent autocollant sur les étiquettes de tranche afin de les protéger. Quant aux petites, il était trop tard pour cela.

J'en ai aussi imprimé sur papier standard pour évaluation, en les disposants ainsi sans collage, car je ne parviens pas à me décider ^^;

Je vous laisse avec une galerie de photo des cartouches, qui montre un peu comment elles sont construites.

ESPGaluda :

Dodonpachi Dai-ou-jou :

Ketsui :

RecalStick -1-

makoto — Tue, 09 Sep 2025 13:59:00 +0200

Aujourd'hui on va fabriquer un RecalStick !… Un stick avec RecalBox dedans.
Je dispose en effet d'un écran cathodique qui ne demande qu'à afficher de belles images, et d'un Raspberry Pi 4 sur lequel j'ai enfin testé la distribution Recalbox, boite à émulateurs permettant d'exécuter des jeux vidéos d’antan, et je voulais une solution pour faire fonctionner ça joliment.

L'émulation sur ce genre de plate-forme étant enfin à peu prés potable, par la puissance maintenant correcte du Rpi – le 4 c'est bien, le 5 je pense qu'on ne fera pas mieux – pour émuler des jeux d'Arcade, et le rendu graphique excellent notamment grâce au module VGA666 compatible avec Recalbox.

On le trouve pour moins de 5€, il suffit de l'enficher sur le Rpi, d'y connecter un câble VGA,

alors on pourra brancher ça sur la vieille télé en intercalant un adaptateur VGA vers Péritel câblé comme ceci :

      Prise VGA                —        Prise Péritel

Pin N°1: Vidéo Rouge           —     Pin N°15: Rouge
Pin N°2: Vidéo Vert            —     Pin N°11: Vert
Pin N°3: Vidéo Bleu            —     Pin N°7:  Bleu
Pin N°6: Retour rouge          —     Pin N°13: Masse Rouge
Pin N°7: Retour vert           —     Pin N°9:  Masse Verte
Pin N°8: Retour bleu           —     Pin N°5:  Masse Bleue
Pin N°9: +5 V                  —     Pin N°8:  SWITCH
Pin N°10: Masse                —     Pin N°17: Masse Synchro
Pin N°13: HSync et N°14: VSync —     Pin N°20: Synchro.

Ajouter une résistance de 75 Ohms entre la Pin 8 et 16 de la prise péritel, permet, grâce au 5V en provenance de la carte vidéo, de basculer le TV en RVB sur l'entrée AV.

Ok, donc on a le micro-ordinateur pour faire tourner des jeux branchés à la TV, il manque la manette et une boite pour l'ordinateur.
Et bien on va combiner les deux pour donc fabriquer (encore !) une sorte de TV Game.

Les plans :

Disponibles en annexe à ce billet, j'ai dessiné le modèle 3D en fonction de plusieurs facteurs importants :
– Je souhaitais que le stick arcade ressemble au Hori Real Arcade Pro VX
– Qu'on puisse l'utiliser posé sur ses genoux
– Qu'il intègre donc le Rpi4
– Qu'on puisse brancher directement les câbles VGA, audio, et alimentation sur le boîtier du stick
– Et aussi un HDMI, comme ça on ne se limite pas aux écrans cathodiques
– Que l'on puisse brancher le câble USB du stick sur évidement le Rpi, mais aussi sur un autre ordinateur
– Qu'on puisse brancher jusqu'à trois autres manettes sur le Rpi Recalbox
– Qu'un bouton permette de basculer le joystick d'un quart de tour pour permettre de jouer aux jeux verticaux à l'horizontale dans le cas où l'on ne peux pas basculer l'écran d'un quart de tour.

Nous avons donc de gauche à droite, sur la façade arrière, l'emplacement du bouton de bascule ¼ de tour, la prise HDMI, la lamelle métallique VGA (qui intégrera la prise audio et la prise alimentation jack), et l'emplacement du Rpi qui laisse l'accès aux 4 prises USB. Il manque pour le moment le trou pour faire sortir le câble USB du circuit manette.

Le matériel :

Cette fois je n'ai pas investi dans des fournitures arcade onéreuses Sanwa ou Seimitsu, car l'usage en sera occasionnel.

– J'ai opté pour le célèbre Zippy et des boutons « no-name »
– On dispose aussi d'un câble de déport VGA (une mini-ralonge en somme)
– Un déport mini-HDMI vers HDMI qui intègre aussi un déport USB-C
– Une prise jack femelle audio stéréo
– Une prise jack femelle d'alimentation
– Un énorme dissipateur thermique ventilé qui enserre le Raspberry
– 4 bouts de bois de récupération, préparés à dimensions, constituant le cadre du boîtier
– Un circuit de manette USB qui vient avec ses câbles et ses cosses serties
Ce qui sera au final tellement plus pratique que de tout fabriquer comme je l'ai fait à l'époque

Des lattes de volets, un montant de porte, et une chute non-identifiée.

L'usinage de la façade arrière :

La pièce de bois étant très épaisse il est nécessaire de retirer une grande quantité de matière pour permettre la disposition correcte des différents connecteurs.

Pour le trou du bouton ¼ de tour j'ai utilisé des forêts à bois en perçant de diamètres différents de part et d'autre de la façade.
J'ai procédé à la défonceuse pour le reste, en retirant suffisamment de matière pour ne laisser que 10 mm de profondeur.

On travaille toujours de gauche à droite avec cet outil qui fait tourner très vite la fraise dans le sens horaire, donc « en avalant » le bois, afin d'éviter un recul brutal de l'outil, et donc l'accident.

Après plusieurs passes la gorge est terminée, on peut donc percer les ouvertures pour la lamelle et le Raspberry :

Parce que l'épaisseur du bois reste problématique pour le branchement de la prise VGA et autres USB, pour l'esthétique aussi, on taille les bords au ciseaux à bois.

Le collage du cadre :

Il était évidemment nécessaire de s'occuper de ces usinages avant l'assemblage, sans clous, ni vis, ni gougeons, à la colle vinylique.

Et pendant que la colle sèche, j'ai découpé la plaque du dessus – le panel – dans du contre-plaqué de 10 mm d'épaisseur.

La taille des coins :

Une scie à onglet facilite beaucoup ce travail !

Cela fait partie des nouveaux outils – avec la défonceuse – bien appréciés.

Et hop ! Terminé.

Fixation du panel et du fond :

Pour positionner le panel en hauteur, bien à fleur du cadre, on va le faire reposer sur des coins (courts morceaux de tasseau) collés à l'intérieur du cadre à bonne profondeur, en pressant le tout contre la table. (La face interne du panel est peinte en vert car provenant d'une chute de contre-plaqué).

Pour éviter que des bavures de colles n'aillent coller le panel aux coins, on peut mettre du ruban de masquage sur le sommet du coin. Une fois le collage sec, on peut donc en principe retirer le panel – et le ruban – sans difficultés.
Le panel sera plus tard solidarisé au cadre, à l'aide de vis passées depuis l'intérieur du boîtier.

Le fond sera quand à lui constitué d'un panneau d'isorel, ce « bois » qu'on retrouve au fond des placards ».

Une feuillure de +/- 4 mm de profondeur est donc pratiquée à la défonceuse dans le cadre pour accueillir le fond que je découperais plus tard.

La taille de la face avant :

Nous arrivons à la phase la plus délicate.
Toute cette matière – représentée en hachuré – doit disparaître, sur toute la longueur.
Je me propose à faire ça à la ponceuse à bande, en procédant de la même manière que la dernière fois (voir la vidéo du billet « linké »)

On fixe l'ouvrage solidement à la table, et on procède par passes successives, patiemment, tranquillement, prudemment…

Voilà, c'est fait, pas parfait, mais ce n'était que la première phase. On retourne la pièce pour s'occuper de l'autre angle :

Et c'est reparti…

Ensuite ça se termine à la lime et au ponçage pour rattraper les creux et bosses indésirables, souvent causées par la nature du bois plus ou moins dure aux abords des nœuds par exemple :

Le perçage des trous :

Ahhh, enfin la phase la plus amusante (j'adore la perceuse à colonne !)

L'ouvrage ressemble enfin au modèle, il reste à percer les trous pour les fournitures Arcade, à l'emplacement voulu après quelques mises en situations pour évaluer l'ergonomie de la chose.

J'ai procédé avec les forêts plats habituels de 24 et 30 mm, mais cette fois-ci, au préalable avec une fraise de 35 mm pour évider le dos du panel sur environ 6 mm de profondeur.

En effet, le contre-plaqué fait 10 mm d'épaisseur et je dispose de boutons à clipser – et non-plus à visser – qui nécessitent un maximum de 4 mm de rebord pour tenir correctement en place.

J'aurais aussi pu procéder à cet évidement à la défonceuse.
J'aurais pu juste percer normalement à 24 et 30 mm et coincer les boutons en place.

La fixation du stick :

Vous aurez peut-être compris que je ne souhaite pas avoir de vis apparentes sur cet ouvrage. Il n'est donc pas question de percer le panel des 4 trous nécessaires à la fixation du stick Zippy.
L'épaisseur du panel aurait pu permettre de visser le stick depuis l'intérieur, sauf que malheureusement la tige était un peu courte et ne dépassait pas suffisamment du panel, m'obligeant alors à pratiquer une défonce de 4 mm pour voir la tige dépasser de 22 mm. Aucune vis à bois – aussi courte soit-elle – n'aurait alors suffisament d'emprise pour tenir cette mécanique en place.

J'ai donc rusé en bricolant deux plaquettes de contre-plaqué, et quelques morceaux de cartons pour bien caller le stick en place, et utiliser des vis à bois comme prévu initialement, mais ainsi déportées dans une zone où l'on dispose de l'épaisseur complète du panel pour les visser.

L'installation des fournitures :

Une petite vidéo

L'installation des boutons se fait aisément en cliquant comme il faut. Le câblage du circuit USB est facile et rapide à faire !

Petit problème avec le Raspberry… Il ne peut pas rentrer à sa place, autrement qu'en diagonale, sinon il bute dans le stick Zippy. À 5 mm prés j'ai bien « merdé » le truc…

À priori il passe si je le décale un peu plus sur le côté, donc je vais devoir élargir l'ouverture sur la face arrière et reboucher l'erreur.

Voici l'ensemble Rpi avec le VGA666 sur-lequel est connecté la lamelle VGA percée de trous de 7 mm pour y visser les connecteurs audio et alimentation. Et une vue de la face arrière avec quelques connecteurs :

En attendant la suite…

Il reste donc à faire rentrer tout ça (sauf l'alimentation !) dans le boîtier :

À suivre…

Décapotes -01-, circuit de positionnement d'image pour écran TV

makoto — Wed, 03 Sep 2025 18:51:00 +0200

J'évoquais dans le premier billet de la série IGS−PGM le petit soucis que provoquait l'utilisation de cette machine sur un écran de téléviseur plutôt que sur un écran d'arcade.

L'image est trop à gauche, et présente une bande verticale noire sur la droite de l'écran, et ce malgré le maximum des possibilités de réglages du TV.

Et effectivement en recherchant sur le sujet, on fini par trouver de l'info fiable et des produits proposants des solutions au problème, par exemple avec cette Carte de positionnement image pour écran tv.
Il y a une vidéo de démo bienvenue où tout est bien expliqué :

Mais comment ça marche !??

On trouve des photos et analyses d'objets de ce type chez retrorgb, pour constater que les références de composants sont caviardées pour rendre impossible leur identification… Pratique qui m'agace toujours très fortement.
Et si on recherche sur des sites marchands asiatiques, même constat… Quel est donc ce secret qu'on s'acharne à si bien garder ??

Étudions la chose…
Une fois trouvé le bon mot clef, rgb shifter, on commence à tomber sur des choses intéressantes, comme sur ce site présentant un montage censé permettre de décaler l'image horizontalement : https://playoffline.wordpress.com/cable/rgbshifter/
Et concomitamment, un forum où les membres s'organisent pour réaliser le montage, ici non plus via le standard Jamma, mais en Péritel : https://circuit-board.de/forum/index.php/Thread/15207-RGB-Shifter/

En étudiant ces circuits on fini par comprendre que le concept de ce type de montage est relativement simple.

Il consiste à déphaser le signal de synchronisation horizontal.

Imaginons qu'on ait une image bien cadrée sur l'écran,
Théoriquement un déphasage de π du signal de synchro déplacerait l'image vers la droite sur une moitié de l'écran, c'est à dire qu'on aurait une moitié gauche noire et la moitié droite avec l'image.
Un déphasage de 2π, reviendrait enfin à replacer l'image au complet dans le cadre, puisqu'elle aurait fait le tour de l'écran, l'image réapparaissant par la gauche du cadre.

L'occasion de consulter quelques ressources sur le signal vidéo :
− http://f5ad.free.fr/ATV-QSP_F5AD_Le_signal_video.htm
− http://tvandco.free.fr/tpe-tvandco/4/4-signal-synchronisation.html
− https://www.nutsvolts.com/magazine/article/video_basics
− https://www.analog.com/en/resources/technical-articles/understanding-analog-video-signals.html
− https://www.retrogamingcables.co.uk/composite-video-vs-composite-sync

Pour résumer, il y a deux cas de figures qui vont nous intéresser :

− La vidéo contenue dans un seul câble (les couleurs + les deux synchro, tout mélangées), qu'on appelle le Composite.
− La vidéo contenue dans trois câbles (rouge, vert, bleu) et un câble de synchro (horizontal + vertical mélangé), donc qu'on nomme communément le RGB, mais devrait-on préciser, le RGB + C−Sync.

C−Sync désignant le mélange de H−Sync et V−Sync, respectivement signal de synchronisation horizontal et vertical.

En effet, le système IGS−PGM fonctionne en RGB + C−Sync, ainsi que quasiment toutes les consoles 8 et 16 bits sorties en Europe : snes, master system, megadrive, pc engine (sodipeng). Et aussi la gamecube et le PC d'émulation Mame. Certaines machines fonctionnent aussi en Composite, c'est le cas pour : snes, gamecube, pc engine (en NTSC).

J'ai donc réalisé un premier circuit pour expérimenter et comprendre la chose.
Nous allons l'analyser et décrire son fonctionnement.
J'ai ensuite eu d'autres ambitions, que je détaillerais dans cette série d'articles.
L'idée étant de concevoir mon propre circuit de décalage de l'image − le Décapotes − pour aller sur ma Péritel multiple où j'ai prévu un emplacement pour une carte fille de traitement du signal. Ce qui permettra donc de recaler non seulement le système IGS-PGM (qui à la base motive tout ça), mais aussi toutes les consoles qui passeront par ce bloc multi−péritel.

Un premier circuit d'essais :

Je me suis donc basé le rgbshifter dont je parlais plus haut, et l'ai modifié dans l'intention de pouvoir décaler l'image horizontalement, mais aussi verticalement.

Principe de fonctionnement :

− Le signal de synchro C−Sync provenant de l'IGS−PGM entre dans l'étage séparation des signaux basé sur un LM1881.
− Puis deux monostables U18A et U18B vont traiter C−Sync en sortie du LM1881 afin de le déphaser, ce qui décalera l'image horizontalement par rapport au cadre de l'écran de TV.
− Deux autres monostables U17A et U17B vont traiter V−Sync en sortie du LM1881, ce qui décalera l'image verticalement.
− Enfin, deux portes NAND sont chargées de ré−assembler les deux signaux afin de recréer le C−Sync qui sera envoyé à la péritel.

Quel est le rôle du LM1881 ?

C'est un circuit spécialisé dans la séparation de signaux de synchronisation TV.
En principe on lui applique un signal vidéo Composite en entrée, qui je le rappelle contient toute l'image, les couleurs et les synchro, et il nous sort plusieurs signaux, dont les C−Sync et V−Sync qui nous intéressent.
Étant donné qu'on travaille ici en RGB + C−Sync, son seul intérêt et de nous fournir V−Sync.
Autrement dit, nous pourrions simplifier le circuit à ceci, dans le cas où l'on voudrait juste recaler l'image horizontalement, et le problème serait réglé pour l'IGS−PGM !!

Mais ce ne serait pas amusant, et assez limité, nous allons voir pourquoi…

Voici donc deux oscillogrammes, en jaune LM1881 pin1 (C−Sync) et en bleu LM1881 pin3 (V−Sync), puis zoomés sur la partie intéressante :

Nous voyons donc un signal C−Sync classique, avec ses nombreux et très courts tops de synchro horizontaux à l'état bas, ainsi que le large trou laissé par le top de synchro vertical.
En bleu le signal de synchro vertical crée par le LM1881. On note qu'il ne mesure pas exactement la largeur du trou, car ce composant recrée un signal respectant la norme vidéo, tout en se « clockant » (synchronisation temporelle) bien sur le moment de cette impulsion.

Zoomons encore, avec quelques mesures :

− Le premier oscillogramme montre C−Sync, zoomé sur quelques impulsions horizontales, période 64 µs, fréquence 15,625 kHz et durée durées d'impulsions à 5,3 µs.
− Le second oscillogramme montre V−Sync, zoomé sur quelques impulsions verticales, période 16,90 ms, fréquence 59,19Hz et avec mesure des durées d'impulsions à 460 µs.

Intéressons nous maintenant au fonctionnement des monostables.

Je vous invite à consulter l'excellent site Sonelec-musique pour de plus amples détails.
C'est un circuit qu'on a déjà utilisé pour le circuit de protection précédemment réalisé, le principe d'usage est similaire, à la différence qu'on ne cherche pas ici à détecter la présence d'un signal.

− Avec le premier monostable, on va générer (grâce aux résistances et condensateurs calculés par la formule donnée dans la datasheet du constructeur) une impulsion A qui va avoir lieu (se déclencher) sur le front montant des impulsions appliquées en entrée du monostable.
La largeur de cette l'impulsion est réglée par le premier potentiomètre. Plus c'est large, plus on éloigne son front montant par rapport à la position du front montant de l'impulsion d'entrée.
− Puis avec le second monostable, on viens générer une nouvelle impulsion B, qui va se déclencher sur le front montant de l'impulsion A, et dont on va fixer la largeur (une fois pour toute, et on n'y touche plus) avec le second potentiomètre (5 kΩ), afin d'obtenir une durée de ±5 µs. (la norme vidéo d'un top de synchro horizontal, à peu prés).

Sync originale, en entrée
____    __________________    ___________________    ________________
    |  |                  |  |                   |  |
    |  ^                  |  ^                   |  ^
    |__|                  |__|                   |__|

1er monostable, impulsion A
_______         _____________         ______________         ________
       |       |             |       |              |       |
       |       ^             |       ^              |       ^
       |_______|             |_______|              |_______| 

2nd monostable, impulsion B identique à l'originale, mais décalée !
_______________    __________________    ___________________    _____
               |  |                  |  |                   |  |
               |  |                  |  |                   |  |
               |__|                  |__|                   |__|

En pratique voici les relevés sur oscillogramme, avec en jaune la synchro horizontale, en bleu l'impulsion du monostable A en sortie Q7, et en vert l'impulsion du monostable B en sortie Q9 du CD4538. Montrés ici à 4 positions du potentiomètre, du minimum, au maximum :

Et voilà, on a notre nouveau signal de synchro déphasé par rapport à celui qu'on a entré dans le montage, réglé par le potentiomètre du monostable A. En jouant avec celui-ci on décale donc l'image du jeu vidéo… Démonstration en vidéo :

Conclusion des essais sur ce premier circuit :

On parvient à déplacer l'impulsion horizontale ou verticale mais l'image n'est pas très stable, ce qui est sans doute dû en grande partie à la qualité des potentiomètres utilisés.
En effet les potars sont « lu » à très haute vitesse et en permanence par le circuit, ce qui induit fatalement de la gigue (jitter).
J'ai noté aussi que la plage d'action en vertical est très limitée, ne permettant de décaler l'image que de quelques pixels, alors que la vidéo de smallcab montre bien une large plage d'action dans les deux sens.

Ces deux raisons impliquent que son circuit doit fonctionner différemment.

J'ai compris plus tard pourquoi ce circuit ne fonctionnait pas en vertical :

Focalisé sur la trace du signal vertical en sortie Q9 du monostable, j'avais en fait oublié de regarder l'oscillogramme de la sortie du signal réassemblé derrière les portes NAND (pin6 du 74LS132), c'est à dire le nouveau C−Sync. Et là tout s'explique !

Si on ne décale pas l'image, ça donne le C−Sync qu'on a l'habitude de voir, mais dés qu'on veut décaler l'image en jouant du potentiomètre, on se retrouve avec deux impulsions verticales, sur toute la plage d'opération !
En jaune C−Sync in et en bleu C−Sync out :

Si la seconde impulsiont V−Sync est proche de l'originale, on parvient à décaler un peu, mais dés qu'on s'éloigne plus, la TV perd les pédales !

Tout est parfaitement logique ! C−Sync contient certes V−Sync, mais laisse un trou à l'emplacement de H−Sync, et celui-ci reste donc en place lorsqu'on reconstruit le signal.
Ce qui invalide de fait la conformité de ce circuit.
Nous aurions besoin d'un V−Sync continu, sans ce trou donc…

Loin d'être du temps perdu, ces informations vont nous servir pour la suite…

PS : Je n'en parle que maintenant, mais autant clore le sujet tout de suite. Parmi mes ambitions, il y avait la possibilité d'étirer l'image (rezise, la géométrie) en plus de pouvoir la déplacer, mais c'est malheureusement chose impossible avec une image en RGB + C−Sync. En effet les signaux sont séparés en cinq donc, et si on modifie les fréquences de H−Sync et V−Sync on perd l'image…
Ce serait à priori possible en Composite, en changeant la fréquence du signal horizontal pour tourner autour de 15khz, en l'augmentant pour réduire la largeur de l'image, et en diminuant la fréquence on augmente la largeur de l'image. Idem pour la verticale, tourner autour de 60Hz.
Je n'ai pas étudié la chose et ne connais donc pas le mode opératoire. Je n'aborderais − à regret − pas ce sujet ici, sinon j'aurais nommé le circuit « Géopote » !

À Suivre…

IGS−PGM - Cartouche de jeu DIY N°3

makoto — Sun, 24 Aug 2025 21:05:00 +0200

Suite de l'aventure précédente :

On termine le travail, ici avec le jeu Ketsui.

Fluffy a prévu la possibilité de pouvoir jouer aussi au « mode arrange » (à priori un mode de jeu non officiel bricolé par un bidouilleur).

On utilisera un petit interrupteur branché sur le cavalier « JP2 » pour l'activer, suivit d'un reset du système IGS−PGM.

Il faut à nouveau souder 2 cartes ! Pas de photos à exposer, c'est la même chose que montré dans le billet précédent…

La programmation :

1 − Extraire les binaires pour les EEPROM 27c322 :
Télécharger sur le net la rom mame avec la mention « BL », ici : ketbl.zip
À priori celle-ci devrait peser 22,1 Mio (23240460 octets)

À l'aide du script python rom_gen.py qu'on aura pris soins d'extraire préalablement, exécuter :

python3 rom_gen.py ketbl.zip

Qui va générer le dossier « ketsui_rg » contenant les binaires à flasher sur les puces. (le dossier « bios_rg » n'est pas utile)

Exécuter ensuite :

python3 rom_gen.py -b pgm_bios_single_pcb_vxxxJP.u42 PGM\ Program\ Files.zip

Qui va générer dans le dossier « ketsui_rg » le fichier « ketsui_p1_trap.bin ».
Utiliser le fichier « ketsui_p1_trap.bin » à la place du fichier « ketsui_p1.bin » précédemment généré par la rom, permet d'utiliser le cavalier « JP2 » pour activer le « mode arrange ».

2 − Programmer les EEPROM 27c322 :
Se référer au billet précédent pour plus de détails sur la procédure de programmation et obtenir l'archive de scripts.

3 − Placer les EEPROM 27c322 sur les PCB :
Se référer pour cela aux sérigraphies, et faire attention au sens d'orientation des puces !

4 − Programmer la GAL : ATF16V8B qui va en position U6 :
Écrire le fichier PGM-RG-U6.jed.

5 − Programmer la GAL : ATF16V8B qui va en position U5 :
Écrire le fichier PGM_RG_U5_ESP.jed. Oui c'est le même fichier que ESPgaluda pour Ketsui.

NB : JP2 permet de sélectionner la ROM normale ou la rom Arrange 1.7 : Sans cavalier > Jeu original et Avec cavalier > mode Arrange.

Mise en cartouche et tests :

Pour que ce soit donc plus pratique, j'ai collé un micro-switch à l'intérieur de la cartouche, relié aux « pins headers » de JP2. On peut le basculer de l'extérieur, alors que la cartouche est insérée dans le système de jeu, à l'aide d'un truc fin comme un cure-dents.

Dans la vidéo, d'abord le mode normal, puis j'ai basculé le micro-switch avant de faire le reset pour redémarrer le système et montrer le « mode arrange » :

À suivre…

IGS−PGM - Cartouche de jeu DIY N°2

makoto — Sun, 03 Aug 2025 18:29:00 +0200

Suite de l'aventure précédente :

On reprend le travail, ici avec le jeu Dodonpachi Dai-ou-jou, appelé aussi Dodonpachi 3.

Ce jeu a la particularité, comme d'autre jeux édités par CAVE d'exister en deux versions. L'habitude chez cet éditeur c'est qu'à la sortie d'un jeu, il s'appelle simplement par son nom, et quelques temps plus tard il peut arriver que le jeu ressorte en version « Black Label ». Celle-ci venant améliorer le gameplay et en revoir la difficulté par exemple. La version du jeu précédente est alors re-nommée « White Label ».

Nous allons construire la version du jeu qui contient la White et la Black label, nommés simplement « Version-A (Old) » et « Version-B (New) » depuis le tableau d'accueil proposé dans la rom spécifique.

Mais d'abord, il faut souder les 2 cartes ! Cette fois-ci j'ai quelques photos…

La carte program:

La carte character :

La programmation :

1 − Extraire les binaires pour les EEPROM 27c322 :
Télécharger sur le net la rom mame avec la mention « BL », ici : ddpdojblkbl.zip
À priori celle-ci devrait peser 19,3 Mio (20323962 octets)

À l'aide du script python rom_gen.py qu'on aura pris soins d'extraire préalablement, exécuter :

python3 rom_gen.py ddpdojblkbl.zip

Qui va générer le dossier « ddp3_rg » contenant les binaires à flasher sur les puces. (le dossier « bios_rg » n'est pas utile)

Exécuter ensuite :

python3 rom_gen.py -b pgm_bios_single_pcb_vxxxJP.u42 PGM\ Program\ Files.zip

Qui va générer dans le dossier « ddp3_rg » les fichiers « ddp3_p1_bl_qb.bin » et « ddp3_p1_dual_qb.bin ».
Utiliser le fichier « ddp3_p1_dual_qb.bin » à la place du fichier « ddp3_p1_amb.bin » précédemment généré par la rom, permet d'obtenir le tableau de choix de la version (old = White, new = Black).
Pour info, le jeu démarre directement sur ce tableau après avoir brièvement affiché la date du jour.

2 − Programmer les EEPROM 27c322 :
Se référer au billet précédent pour plus de détails sur la procédure de programmation et obtenir l'archive de scripts.

3 − Placer les EEPROM 27c322 sur les PCB :
Se référer pour cela aux sérigraphies, et faire attention au sens d'orientation des puces !

4 − Programmer la GAL : ATF16V8B qui va en position U6 :
Écrire le fichier PGM-RG-U6.jed.

5 − Programmer la GAL : ATF16V8B qui va en position U5 :
Écrire le fichier PGM_RG_U5_QB.jed.

NB : Dans le cas de ce jeu, les jumpers ne servent à rien.

Mise en cartouche et tests :

Le jeu fonctionne, mais j'ai parfois rencontré des problèmes d'erreurs CRC après avoir sélectionné la version White du jeu.
Si on laisse dérouler la démo, le jeu plante. Mais si on met un crédit, le jeu fonctionne. En cas de Game Over, le jeu plante.

Comme montré dans cette vidéo :

Lorsqu'on sélectionne la version Black, aucun problème.
Comportement erratique dont on peut fort bien s'accommoder, ou bien prendre la solution apportée sur le forum, en utilisant un binaire de remplacement, proposé par IQ 132 sur cette page, et disponible en annexe à ce billet.

− Il faut donc effacer la puce 27c233 qu'on avait en P1 et écrire dessus le fichier « ddp_j.bin » contenu dans l'archive.
− Il faut aussi effacer la puce ATF16V8B située en U5 et lui écrire le fichier « PGM_RG_U5_DDP.jed » disponible depuis l’archive principale.

Cette fois le jeu démarre en montrant le bios du slot IGS-PGM, puis ensuite tout fonctionne parfaitement.

À suivre…

Piloter un ventilateur pour Odroid-C2

makoto — Sat, 19 Jul 2025 14:17:00 +0200

Le µ-ordinateur Odroid-C2 vient avec un bon dissipateur thermique, mais sans ventilateur.
Il a tendance à fleurter avec les 50°C, surtout par temps caniculaire et d'autant plus s'il est disposé dans un boîtier, ce qui m'a amené à vouloir lui adjoindre un ventilo.

Les vendeurs de boîtiers (le design de l'Odoid-C2 est compatible avec les boîtiers Raspberry-pi 2 et 3) avec ventilateur ont tendance à y mettre un ventilo de 30 mm assez faiblard, quand ce n'est pas simplement un ventilo 12V qui sera donc alimenté en 5V par l'appareil, réduisant sa vitesse de rotation.
L'avantage indéniable c'est qu'il ne fait alors pas trop de bruit.

En choisissant comme je l'ai fait un ventilateur 5V, je ne m'attendais pour autant pas à autant d'efficacité pour autant de bruit très gênant.

Nous allons donc voir comment réguler ça.

Au démarrage de l'appareil, avec 26°C de température ambiante, nous avons 36°C pour le CPU ''ARMv'8'. Nous garderons cette température en référence à atteindre.

Au bout de quelques minutes sans rien demander à la machine nous sommes déjà à 42°C. La faire travailler montera encore indéniablement la température.

L'électronique :

Un simple transistor sera utilisé pour interfacer le ventilateur à une pin GPIO de l'appareil.
Elle sera en charge de piloter le transistor avec une PWM logicielle. (oui, impossible de faire fonctionner la PWM matérielle, nous y reviendrons plus loin).

Notez qu'en principe il aurait fallu ajouter une diode de roue-libre aux bornes du ventilateur.

Nous avons donc un simple ventilateur à deux broches, et un transistor costaud bien que sur-dimensionné IRLZ44N (un IRL540N fonctionne aussi). J'ai fait avec ce que j'avais sous la main.

C'est ici un transistor CMOS, mais ça fonctionnera aussi bien avec un classique NPN, cependant il faut vérifier sur la datasheet la valeur max du courant iD (Drain Current) ou iC (Collector Current) qu'il est capable d'encaisser.
Un classique BC547 qui encaisse 100 mA serait insuffisant car le ventilateur consomme 120 mA.
Je m'étais alors orienté vers un BS170 qui prend allégrement 500 mA, sauf que !
Il est utile de rappeler que la logique GPIO fonctionne en 0-3,3V, et qu'il faut alors que le transistor soit capable de saturer complètement à 3,3V.
Nous pouvons consulter la valeur de VGS(th) (Gate threshold voltage), et pour le BS170 c'est entre 0,8V et 3,0V, et c'est donc bien au delà de cette dernière valeur qu'il va conduire pleinement.
Expérimentation à l'appui, ce n'est en effet pas suffisant, certes ça déclenche, mais le ventilo ne tourne pas à fond.
Alors qu'avec l'IRLZ44 qui à son VGS(th) à 2V, aucun problème, ça ventile à pleine vitesse.

La PWM sur GPIO :

Je ne vais pas expliquer ici ce que c'est, mais comment en générer une, en 2025 sur un Odroid-C2, matériel qui n'est plus supporté par le fabriquant Hardkernel.

En effet plus aucun système d'exploitation n'est disponible officiellement, et ce n'est que grâce à la communauté DietPi qu'il est possible d'avoir un OS à jour avec des possibilités très intéressantes permettant de faire revivre ce µ-ordinateur… Formidable !

Oubliez tout ce que vous aviez appris à l'époque par contre, j'y ai passé 3h pour comprendre que les librairies permettant de piloter les GPIO sur un OS récent, telles que WiringPi ou RPi.GPIO sont dépréciées, cassées et inutilisables. Ça m'apprendra à ne plus retourner en premier lieu sur mes notes et à interroger l'état de l'art à l'instant présent.

La solution que j'ai pour l'heure adoptée est l'utilisation de la librairie libgpiod, qui donne entière satisfaction en langage C. Cependant je n'ai pas réussi à faire fonctionner son pendant en Python gpiod.

Mais elle ne permet malheureusement pas d'exploiter les deux broches PWM matérielles embarquées dans l'Odroid-C2, tant pis, nous allons en créer une logicielle.

Pour l'installation de la librairie, c'est très facile :

sudo apt install libgpiod-dev g++ gcc

Ensuite j'ai demandé à un outil moderne, Le Chat de me générer le code via ce prompt :

un code en C qui fait varier la vitesse de la pwm en fonction de la température du CPU

Un code qui fonctionne (presque) directement, et sans erreur ! Incroyable… (ci-après)
(Par contre oubliez ChatGPT, son code ne fonctionne jamais… on préférera des outils plus spécialisés en la matière qu'une LLM généraliste.)

Il faut donc tout de même spécifier la broche sur laquelle est connectée notre transistor, et aussi sur quel contrôleur « gpiochip ».

#define GPIO_CHIP "gpiochip???"
#define GPIO_PIN ???

On trouve des explications très utiles et claires sur le blog de Christophe Blaess, à propos de la manière de déterminer ces deux éléments cruciaux.

En effet la commande :

sudo gpioinfo

Nous retourne un tas d'information, dont :

[…]
gpiochip1 - 119 lines:
[…]
	line  98: "J2 Header Pin33" unused output active-high 
[…]

Que nous pouvons corréler à l'implantation du connecteur J2 de l'Odroid-C2 :
C'est donc le chip 1 qui adresse le connecteur J2 qu'on doit utiliser, et le nombre 98 qu'on doit indiquer, correspondant à la pin33.

Notez bien que j'utilise la pin33, qui correspond à la PWM matérielle, qui ne sera pas usitée en tant que telle (cf. plus haut), et que j'aurais pu utiliser une autre pin, puisque la PWM est générée logiciellement, par le code C ci-après.

On peut maintenant créer le fichier ventilateur.c qui contiendra le programme :

sudo nano /root/ventilateur.c

Et y copier le code C suivant :

#include <stdio.h>
#include <stdlib.h>
#include <gpiod.h>
#include <unistd.h>
#include <time.h>

#define TEMPERATURE_FILE "/sys/class/thermal/thermal_zone0/temp"
#define GPIO_CHIP "gpiochip1"
#define GPIO_PIN 98

void simulate_pwm(struct gpiod_chip *chip, int pin, int duty_cycle) {
    struct gpiod_line *line;
    struct timespec sleep_time_on, sleep_time_off;
    int ret;

    line = gpiod_chip_get_line(chip, pin);
    if (!line) {
        perror("Récupération de la ligne GPIO échouée");
        return;
    }

    ret = gpiod_line_request_output(line, "pwm_sim", 0);
    if (ret < 0) {
        perror("Configuration de la ligne GPIO en sortie échouée");
        gpiod_line_release(line);
        return;
    }

    sleep_time_on.tv_sec = 0;
    sleep_time_on.tv_nsec = (long)(duty_cycle * 1000000L);
    sleep_time_off.tv_sec = 0;
    sleep_time_off.tv_nsec = (long)((100 - duty_cycle) * 1000000L);

    for (int i = 0; i < 100; i++) {
        gpiod_line_set_value(line, 1);
        nanosleep(&sleep_time_on, NULL);
        gpiod_line_set_value(line, 0);
        nanosleep(&sleep_time_off, NULL);
    }

    gpiod_line_release(line);
}

int read_cpu_temperature() {
    FILE *temperature_file;
    int temperature;

    temperature_file = fopen(TEMPERATURE_FILE, "r");
    if (temperature_file == NULL) {
        perror("Erreur lors de l'ouverture du fichier de température");
        return -1;
    }

    if (fscanf(temperature_file, "%d", &temperature) != 1) {
        perror("Erreur lors de la lecture de la température");
        fclose(temperature_file);
        return -1;
    }

    fclose(temperature_file);
    return temperature;
}

int main(void) {
    struct gpiod_chip *chip;
    int temperature, duty_cycle;

    chip = gpiod_chip_open_by_name(GPIO_CHIP);
    if (!chip) {
        perror("Ouverture de la puce GPIO échouée");
        return EXIT_FAILURE;
    }

    while (1) {
        temperature = read_cpu_temperature();
        if (temperature == -1) {
            gpiod_chip_close(chip);
            return EXIT_FAILURE;
        }

        // Convertir la température en degrés Celsius
        float temperature_c = temperature / 1000.0;
        printf("Température du CPU : %.2f °C\n", temperature_c);

        // Calculer le cycle de travail en fonction de la température
        // Par exemple, augmenter le cycle de travail de 20% à 100% en fonction de la température
        duty_cycle = 20 + (int)((temperature_c / 80.0) * 80);
        if (duty_cycle > 100) {
            duty_cycle = 100;
        }

        printf("Cycle de travail PWM : %d%%\n", duty_cycle);
        simulate_pwm(chip, GPIO_PIN, duty_cycle);
    }

    gpiod_chip_close(chip);
    return EXIT_SUCCESS;
}

Pour compiler le code on entre cette commande :

sudo gcc -o /root/ventilateur /root/ventilateur.c -lgpiod

Et pour l'exécuter :

sudo /root/ventilateur

Ce qui au fil du temps renvoie ceci au terminal :

Température du CPU : 43.00 °C
Cycle de travail PWM : 63%
Température du CPU : 42.00 °C
Cycle de travail PWM : 62%
Température du CPU : 41.00 °C
Cycle de travail PWM : 61%
Température du CPU : 40.00 °C
Cycle de travail PWM : 60%
Température du CPU : 39.00 °C
Cycle de travail PWM : 59%
Température du CPU : 38.00 °C
Cycle de travail PWM : 58%
Température du CPU : 38.00 °C
Cycle de travail PWM : 58%
Température du CPU : 37.00 °C
Cycle de travail PWM : 57%
Température du CPU : 36.00 °C
Cycle de travail PWM : 56%
Température du CPU : 35.00 °C
Cycle de travail PWM : 55%
Température du CPU : 35.00 °C
Cycle de travail PWM : 55%
Température du CPU : 34.00 °C
Cycle de travail PWM : 54%
Température du CPU : 33.00 °C
Cycle de travail PWM : 53%

Automatisation :

Si tout à bien fonctionné à l'étape précédente, maintenant il s'agit d'exécuter le programme à chaque démarrage du DietPi, ce que nous allons faire en créant un service systemd :

Écrire le fichier suivant :

sudo nano /etc/systemd/system/ventilateur.service

Contenant ceci :

[Unit]
Description=Démarre le programme « ventilateur »

[Service]
ExecStart=/root/ventilateur
Restart=on-failure
User=root

[Install]
WantedBy=multi-user.target

Puis exécuter ces commandes pour respectivement recharger systemd, installer le service au démarrage, démarrer le service pour la session en cours, consulter l'état du service :

sudo systemctl daemon-reload
sudo systemctl enable ventilateur.service
sudo systemctl start ventilateur.service
sudo service ventilateur status

Voilà, à chaque démarrage du µ-ordinateur, le ventilateur se mettra en route et régulera sa vitesse en fonction de la température du processeur ARM.

Modifications utiles :

Si on souhaite baisser la vitesse du ventilo par rapport à la température, on peut modifier le code comme ceci :

Repérer la ligne :

duty_cycle = 20 + (int)((temperature_c / 80.0) * 80);

Qui donne ceci :

Température du CPU : 29.00 °C
Cycle de travail PWM : 49%

Et modifier les valeurs comme ceci :

duty_cycle = 20 + (int)((temperature_c / 100.0) * 60);

Ce qui donne alors :

Température du CPU : 29.00 °C
Cycle de travail PWM : 37%

Lumiplot, le système lumineux pour cône de roller slalom -4-

makoto — Fri, 21 Mar 2025 16:54:00 +0100

Suite des expérimentations précédentes :

On a eu de la casse !!

Il s'agit de la languette qui s'est brisée lors d'un choc.
Tout le reste va bien et fonctionne encore. À vrai dire je m'attendais à ce que ce type de pièce casse tôt ou tard…
Sauf que par un manque de recul, je n'avais pas prévu de pouvoir remplacer facilement cet élément. Je l'évoquais alors dans le billet N°2.

C'est maintenant chose faite, voici en effet la nouvelle version du boîtier imprimé 3D.

La partie concernée fait désormais partie du boîtier au complet, plus besoin de la coller.

J'ai donc ajouté un trou de vis supplémentaire afin de pouvoir remplacer la partie de la languette qui pourrait à nouveau casser.

J'ai pensé aussi que cette languette pourrait être imprimée à partir de filament flexible type TPU ou autre NinjaFlex, ce qui la rendrait alors indestructible. Mais pour le moment je ne dispose pas de ce type de plastique.

Le couvercle de la batterie dispose aussi d'une languette, et on pourrait vouloir aussi l'imprimer en flexible, mais je pense que c'est une mauvaise idée, car on veut vraiment protéger la batterie des chocs. Ainsi il vaut mieux mettre toutes les chances du côté de la rigidité pour cela.

À suivre…?

Je mène actuellement quelques essais pour rendre les Lumiplots télécommandables… Si c'est fiable les fonctionnalités lumineuses seraient décuplées sans limites. Ou pas.

Réparer la croix de direction des manettes Megadrive

makoto — Wed, 12 Mar 2025 19:02:00 +0100

Lors d'une session de jeu avec un ami nous avons rencontré un problème avec la croix de direction d'un pad Megadrive.
Impossible d'utiliser certaines diagonales, en l’occurrence, en haut-droit et bas-droite.

J'ai pensé, comme souvent c'est le cas, à des soucis de contacts comme déjà vu de manière générale, et c'est donc confiant, que j'ai procédé à cette l'opération de nettoyage et d'optimisation des contacts.

Et de découvrir une originalité que je ne connaissais pas en la matière !
En effet, les contacts s'effectuent à l'arrière de la manette, via une tige qui transfère les directions à un disque chargé d'appuyer sur les boutons placés au dos de la manette. La carte électronique est donc double face, première fois que j'en vois une pour une manette de cette l'époque.

Sur la dernière photo, j'oriente la croix côté face de la carte, pour voir au dos le disque appuyer sur les boutons de caoutchouc.

Une fois la manette remontée le problème était toujours bien présent…

Mais que se passe-t'il donc ??

Et puis, j'ai secoué la manette :

Hum… Ce n'est peut-être pas trop normal que la croix gigote autant non ?

Il y a fort à parier que ce jeu (non pas ce jeu là) dans la mécanique empêche l'appuie efficace sur les boutons en caoutchouc.

Après re-démontage et observation,

La croix et le disque-tige reposent sur le boitier arrière de la manette :

J'ai tout nettoyé et rien constaté d'anormal…

Pensant que sans doute, le téton au centre du disque se serait usé avec le temps, j'ai tenté de coller un morceau de plastique fin (0,3 mm) dans le fond qui l’accueille :

Et ainsi la croix de direction s'est remise à fonctionner parfaitement !
Pourtant la croix gigote encore beaucoup, et pris d'un doute, je décidais de démonter la seconde manette aussi.

Et là, double constat ! Il y a de la graisse sur le téton, et une fois le fond de la manette nettoyé, on voit bien que l'espèce de poteau qui accueille le téton est en fait censé être plat, puisqu'avec cette manette-ci, moins usée, il y a un petit creux au milieu :

Ok donc en fait sur la première manette, le poteau parfaitement creux était surtout parfaitement et uniformément usé…!

Sur la seconde manette, de manière à combler le petit creux, collage d'un petit morceau de plastique de 0,3 mm d'épaisseur, qui a ensuite été poncé à ras :

Puis collage d'un second morceau pour réduire encore plus le jeu mécanique. La graisse a été récupérée et replacée au sommet du téton :

Sur la première manette, même travail. Ponçage de l'ajout en plastique déjà en place afin d’aplanir la surface, et ajout d'une seconde épaisseur. Comme il n'y avait plus de graisse, j'ai utilisé de la graisse au silicone en remplacement :

Yapuka remonter en vissant correctement !

Voilà, comme neuve !

Après ça je ne suis plus étonné de me rendre compte qu'appuyer comme un sot sur la croix n'avait aucun effet, étant donné la manière dont sont conçues ces manettes, en contact indirect. Alors que sur des manettes classiques ma peut marcher car on appuie directement, au moins pour constater que le contact est mauvais.

Lumiplot, le système lumineux pour cône de roller slalom -3-

makoto — Thu, 06 Feb 2025 19:57:00 +0100

Suite des expérimentations précédentes :

Le moment tant attendu étant arrivé, nous nous sommes réunis à l'occasion d'une session de roller nocturne sur le spot de slalom.

Voici l'ambiance lumineuse que nous avions sur place, qui malgré les lampadaires trop éclairants à mon goût ne nuisait pas forcément au spectacle.

Il suffit de constater à quel point la ligne de plots lumineux surpasse de loin la présence de la ligne classique sur la droite !
Précisons que les 3 leds de chacun des modules sont allumées.

J'ai tenté quelques clichés en bricolant les réglages de l'appareil photo afin de faire ressortir un peu plus la présence des plots sans avoir trop de halo de lumière autour.

Après ces quelques essais, j'ai préféré utiliser ces réglages pour faire des vidéos.

Un spécialiste en photo m'indiquera peut-être comment j'aurais dû plutôt procéder…? Cependant, c'est fait !

En voici le montage :

Voilà ! Nous sommes donc tout à fait satisfaits du résultat ^__^
Les plots se comportent très bien et comme attendu se renversent moins facilement que sans module. Il arrive que le module se déchausse du cône, mais c'est à priori assez rare et dans la grande majorité des cas ils restent bien en place.

À suivre

Le site est en travaux…

makoto — Mon, 03 Feb 2025 21:27:00 +0100

Et reste ouvert durant ceux-ci.

Je bricole une barre de menu en haut de page, le truc que je voulais faire depuis au moins 10 ans…

L'idée serait donc de rendre les réalisations plus accessibles.
Il est possible qu'il se passe donc des trucs bizarres avec l'interface graphique, c'est juste moi qui teste des choses et range mon bordel.
La consultation des pages devrait pouvoir continuer sans soucis majeur.

Lumiplot, le système lumineux pour cône de roller slalom -2-

makoto — Sun, 05 Jan 2025 22:01:00 +0100

Suite des expérimentations précédentes :

Cependant, le cône coloré est problématique car il atténue et filtre la lumière, voire même annule la couleur de led opposée à celle du cône, et pour cette raison il a été décidé de passer sur un plot blanc et de revoir certaines choses que nous allons détailler ici.

**Second prototype, avec le plot Seba.** :

Cette fois le plot est rigide sur sa base et mou sur le dessus, permettant plus de sécurité en cas de chute.

Nouveau boîtier :

Il était aussi nécessaire de modifier le boîtier afin de faciliter l'impression 3D et le rendre plus solide et reproductible.
En effet, le logement très étroit de la batterie a eu vite fait de se fendre à force d'y insérer la batterie, un système de couvercle à visser semblait incontournable.
De même, la pièce transparente de protection du circuit a fini par se décoller, là encore il fallait envisager un système à vis, ne serait-ce que pour intervenir facilement en cas de maintenance.

Les modifications sus-citées, avec taraudage des trous de vis directement dans le plastique :

À ce stade, nous attendions de recevoir les pièces transparentes découpées au laser commandées auprès d'un prestataire, ainsi que les petites vis de 2 mm de diamètre.

Et il fallait tout de même fiabiliser un peu plus la fixation au plot en ajoutant un aimant supplémentaire.

Je n'ai pas pensé à prendre plus de clichés de ce modèle à aimants interagissant avec le cône…

Une fois ce prototype achevé, nous étions cette fois très satisfaits du rendu en lumière, ici dans la pénombre :

Notez que les photos ne rendent pas ce que l'œil humain perçoit. Souvent entouré d'un halo de lumière grossier, j'ai dû bricoler les réglages de la prise de vue, ici avec un ordi-phone, pour qu'on puisse discerner distinctement l'objet. En réalité donc c'est plus lumineux que ça.

Après quelques tests de simulation d'usage, consistant à malmener le plot en le secouant, le culbutant, le frappant et le dégageant, il nous est rapidement apparu quelques problèmes.
Le module ne tient pas suffisamment bien en place et beaucoup de questions, pourtant déjà présentes, vinrent semer le doute.

Après tant de travail fourni à souder les plaquettes, et celui qui nous attendait pour la suite, la crainte de dommages matériels nous obligeât à prendre une pause pour réfléchir…
Quand le module se fait éjecter, jusqu'où va-t'il ? Est-il facile à ramasser ? Que se passe-t'il si on roule dessus ? Sans doute la casse assurée… Et pire en fait, l'accident sur l'humain, qui plus que de risquer une hypothétique explosion de batterie, se retrouverait forcément au sol, à cause des roues de roller bloquées net par le module.

Cela paraissait pourtant correct avec le plot Oxelo, sans doute car il nous semblait que nous n'avions pas trop le choix étant donnée la souplesse du plastique.

Nous n'avions pas pensé à remettre en question le sujet intégrant ces nouveaux paramètres induits par le cône Seba.

À contrecœur (oui les aimants c'était un système amusant :P) nous avons donc engagé un processus de réflexion, qui nous a menés vers l'évolution suivante.

Puisque le haut du plot est souple, alors nous pourrions considérer que l'aspect sécuritaire de celui-ci réside dans le fait qu'il est fait pour voir sa base résister quand le haut s'écrase, permettant alors de garder le module lumiplot en place durant les chocs avec les roues, les patins et les humains.
Puisque la base du plot est rigide, autant la mettre à profit, en permettant au module de se clipser facilement dessus.
De plus, l'article du site roller en ligne nous l'indiquait, la prise au vent de ce modèle de cône serait un point à améliorer, et c'est en quelque sorte l'occasion de le faire car le module va alors lester quelque peu le plot pile à l'endroit voulu, à sa base.
La voila la solution !! Restait alors à modifier le modèle 3D pour changer tout ça, mais sans pouvoir tout refaire, car certaines pièces comme les plaquettes transparentes sont déjà dans nos mains et il n'est pas question d'en commander une version modifiée.

Troisième version du boîtier :

Le couvercle à batterie a été modifié pour présenter une sorte de languette dépassante. Une petite pièce avec une languette est ajoutée du côté du circuit, elle sera collée. Devant la multitude à faire, les trous de vis ne seront plus taraudés, mais remplacés par des inserts métalliques filetés qui seront bien plus rapides à disposer.

On utilise un fer à souder pour pousser l'insert dans le trou de plastique qui se ramollit et durcit immédiatement autour du métal après la pose.

Pour accueillir les languettes, il faut découper de larges fentes dans le cône :

Voilà !! En pressant les bords du cône, on peut alors glisser le module dans les fentes.

Clichés pris à l'ordi-phone en lumière ambiante, cette fois pas eu besoin de toucher aux réglages.

Mise en production :

Quasiment toutes les pièces sont réunies, l'impression des boîtiers étant la plus longue :

Il y a un travail important d'ébavurage des pièces imprimées ainsi que de collage des languettes, qui en fait aurait pu être conçues d'un seul tenant avec le boîtier… Là encore, modifier l'existant est le risque de manquer de recul pour repenser une solution technique. Chose que je corrigerai donc dans mes fichiers 3D.

Les vis et inserts sont arrivés. J'ai soudé toutes les batteries sur les circuits et j'en profite pour les mettre en charge :

Pour faciliter la découpe des plots, j'ai imprimé un gabarit pour guider la lame afin de marquer le plastique toujours au bon emplacement.

Toutes les pièces prêtes pour l'assemblage, le cône marqué pour découpe.

Le Lumiplot terminé !

Petit plaisir en fin de production :

Ces photos prises dans le noir sont à peu prés représentatives de la réalité, les plots brillent assez pour s'éclairer les uns les autres.

Et une petite vidéo « mode d'emploi » :

Quelques photos et conclusion :

Comparatif de rendu lumineux avec 1, 2 ou 3 leds allumées :

Ça brille fort ! Comme je disais la dernière fois, à l'œil avec une led c'est déjà bien suffisant, en tous cas en déco de salon. Il faudra décider en situation si on privilégie l'autonomie ou le spectacle.

Ci-dessous, la première à l'ordi-phone et la seconde à l'appareil photo en baissant la sensibilité afin de faire ressortir les différences.

Une galerie de clichés avec l'appareil réglé pour ne pas éblouir l'objectif. Ces couleurs sont plus proches de la réalité :

En effet l'ordi-phone, ici à gauche sature un peu trop les couleurs.

Nous avons donc enfin nos Lumiplots tant attendus et fonctionnels !
Les premiers essais en situation se passent bien, nous verrons à l'usage ce qu'il en est de la fiabilité, notamment confrontée à la réalité des rollers.
Les fichiers de conception 3D sont disponibles en annexe à ce billet.
Dans un prochain billet nous essayerons de tourner une belle vidéo en situation d'usage.

まこと の ブログ

IR « Light » Gun avec Arduino - Mundo Yakara -

Décapotes -04-, circuit de positionnement d'image pour écran TV

Un quatrième circuit d'essais :

À suivre…?

Note

Décapotes -03-, circuit de positionnement d'image pour écran TV

Un troisième circuit d'essais :

Une piste intéressante… :

Note

Pocket SDVX pico, Makoto's edition -5-

Pocket-SDVX-Pico MAKOTO final.zip :

Firmware Pico-Game-Controller-20220705-v4 Makoto-edition.tar.gz :

Pocket SDVX pico, Makoto's edition -4-

Le fond :

Finitions :

Fonctionnalités :

Conclusion et démonstration en jeu :

Galerie :

Péritel multiple

Un peu de contexte,

Retour à aujourd'hui,

Réalisation :

Démo :

Joystick Arcade pour Nintendo GameCube

RecalStick -2-

Perçage de la ventilation :

Fixation du Raspberry pi 4 :

Câblage :

Quelques détails… :

Galerie :

À suivre…

Décapotes -02-, circuit de positionnement d'image pour écran TV

Un deuxième circuit d'essais :

IQS−PGM - Labels pour cartouche de jeu DIY

RecalStick -1-

Les plans :

Le matériel :

L'usinage de la façade arrière :

Le collage du cadre :

La taille des coins :

Fixation du panel et du fond :

La taille de la face avant :

Le perçage des trous :

La fixation du stick :

L'installation des fournitures :

En attendant la suite…

Décapotes -01-, circuit de positionnement d'image pour écran TV

Un premier circuit d'essais :

IGS−PGM - Cartouche de jeu DIY N°3

La programmation :

Mise en cartouche et tests :

IGS−PGM - Cartouche de jeu DIY N°2

La programmation :

Mise en cartouche et tests :

Piloter un ventilateur pour Odroid-C2

L'électronique :

La PWM sur GPIO :

Automatisation :

Modifications utiles :

Lumiplot, le système lumineux pour cône de roller slalom -4-

À suivre…?

Réparer la croix de direction des manettes Megadrive

Lumiplot, le système lumineux pour cône de roller slalom -3-

Le site est en travaux…

Lumiplot, le système lumineux pour cône de roller slalom -2-

Second prototype, avec le plot Seba. :

Nouveau boîtier :

Troisième version du boîtier :

Mise en production :

Quelques photos et conclusion :

まこと　の　ブログ

**Second prototype, avec le plot Seba.** :