---
title: "Le moniteur ne savait plus ce qu'était le noir"
locale: "fr"
url: "https://irz.fr/fr/articles/pico-vga-scanvideo-six-pins-fr"
markdown_url: "https://irz.fr/fr/articles/pico-vga-scanvideo-six-pins-fr.md"
category: "tech"
tags: ["RP2040", "VGA", "PIO", "Scanvideo", "ZX Spectrum", "Arduino"]
published_at: "2026-08-25T17:00:00.000Z"
author: "Léa Perrin"
translation: "https://irz.fr/en/articles/pico-vga-scanvideo-six-pins-en.md"
---

# Le moniteur ne savait plus ce qu'était le noir

En disséquant la bibliothèque scanvideo du RP2040, Kevin est descendu de dix-sept broches VGA à six, assez pour les couleurs du ZX Spectrum. Et un pixel noir manquant a suffi à ternir tout l'écran.

L'écran affichait bien les couleurs du ZX Spectrum. Sauf qu'aucune n'avait l'air juste : tout semblait passé au gris sale, y compris ce qui devait être du blanc éclatant. La cause n'était ni le moniteur, ni le DAC à résistances, ni la bibliothèque vidéo. Il manquait un seul pixel noir à la fin de chaque ligne.

Ce détour par un écran terne est la dernière étape d'une série que publie Kevin depuis juillet, *Simplified Pico VGA* [1](https://emalliab.wordpress.com/2026/07/25/simplified-pico-vga/). Son objectif tient en une phrase : sortir du VGA sur Raspberry Pi Pico sans traiter la bibliothèque `scanvideo` comme une boîte noire. Avec une contrainte personnelle qui complique un peu tout : rester dans l'environnement Arduino [2](https://emalliab.wordpress.com/2026/08/01/simplified-pico-vga-part-2/). Adafruit a relayé la série fin juillet, puis à nouveau le 24 août [3](https://blog.adafruit.com/2026/08/24/simplified-raspberry-pi-pico-vga/).

## Dix-sept broches

Le point de départ officiel ne manque pas de moyens. Le manuel matériel du RP2040 documente une carte d'exemple qui produit du VGA avec trois DAC à résistances, cinq bits par canal rouge, vert et bleu. Cinq broches par couleur, plus HSYNC et VSYNC : dix-sept GPIO pour la seule vidéo [4](https://github.com/raspberrypi/pico-playground/tree/master/scanvideo). Sur un Pico standard qui en expose vingt-six, ça laisse peu de place au reste.

C'est ce design qu'utilise la Pico VGA Demo Base de Pimoroni, qui ajoute autour un lecteur SD et une sortie audio I2S [5](https://shop.pimoroni.com/products/pimoroni-pico-vga-demo-base). Pour bricoler soi-même sur breadboard, chaque canal se câble avec cinq résistances en échelle — 8K, 4K, 2K, 1K, 500R — et deux résistances de 47R pour les synchronisations [2](https://emalliab.wordpress.com/2026/08/01/simplified-pico-vga-part-2/).

> Illustration: Deux montages DAC côte à côte sur une carte d'essai VGA : cinq résistances par canal à gauche, configuration RGBY1111 avec diodes à droite. À gauche, le DAC RGB555 complet à cinq résistances par canal. À droite, la variante RGBY1111 : quatre fils couleur et des diodes. Credit: [Kevin / diyelectromusic](https://emalliab.wordpress.com/2026/08/01/simplified-pico-vga-part-2/).

Dix-sept broches, c'est le prix du confort. Tout le reste de la série marchande ce prix.

## La chasse aux fils

Avant d'écrire quoi que ce soit, Kevin a passé en revue ce qui existait déjà, et chaque projet raconte un compromis différent.

PicoVGA de Miroslav Nemecek descend à neuf broches en passant au format R3G3B2 : trois bits de rouge, trois de vert, deux de bleu, plus une sync composite. Son auteur assume le calcul : avec 264 Ko de RAM, sortir du 8 bits par pixel n'a guère de sens sur RP2040, et le dithering rattrape une partie de la perte [6](http://www.breatharian.eu/hw/picovga/index_en.html). Ce projet est aujourd'hui remplacé par DispHSTX, qui utilise le périphérique HSTX du RP2350 pour sortir du DVI et du VGA [7](http://www.breatharian.eu/hw/disphstx/index_en.html). Autre voie, autre usage : MCEBlaster lit les signaux TTL de cartes MDA, CGA et EGA d'époque et les convertit pour un moniteur VGA moderne, avec huit broches — deux bits par couleur et les deux syncs [8](https://github.com/scrapcomputing/MCEBlaster).

Mais le déclic vient d'ailleurs. En cherchant à recréer la palette du ZX Spectrum, Kevin tombe sur pico-zxspectrum, qui pilote un VGA dans un mode baptisé RGBY1111 : bleu, vert, rouge sur une broche chacun, et une quatrième broche qui joue la luminosité [9](https://github.com/fruit-bat/pico-zxspectrum). Le Y hérite directement de l'architecture du Spectrum de 1982 : ses attributs de couleur s'appliquent à des blocs de huit par huit pixels, et la brillance frappe tout le bloc. Quinze couleurs réellement distinctes — le noir existe en version « bright », donc en double — suffisaient déjà aux jeux de l'époque.

> **Compter les broches avant les couleurs**
> - RGB555 : cinq bits par canal, deux synchronisations.: 17
> - R3G3B2 : trois, trois, deux bits et une sync composite.: 9
> - Conversion TTL CGA/EGA : deux bits par canal.: 8
> - RGBY1111 final de Kevin : quatre fils couleur, deux syncs.: 6
> Relevé IRZ : designs Raspberry Pi/Pimoroni, PicoVGA, MCEBlaster, montage final documenté par Kevin.

De dix-sept à six. Ce qu'on paie en retour, ce sont les demi-teintes : ici, pas d'orange doux ni de bleu pâle, seulement quinze teintes franches.

## Des pixels en instructions

Restait à comprendre comment `scanvideo` occupe ces broches, et c'est là que la série devient passionnante.

La bibliothèque vit dans pico-extras [10](https://github.com/raspberrypi/pico-extras/blob/master/src/common/pico_scanvideo/README.adoc). Le CPU n'y touche jamais aux broches. Il remplit des buffers de tokens de seize bits, le DMA pousse le tout vers un state machine PIO, et c'est le PIO qui crache les pixels au rythme voulu. Pour le mode par défaut, la doc suppose du 5-5-5 plus une broche optionnelle de transparence, tout étant déplaçable via des définitions de compilation [10](https://github.com/raspberrypi/pico-extras/blob/master/src/common/pico_scanvideo/README.adoc).

Le tour de force se cache dans le programme PIO nommé `video_24mhz_composable_default` [11](https://github.com/raspberrypi/pico-extras/blob/master/src/common/pico_scanvideo/scanvideo.pio). Sa première instruction utile est `out pc, 16` : seize bits sortent du bus et atterrissent directement dans le compteur de programme. Autrement dit, chaque token choisit la suite des instructions. Un token COLOR_RUN saute vers le bloc qui pose une couleur sur les broches, lit un compte de pixels, boucle dessus, puis reprend un nouveau token. Les aplats deviennent très compacts — la doc parle de run-length encoding pour les zones de couleur plate [10](https://github.com/raspberrypi/pico-extras/blob/master/src/common/pico_scanvideo/README.adoc) — et deux paramètres de temporisation sont même réécrits à l'exécution pour étirer les pixels selon la résolution visée [11](https://github.com/raspberrypi/pico-extras/blob/master/src/common/pico_scanvideo/scanvideo.pio).

> pico_scanvideo
> **La ligne vidéo devient un flux de tokens**
> - Le CPU écrit des tokens 16 bits dans un buffer de scanline.: Remplir
> - Le DMA pousse le buffer vers la FIFO du PIO.: Transporter
> - Chaque token fait sauter le compteur de programme.: Décoder
> - Le PIO pose la couleur sur les broches, au cycle près.: Sortir
> Mécanisme du programme composable de pico-extras.

J'ai rarement vu un bus de données jouer le rôle d'un programme aussi littéralement. La mémoire ne contient pas seulement l'image : elle contient les instructions qui la dessinent.

## Le détour Arduino

Officiellement, `scanvideo` se consomme en C avec le SDK Raspberry Pi. Kevin tient à son IDE Arduino, donc il a déplacé la bibliothèque à la main sur le core Arduino-Pico d'Earle Philhower [12](https://github.com/earlephilhower/arduino-pico).

Les fichiers partent à plat dans le dossier du sketch. Les deux programmes PIO, eux, doivent être assemblés avant : il passe les fichiers `.pio` dans l'outil pioasm de Wokwi et colle le résultat dans deux headers. Et comme les modes vidéo se configurent par définitions de préprocesseur compilées jusque dans les fichiers C de la bibliothèque, un simple `#define` avant le `include` ne suffit pas : il greffe un petit `vgamode.h` directement dans `scanvideo.h`. La fonction qui tournait sur le second cœur se découpe entre `setup()` et `loop()`, la façon Arduino de dire « initialisation » et « boucle infinie ».

Kevin a aussi dessiné une carte d'essai entre le Pico et la prise VGA, publiée avec son schéma [13](https://github.com/diyelectromusic/sdemp_pcbs/tree/main/PicoVGABreakout). Un détail honnête, relevé dans son billet : le texte imprimé recommande 300R + 100R pour le RGBY1111, mais la bonne valeur est bien 330R, celle gravée à côté des composants.

> Illustration: Rendu du PCB PicoVGABreakout reliant un Raspberry Pi Pico à une prise VGA avec emplacements de résistances. La carte d'essai PicoVGABreakout de Kevin, conçue pour tester plusieurs DAC sans recâbler la breadboard à chaque essai. Credit: [Kevin / diyelectromusic](https://github.com/diyelectromusic/sdemp_pcbs/tree/main/PicoVGABreakout).

## Tout en gris

Premier essai du mode RGBY1111 : les bonnes couleurs apparaissent, mais toutes trop sombres. Le blanc éclatant du bas de mire ressort en gris crasseux.

L'enquête tient en trois actes. D'abord, Kevin soupçonne la structure du buffer : sa ligne était un seul gros aplat là où l'exemple officiel découpait chaque ligne en trente-deux morceaux. Il imite le découpage, l'image devient correcte. Puis l'oscilloscope montre quelque chose de plus net : sur la version qui rate, la broche bleue reste constamment haute, là où la version qui marche retombe à zéro, synchronisée avec chaque ligne [2](https://emalliab.wordpress.com/2026/08/01/simplified-pico-vga-part-2/).

Le vrai coupable n'est pas le découpage. C'est le pixel noir qui accompagne ce découpage : la version fonctionnelle termine sa ligne par un token RAW_1P de couleur noire, l'autre non. Et en relisant la documentation, on tombe sur un avertissement en majuscules : il faut terminer chaque ligne par au moins un pixel noir, sinon « vos couleurs débordent dans le blanking » [10](https://github.com/raspberrypi/pico-extras/blob/master/src/common/pico_scanvideo/README.adoc).

Pourquoi ça assombrit tout l'écran ? Là, Kevin avoue ne pas savoir exactement. Un lecteur lui a envoyé une note de Ken Shirriff qui décrit le même symptôme : en oubliant de blanker les zones hors image, son image restait visible mais « très sombre, car le moniteur ne savait plus quelle tension représentait le noir » [14](https://www.righto.com/2018/04/#fn:blanking). L'idée la plus probable : le moniteur utilise le porche de blanking pour calibrer ce que « éteint » veut dire. Si cette zone porte une couleur, toute la référence glisse. Reste une zone d'ombre que Kevin partage volontiers : le mécanisme électrique précis n'est pas démontré dans la série.

## Le noir retrouvé

Troisième version du code, un seul token noir ajouté en fin de ligne : les quinze couleurs tombent justes, brightness comprise [2](https://emalliab.wordpress.com/2026/08/01/simplified-pico-vga-part-2/).

> Montage final
> **Un Spectrum sur VGA, à la main**
> - broches GPIO utilisées: 6
> - couleurs distinctes: 15
> - d'horloge pixel en 640×480: 25 MHz
> Mode RGBY1111 documenté dans la série ; horloge issue des timings de pico-zxspectrum.

Au bout du compte, six broches font l'affaire : quatre fils couleur et les deux synchronisations, puisque Kevin garde VSYNC là où pico-zxspectrum s'en passe [1](https://emalliab.wordpress.com/2026/07/25/simplified-pico-vga/)[2](https://emalliab.wordpress.com/2026/08/01/simplified-pico-vga-part-2/).

Ce que raconte cette série dépasse le plaisir rétro. Un signal vidéo de 1986, conçu pour des téléviseurs analogiques, se négocie encore aujourd'hui en broches, en résistances et en cycles : chaque économie de fil se paie en profondeur de couleur, et un pixel oublié suffit à faire mentir tout l'écran. On peut utiliser `scanvideo` sans rien savoir de tout ça. Mais celui qui a suivi la descente — tokens, DMA, blanking — peut maintenant inventer son propre mode vidéo, pas seulement recopier un `#define`. Kevin, en tout cas, a continué : sa série s'est déjà prolongée en sortie vidéo compatible Spectrum pour l'ordinateur modulaire RC2014.

## References

1. [Kevin, Simplified Pico VGA (partie 1), 25 juillet 2026](https://emalliab.wordpress.com/2026/07/25/simplified-pico-vga/)
2. [Kevin, Simplified Pico VGA – Part 2, 1er août 2026](https://emalliab.wordpress.com/2026/08/01/simplified-pico-vga-part-2/)
3. [Adafruit, Simplified Raspberry Pi Pico VGA, 24 août 2026](https://blog.adafruit.com/2026/08/24/simplified-raspberry-pi-pico-vga/)
4. [Raspberry Pi, exemples ScanVideo et schéma de câblage, pico-playground](https://github.com/raspberrypi/pico-playground/tree/master/scanvideo)
5. [Pimoroni, Pico VGA Demo Base](https://shop.pimoroni.com/products/pimoroni-pico-vga-demo-base)
6. [Miroslav Nemecek, PicoVGA](http://www.breatharian.eu/hw/picovga/index_en.html)
7. [Miroslav Nemecek, DispHSTX (RP2350 / HSTX)](http://www.breatharian.eu/hw/disphstx/index_en.html)
8. [scrapcomputing, MCEBlaster (TTL MDA/CGA/EGA vers VGA)](https://github.com/scrapcomputing/MCEBlaster)
9. [fruit-bat, pico-zxspectrum](https://github.com/fruit-bat/pico-zxspectrum)
10. [Raspberry Pi, README de pico_scanvideo, pico-extras](https://github.com/raspberrypi/pico-extras/blob/master/src/common/pico_scanvideo/README.adoc)
11. [Raspberry Pi, programme PIO video_24mhz_composable_default, scanvideo.pio](https://github.com/raspberrypi/pico-extras/blob/master/src/common/pico_scanvideo/scanvideo.pio)
12. [earlephilhower, core Arduino-Pico](https://github.com/earlephilhower/arduino-pico)
13. [diyelectromusic, PicoVGABreakout (schéma et PCB)](https://github.com/diyelectromusic/sdemp_pcbs/tree/main/PicoVGABreakout)
14. [Ken Shirriff, note sur le blanking, avril 2018](https://www.righto.com/2018/04/#fn:blanking)