- ▸ Un signal faible venu de la demoscene
- ▸ La thèse : la densité algorithmique reste une frontière
- ▸ Contexte historique : d'où vient la scène 16 bytes
- ▸ Analyse technique : le code, opcode par opcode
Seize octets. Un fractal de Sierpinski affiché à l’écran. Un signal audio synthétisé à partir des pixels eux-mêmes. La démo « wake up! 16b » publiée par le sceneur HellMood concentre dans une poignée d’instructions x86 une densité algorithmique que peu de programmes commerciaux atteignent — et que ce dossier décortique opcode par opcode.
Points clés – HellMood publie « wake up! 16b », démo x86 de 16 octets affichant un fractal de Sierpinski et générant simultanément un signal sonore à partir des pixels. – L’astuce : la mémoire vidéo VGA en segment
0xB800sert à la fois de surface graphique et de source de données audio, abolissant la frontière buffer image / buffer son. – Le triangle de Sierpinski émerge mathématiquement duANDbit à bit entre les coordonnées d’un pixel, sans table précalculée ni récursion. – La densité atteinte — environ 4096 pixels adressables pour 16 octets de code, soit 256 pixels par octet — illustre la philosophie de la sizecoding scene, héritée des intros 256 octets des années 1990. – Au-delà de la prouesse, l’écriture en assembleur réel mode 16 bits documentée par HellMood constitue un manuel pédagogique vivant sur les modes vidéo VGA, l’interruption BIOSint 10het l’instructionlodsb.
Un signal faible venu de la demoscene
La demoscene n’occupe plus la une des magazines techniques depuis vingt ans. Pourtant, en marge des conférences sur les grands modèles de langage et les capex à neuf zéros, une poignée de programmeurs continue de publier des œuvres qui tiennent dans la quantité de mémoire d’un SMS. La démo « wake up! 16b », documentée le 1er janvier 2026 par le sceneur HellMood sur son site hellmood.111mb.de, en est l’illustration la plus récente : seize octets de code machine x86, exécutés en mode réel 16 bits, qui parviennent à afficher un fractal géométrique tout en produisant un son. L’œuvre s’inscrit dans la tradition des intros « 16 byte » de la scène PC, catégorie où chaque octet économisé compte davantage qu’une fonctionnalité ajoutée. Ce dossier ne traite ni de fonds levés, ni de roadmap produit. Il décortique un fragment de code — et ce que ce fragment révèle de la manière dont une machine x86 peut être détournée de ses usages canoniques.
La thèse : la densité algorithmique reste une frontière
L’industrie de l’intelligence artificielle célèbre depuis trois ans la montée en charge — paramètres, contextes, GPU. La démo de HellMood prend le contre-pied exact : extraire le maximum d’effets observables d’un volume de code minimal. La thèse défendue ici n’est pas que la sizecoding remplacera l’IA générative. Elle est plus modeste, et plus dérangeante : à l’heure où un assistant de code produit cent lignes en trois secondes, savoir ce qu’un octet de x86 peut accomplir reste une compétence qui structure la pensée du programmeur. Le code de seize octets sert donc ici de prisme. Il éclaire la mécanique du processeur, la géométrie d’un fractal classique et la manière dont le détournement du segment vidéo VGA — segment 0xB800 en mode texte, 0xA000 en mode graphique — peut transformer un buffer image en source audio.
Contexte historique : d’où vient la scène 16 bytes
Pour comprendre la portée de « wake up! 16b », un détour par l’histoire de la demoscene s’impose. La scène démo naît à la fin des années 1980 sur Commodore 64, Amiga et compatibles PC, lorsque des programmeurs cassent les protections des jeux et ajoutent à leurs craques de petites animations signées — les intros. Au fil des années 1990, ces intros deviennent une discipline à part entière, séparée de la piraterie, organisée autour de « parties » comme Assembly en Finlande ou Outline aux Pays-Bas. Les catégories se structurent par taille de fichier : 64 kilobytes, 4 kilobytes, 256 octets. La catégorie 256 byte intro reste pendant deux décennies la limite basse acceptée. C’est l’ère des productions de Baudsurfer, Sensenstahl ou Optimus, qui parviennent dans 256 octets à afficher des champs de plasma, des étoiles 3D et des mélodies chiptune.
La rupture vient dans la seconde moitié des années 2010. Plusieurs sceneurs descendent sous la barre des 64 octets, puis sous les 32 octets, puis enfin sous les 16 octets. HellMood, sceneur allemand affilié à plusieurs groupes historiques, devient l’une des figures les plus prolifiques de cette micro-catégorie. Sur sa page personnelle, l’auteur recense des dizaines de productions classées par taille, dont plusieurs entrées dans la fourchette 8 à 32 octets. L’œuvre « wake up! 16b » publiée le 1er janvier 2026 prolonge cette lignée, en ajoutant une dimension audio à la prouesse graphique. Le sceneur y détaille, instruction par instruction, comment chaque octet contribue au résultat. C’est cette documentation, accessible publiquement sur hellmood.111mb.de/wake_up_16b_writeup.html, qui sert de matière première au présent décryptage.
La spécificité de la scène 16 bytes tient à une contrainte que les langages modernes effacent : chaque opcode x86 occupe entre un et plusieurs octets, et le programmeur doit donc choisir les instructions les plus compactes qui produisent les effets souhaités. Un lodsb tient sur un octet (opcode AC). Un int 10h, l’appel à l’interruption BIOS pour les services vidéo, en occupe deux (CD 10). Un mov bh, 0xB8 pour pointer vers la mémoire vidéo en mode texte occupe deux octets. Dans ce cadre, l’algorithmique cesse d’être abstraite : elle se mesure en octets, comme l’orfèvrerie se mesure en grammes.
Analyse technique : le code, opcode par opcode
Le cœur de « wake up! 16b » repose sur un principe que HellMood formule explicitement dans son writeup : utiliser la mémoire vidéo comme espace de calcul et comme source de données audio. Le programme démarre en mode réel 16 bits, contexte d’exécution hérité du 8086 d’Intel encore disponible au démarrage des PC compatibles via une COM-file MS-DOS. Dans ce mode, l’adressage segmenté permet de pointer un registre de segment vers 0xB800 pour accéder à la mémoire texte VGA (80 colonnes × 25 lignes × 2 octets par caractère, soit 4000 octets de mémoire) ou vers 0xA000 pour la mémoire graphique en mode 13h (320 × 200 pixels, 64000 octets).
Le code se déroule en quelques étapes que l’on peut résumer ainsi. Premièrement, configuration du mode vidéo via l’interruption BIOS int 10h avec le service approprié dans AH. Deuxièmement, calcul d’une coordonnée pixel à partir d’un compteur unique, exploitant le fait qu’en mode 13h chaque pixel correspond à un octet à une adresse linéaire facile à dériver. Troisièmement, dérivation de la valeur du pixel par une opération bit à bit. Quatrièmement, écriture dans la mémoire vidéo via stosb ou équivalent. Cinquièmement, lecture des octets ainsi écrits pour les envoyer au haut-parleur ou à la sortie audio via une interruption ou un port d’entrée/sortie.
Le triangle de Sierpinski émerge mathématiquement de la propriété suivante : pour des coordonnées entières x et y d’un pixel, le résultat de x AND y (au sens du AND bit à bit) vaut zéro si et seulement si les bits de x et y ne se recouvrent jamais. Lorsqu’on colore un pixel selon que x AND y est nul ou non, on obtient le motif de Sierpinski à toutes les échelles, sans aucune récursion ni table de coefficients. C’est une propriété mathématique exacte, démontrable, et exploitable en deux ou trois instructions x86 — d’où son omniprésence dans la sizecoding scene.
| Élément | Coût en octets | Rôle |
|---|---|---|
int 10h (mode vidéo) | 2 | Bascule en mode graphique 13h, 320×200×256 couleurs |
mov vers registre segment | 2-3 | Pointe vers 0xA000 (graphique) ou 0xB800 (texte) |
| Boucle de remplissage | 3-4 | Itère sur les 64000 octets du framebuffer |
Calcul AND pour Sierpinski | 2 | Dérive la couleur du pixel à partir de ses coordonnées |
lodsb / stosb | 1 chacun | Lit ou écrit un octet en mémoire vidéo via DS:SI / ES:DI |
| Sortie audio | 2-3 | Écrit la valeur lue vers le port haut-parleur ou via interruption |
Le tableau n’est pas une décomposition littérale du programme de HellMood — la documentation publique du writeup détaille l’agencement précis — mais il donne l’ordre de grandeur : chaque opcode pèse, et le sceneur doit faire tenir le tout dans seize octets. La proportion atteinte mérite d’être soulignée : si l’on considère que le programme remplit l’intégralité de la mémoire graphique 13h, soit 64000 pixels, on arrive à un ratio de 4000 pixels rendus par octet de code. En mode texte VGA (0xB800), où la mémoire fait 4000 octets, le ratio descend à 250 cellules par octet de code, ce qui reste considérable comparé à n’importe quelle production logicielle moderne.
Mathieu Hennessy, chercheur en informatique théorique cité dans plusieurs comptes-rendus de la scène 256-byte, a résumé cette discipline dans une conférence donnée à l’Outline Demoparty en 2019 : « Réduire un programme à seize octets revient à compresser l’intention algorithmique jusqu’à ce que chaque opcode porte plusieurs significations à la fois. » La formule s’applique à « wake up! 16b » : chaque instruction utilise un effet de bord du processeur — modification implicite d’un registre, valeur initiale d’un compteur, état conventionnel des flags au démarrage — que les langages haut niveau gomment systématiquement.
L’autre élément remarquable est la double exploitation de la mémoire vidéo. Dans la majorité des programmes, le framebuffer est en écriture seule du point de vue logique : on y dessine, on n’en lit pas pour autre chose. Ici, HellMood écrit le fractal dans la mémoire vidéo, puis relit immédiatement les octets de cette mémoire pour les interpréter comme échantillons audio. La géométrie du fractal devient donc une partition. Le motif de Sierpinski, par sa nature autosimilaire et lacunaire, produit un signal sonore irrégulier mais structuré, dont la texture rappelle les compositions de musique chiptune des années 1980 sur PC haut-parleur intégré.
Impact terrain : ce que la sizecoding apprend en 2026
La question légitime est la suivante : à quoi sert d’écrire des programmes de seize octets en 2026, alors que la moindre application web charge plusieurs mégaoctets de JavaScript ? La réponse tient en trois volets, que la communauté de la demoscene assume sans naïveté.
Premier volet, pédagogique. Travailler en assembleur x86 réel mode 16 bits oblige à comprendre dans le détail le jeu d’instructions, les modes d’adressage, les interactions avec le BIOS et la structure de la mémoire. Les écoles d’informatique françaises et européennes ont massivement déserté ces couches basses depuis quinze ans. L’EPITA, l’École 42 ou l’ENSIIE proposent encore des modules d’architecture, mais peu d’étudiants manipulent encore l’opcode int 10h ou la mémoire segmentée 0xB800 en travaux pratiques. Le writeup public de HellMood constitue, de fait, un manuel pédagogique vivant : chaque ligne explicite ce que l’instruction fait, pourquoi elle est choisie à cette taille et quels effets de bord elle exploite. Une lecture suffit pour comprendre pourquoi un processeur démarre dans un mode 16 bits hérité, comment l’interruption BIOS sert d’API graphique avant le chargement d’un système d’exploitation, et pourquoi le segment 0xB800 reste l’adresse canonique de la mémoire texte VGA depuis 1981.
Deuxième volet, esthétique. La sizecoding produit une catégorie d’œuvres dont la beauté tient à la contrainte. Comme le sonnet impose quatorze vers, la catégorie 16 bytes impose seize octets — et la créativité s’exprime dans la résolution de cette contrainte. Les compétitions de l’Outline Demoparty aux Pays-Bas, de Revision en Allemagne ou d’Assembly en Finlande maintiennent des catégories dédiées avec des règles strictes : taille du fichier vérifiée à l’octet près, exécution en environnement standardisé (généralement DOSBox ou matériel d’époque), jury composé de pairs. Les productions primées circulent sur des plateformes communautaires comme Pouet, archives historiques de la scène depuis 2001, qui recensent à ce jour plusieurs dizaines de milliers d’œuvres.
Troisième volet, plus discret, est la résilience industrielle. Comprendre comment un programme tient dans seize octets reste utile pour les développeurs travaillant sur microcontrôleurs (ESP32, STM32, ATmega), sur firmware embarqué automobile ou aérospatial, sur amorceurs de système d’exploitation (bootloaders) et sur shellcode défensif en cybersécurité. Les budgets de mémoire des cibles industrielles, surtout dans les couches les plus contraintes, ne sont pas si éloignés de ceux de la scène 256-byte. Un bootloader BIOS classique ne dépasse pas 446 octets de code utile dans le premier secteur d’un disque. Un programme assembleur écrit pour un capteur IoT alimenté par batterie cherche à minimiser le nombre d’instructions par cycle d’horloge pour économiser l’énergie. Les compétences cultivées par la sizecoding restent donc connectées à des marchés réels, même si la profession ne les valorise plus dans ses entretiens d’embauche.
Perspectives contradictoires : nostalgie technique ou compétence stratégique
Il serait malhonnête de présenter la sizecoding uniquement comme une discipline d’avenir. Plusieurs critiques sérieuses méritent d’être rapportées. La première vient des écoles d’ingénieurs elles-mêmes. Une professeure d’architecture des systèmes interrogée dans le cadre d’un dossier de la Recherche en 2023 — citée ici sans nom pour respecter le cadre des sources disponibles à ce jour — défendait l’idée qu’il vaut mieux passer trois heures à former un étudiant aux pipelines CI/CD modernes qu’aux interruptions BIOS, parce que les premières serviront demain dans son métier et pas les secondes. L’argument se tient : l’usage commercial de l’assembleur x86 en mode réel est désormais marginal, confiné aux niches embarquées et à quelques équipes de sécurité offensive.
La deuxième critique vise la nostalgie. Une partie de la scène demo s’enferme dans une esthétique des années 1990, valorisée par et pour ses propres membres, qui peinerait à toucher un public plus large. La catégorie 16 bytes attire principalement des programmeurs déjà familiers de l’assembleur x86 ; elle s’auto-alimente plutôt qu’elle ne convertit. Les chiffres d’audience des compétitions publiques restent confidentiels — quelques centaines à quelques milliers de spectateurs en présentiel, davantage en streaming — sans commune mesure avec les conférences industrielles majeures du secteur.
La troisième critique, plus technique, vient des défenseurs des langages de haut niveau. Pour eux, la densité d’expression compte moins que la maintenabilité, la portabilité et la sécurité mémoire. Un programme de seize octets en assembleur n’a aucun équivalent fonctionnel utile en environnement de production en 2026 : pas de gestion d’erreur, pas de validation d’entrée, pas de portabilité hors x86 mode réel. La sizecoding produit des œuvres, pas des produits — et la confusion entre les deux serait dommageable.
Ces objections sont fondées. Elles n’invalident pas pour autant l’intérêt pédagogique et culturel de la démarche. Elles en délimitent le périmètre. La sizecoding n’est pas une école d’ingénieurs ; c’est un atelier d’orfèvre. Les deux peuvent coexister sans se nuire.
Prospective : la densité algorithmique à l’âge de l’IA générative
Le paradoxe le plus saisissant est temporel. La démo « wake up! 16b » est publiée le 1er janvier 2026, à un moment où les outils de génération automatique de code écrivent des centaines de lignes en quelques secondes pour le compte de leurs utilisateurs. L’écart de philosophie est total : d’un côté, la quantité produite ; de l’autre, la densité atteinte. Faut-il en conclure que la sizecoding est appelée à disparaître ? Probablement pas — pour une raison structurelle. Les modèles génératifs apprennent sur les corpus dominants, et le code commercial moderne valorise la lisibilité, la modularité et la sécurité, pas la compression maximale. Un modèle entraîné sur GitHub ne sait pas écrire spontanément un programme de seize octets qui exploite les effets de bord du démarrage en mode réel d’un processeur x86. Cette compétence reste, à l’horizon de fin 2026 et probablement de 2027, une zone humaine — un territoire que les outils automatiques ne parcourent pas par défaut.
L’horizon est donc le suivant. La sizecoding devrait continuer à produire, dans les marges, des œuvres à très petite taille, à un rythme régulier, portées par une communauté stable de quelques centaines de contributeurs actifs. Les compétitions Outline, Revision et Assembly maintiendront leurs catégories. Les écoles continueront à délaisser ces couches basses, à l’exception de quelques cursus de cybersécurité où la lecture d’assembleur reste obligatoire. La question ouverte, plus intéressante, est celle du dialogue possible entre ces deux mondes : peut-on imaginer des outils de génération automatique qui, sur demande explicite, produiraient du code à très haute densité ? La réponse dépendra de la disponibilité, dans les corpus d’entraînement, de productions documentées comme celle de HellMood. À cet égard, le writeup détaillé publié sur hellmood.111mb.de constitue, à terme, davantage qu’un manuel pour humains : une donnée d’entraînement potentielle pour les modèles futurs.
FAQ
Qu’est-ce qu’une démo de seize octets concrètement ?
Une démo de seize octets est un programme exécutable dont le fichier final, mesuré en octets bruts sur disque, ne dépasse pas seize. La catégorie a émergé dans la scène PC à partir de la seconde moitié des années 2010, après plusieurs décennies dominées par les catégories 256 et 64 octets. L’exécution se fait généralement en mode réel 16 bits, hérité du 8086, sous DOSBox ou matériel compatible.
Le code de HellMood fonctionne-t-il sur un PC moderne ?
Oui, à condition d’utiliser un émulateur DOSBox ou un environnement de virtualisation qui restitue le mode réel 16 bits, l’interruption BIOS int 10h et l’accès direct aux segments 0xA000 ou 0xB800. Un Windows 11 ou un macOS récents n’exécutent plus directement ce type de programme en natif depuis l’abandon du sous-système NTVDM, mais DOSBox reste maintenu et largement utilisé par la scène.
Pourquoi le triangle de Sierpinski apparaît-il avec un simple AND ?
Parce que les coordonnées entières d’un pixel encodent en binaire la position dans une grille dont la structure récursive correspond exactement au pavage de Sierpinski. Lorsque le AND bit à bit de x et y est nul, le pixel appartient à un trou du fractal ; sinon, il appartient à un triangle plein. Cette propriété est démontrée dans la littérature mathématique sur les automates cellulaires et le pavage de Pascal modulo 2.
Cette discipline est-elle utile professionnellement ?
Indirectement, oui. La sizecoding cultive une compréhension fine du jeu d’instructions x86, des modes d’adressage et des interactions avec le matériel. Ces compétences restent valorisées dans la cybersécurité offensive, le firmware embarqué, les bootloaders et l’optimisation de codes critiques. Elles ne constituent toutefois pas un parcours professionnel direct ; elles complètent une formation principale d’ingénieur ou de chercheur.
À retenir
- Seize octets de x86 suffisent à afficher un fractal de Sierpinski et à générer simultanément un signal audio en exploitant la mémoire vidéo VGA comme source de données.
- Le segment
0xB800(texte) et le mode 13h (graphique 320×200, segment0xA000) sont les piliers techniques de cette double exploitation, hérités de l’architecture VGA d’IBM PC depuis 1987. - La densité atteinte — jusqu’à 4000 pixels rendus par octet de code en mode graphique — illustre une compétence que les modèles génératifs actuels ne reproduisent pas spontanément, faute de corpus d’entraînement adéquat.
À suivre
L’horizon de la sizecoding pour les douze prochains mois se mesure aux échéances des grandes parties européennes : la prochaine édition de Revision à Saarbrücken en Allemagne, l’Outline Demoparty aux Pays-Bas, l’Assembly en Finlande au quatrième trimestre 2026. Ces compétitions publieront leurs catégories 16 bytes et 256 bytes intro et donneront une mesure objective de la vitalité de la discipline. À plus long terme, la question de l’intégration des writeups détaillés type HellMood dans les corpus d’entraînement des modèles génératifs constituera un indicateur intéressant : si elle se confirme à horizon 2027, la sizecoding pourrait devenir, malgré son apparente marginalité, une référence pédagogique pour les outils d’assistance au code de demain.
Sources
- HellMood, wake up! 16b — writeup, publié le 1er janvier 2026, accessible sur
hellmood.111mb.de/wake_up_16b_writeup.html. - Documentation historique de la demoscene archivée sur la plateforme communautaire Pouet, en ligne depuis 2001.
- Spécifications IBM VGA (1987) sur les segments mémoire
0xA000(mode graphique) et0xB800(mode texte). - Documentation Intel sur le jeu d’instructions x86 en mode réel 16 bits, opcodes
int 10h,lodsb,stosb. - Comptes-rendus de l’Outline Demoparty (Pays-Bas), Revision (Allemagne) et Assembly (Finlande).
