Vue normale

Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.
À partir d’avant-hierFlux principal

Doom tourne désormais sur un bracelet Xiaomi Mi Band 10

22 juin 2026 à 15:06

Il y a des gens qui se détendent en regardant une petite série. Aaron Christophel, lui, se détend en désossant des bracelets connectés Xiaomi pour leur faire cracher du code qu'aucun ingénieur de la marque n'avait prévu.

Ce bidouilleur allemand, plus connu sous le pseudo atc1441, vient de s'attaquer au Mi Band 10, et il en a tiré ce que la communauté du hack matériel considère comme le sacre suprême depuis trente ans : un portage de Doom, le jeu de tir sorti en 1993.

Le jeu n'était pourtant pas le problème. La puce, si.

Le Mi Band 10 utilise un BES2700iMP, un composant fabriqué par Bestechnic, un fondeur chinois qu'on croise surtout dans des écouteurs sans fil parce qu'il est taillé pour la basse consommation. Petite subtilité qui complique tout : chez Bestechnic, cette même puce répond aussi au nom de code BEST1503.

Or pour programmer un composant pareil, il faut son SDK, autrement dit le kit fourni par le fabricant avec la documentation et les outils pour développer dessus. Et là, surprise : pour ce modèle, aucun SDK public. Rien du tout. Christophel s'est donc retrouvé face à une puce muette, sans plan ni notice.

Sa porte d'entrée, il l'a trouvée du côté d'une cousine quasi jumelle. Le BEST1306, un autre composant Bestechnic, partage la même architecture, et lui possède un SDK qui a fuité par le biais de kits de développement audio. En recoupant patiemment les deux, il a reconstitué par rétro-ingénierie, ce travail qui consiste à remonter le fonctionnement interne d'un appareil sans en avoir les plans, un SDK compatible avec le BES2700iMP.

Le reste a suivi. Firmware maison, c'est-à-dire le logiciel bas niveau qui pilote directement le matériel, puis portage de Doom via le projet GBADoom. Tout n'est pas nickel pour autant : l'écran fonctionne en SPI un seul bit au lieu du quad-SPI dont il est capable, deux manières d'envoyer les pixels dont la seconde va nettement plus vite, ce qui plombe ici la fluidité et écrase les couleurs.

Screenshot

Bref, ça se joue, mais c'est moche. Et sur une dalle large de quelques centimètres, on reste évidemment dans l'exploit pour l'exploit plus que dans la séance de jeu.

Le détail qui fait un peu marrer vu le contexte actuel, c'est l'aveu de Christophel sur l'intelligence artificielle : elle ne lui a quasiment servi à rien. Les données techniques de ces puces propriétaires n'existent nulle part dans les corpus d'entraînement des modèles, du coup les assistants brassaient du vide.

Et ce n'est pas fini. Le Mi Band 9 embarque exactement le même matériel, ce qui signifie que le SDK reconstitué devrait y tourner tel quel, sans toucher une ligne. Tout est documenté et publié sur GitHub, à la disposition de quiconque veut prolonger cette bien belle aventure.

Bref, faire tourner un jeu de 1993 sur un bracelet de sport ne sert objectivement à rien, et c'est précisément pour ça que c'est toujours très cool.

Source : Hackaday

Un clone de DOOM en COBOL ça vous dit ?

8 juin 2026 à 18:17

Un développeur connu sous le pseudonyme icitry s'est posé une question que personne de sensé ne formule jamais, peut-on coder un jeu de tir à la première personne en COBOL ? La réponse, contre toute attente, est oui, et le résultat est même tout à fait jouable.

Pour ceux que ce nom laisse de marbre, COBOL, pour Common Business Oriented Language, est un langage né en 1959 qui fait encore tourner aujourd'hui une partie des mainframes chargés de vos virements bancaires et de la paie. C'est l'outil de la gestion et des relevés de compte, à peu près l'inverse de ce qu'on imagine pour un jeu vidéo.

Le moteur du jeu repose sur le raycasting, cette technique qui a propulsé Wolfenstein 3D au début des années 90. Le programme projette une rangée de rayons depuis le point de vue du joueur, regarde où chacun vient percuter un mur, et en déduit colonne par colonne la hauteur à dessiner. De la fausse 3D reconstruite à partir d'un simple plan vu de dessus.

Le vrai casse-tête, c'est que COBOL n'embarque aucune bibliothèque graphique, pas la moindre fonction pour allumer un pixel ou ouvrir une fenêtre. La parade est astucieuse. Le programme calcule lui-même chaque image, en recrache les pixels bruts sur la sortie standard du terminal, puis laisse un petit utilitaire nommé ffplay récupérer ce flux pour l'afficher comme une vidéo animée.

Même esprit de débrouille pour les commandes. Le terminal bascule en mode brut afin d'intercepter chaque touche sans attendre que vous validiez, pendant que le programme lit en continu ce qui arrive sur son entrée standard.

Et le rendu ne se limite pas à trois murs gris qui clignotent. On y trouve des sprites, des ennemis qui se baladent et vous tirent dessus, et même des secteurs de hauteur variable qui rapprochent l'ensemble du DOOM de 1993 plutôt que de son aîné Wolfenstein.

Le code complet est publié sur GitHub sous licence Apache, libre à chacun d'aller en fouiller les coulisses. Un internaute a d'ailleurs relevé que GnuCOBOL, le compilateur libre utilisé ici, sait parfaitement appeler du code écrit en langage C, ce qui ouvrirait l'accès à tout son arsenal de bibliothèques.

Toute la démonstration sert à rappeler que COBOL est Turing-complet, c'est-à-dire capable en théorie de calculer exactement la même chose que n'importe quel langage moderne, et à le prouver sur le terrain le plus hostile qu'on puisse lui opposer.

Bref, c'est rigoureusement inutile, et c'est très exactement pour ça que c'est cool.

Source : Hackaday

❌
❌