DEVLOG 06 :

Aujourd’hui, j’ai continué à réfléchir sérieusement à la conception de ma nouvelle console. Plus j’avance dans le projet, plus il devient concret. Au départ, ce n’était qu’une idée un peu abstraite : créer une console personnelle sur laquelle je pourrais développer mes propres jeux. Mais progressivement, je commence à penser à l’architecture complète du système. Je réfléchis désormais à tous les éléments qui composent réellement une machine de jeu : le processeur, la mémoire, l’écran, les entrées utilisateur, le système audio, le stockage des jeux via des cartouches, mais aussi la manière dont les jeux seront conçus et distribués.

L’un des changements importants dans ma réflexion a été le choix du processeur.

Au départ, j’avais l’habitude de travailler avec l’ESP32, que j’ai déjà utilisé sur plusieurs projets. Mais après avoir comparé différentes architectures, j’ai finalement décidé d’orienter cette console autour du microcontrôleur Raspberry Pi RP2040. Ce choix peut sembler surprenant puisque l’ESP32 est très populaire, mais le RP2040 possède plusieurs avantages pour un projet de console DIY. Il est basé sur deux cœurs ARM Cortex-M0+ pouvant fonctionner jusqu’à 133 MHz et dispose de 264 KB de RAM interne. Pour un microcontrôleur destiné à une console portable, cela représente déjà une base très solide. De plus, l’architecture du RP2040 est particulièrement intéressante grâce à son système de PIO (Programmable Input Output) et à ses nombreux canaux DMA, ce qui permet de gérer des flux de données de manière très efficace, notamment pour l’affichage graphique.

En comparant ce processeur avec ceux utilisés dans d’autres consoles DIY, je me rends compte que mon projet se situe dans une catégorie assez différente. Par exemple, la console Arduboy repose sur un microcontrôleur ATmega32u4 cadencé à 16 MHz avec seulement quelques kilooctets de RAM. Son écran est un petit affichage monochrome de 128×64 pixels. Cette console est volontairement limitée et pousse les développeurs à produire des jeux extrêmement optimisés et minimalistes. Elle est intéressante d’un point de vue pédagogique, mais ses contraintes sont très fortes.

Une autre référence dans le monde des consoles DIY est la Gamebuino META. Cette machine utilise un microcontrôleur ARM Cortex-M0+ cadencé à 48 MHz avec environ 32 KB de RAM et un écran couleur de 160×128 pixels. Elle permet déjà de créer des jeux beaucoup plus riches que l’Arduboy, avec des sprites en couleur, du scrolling et des systèmes de jeu plus complexes. Cependant, elle reste limitée en mémoire et en puissance de calcul. En comparaison, le RP2040 que j’ai choisi offre une fréquence plus élevée, davantage de RAM et surtout une architecture très flexible qui peut faciliter certaines optimisations graphiques.

Pour la partie affichage, j’ai choisi un écran basé sur le contrôleur ST7789 TFT Display Controller, avec une résolution de 240×320 pixels sur une diagonale d’environ deux pouces. Ce choix augmente considérablement la résolution par rapport aux consoles DIY classiques. Cela signifie que je pourrai afficher des sprites plus détaillés, des interfaces plus lisibles et des environnements plus riches visuellement. Cependant, cette résolution plus élevée implique aussi une contrainte importante : le nombre total de pixels à afficher est beaucoup plus grand. L’écran communique avec le microcontrôleur via le protocole SPI, ce qui limite la bande passante disponible pour l’envoi des images. Cela signifie que je devrai optimiser le moteur graphique, par exemple en utilisant des techniques comme le rendu par tuiles, les mises à jour partielles d’écran ou l’utilisation du DMA pour transférer les buffers vers l’écran sans bloquer le processeur.

Un autre aspect central du projet est le système de cartouches. Je veux que la console puisse fonctionner avec différents jeux physiques, ce qui implique de concevoir un format de cartouche simple et économique. Pour les cartouches de base, j’ai choisi d’utiliser une petite mémoire flash AT25EU0021A, qui offre une capacité suffisante pour des jeux relativement compacts. J’ai réussi à en commander cinquante pour environ treize euros, ce qui représente un coût extrêmement faible par unité. Ces cartouches simples pourront être utilisées pour des prototypes, des mini-jeux ou des projets expérimentaux.

En parallèle, je souhaite proposer des cartouches plus avancées pour des jeux plus ambitieux. Pour cela, j’ai choisi une mémoire flash beaucoup plus grande, la W25Q256JV, qui offre environ 32 Mo de stockage. Cette capacité permet d’envisager des jeux beaucoup plus riches : stockage de sprites volumineux, grandes cartes de jeu, musique numérique ou encore systèmes complexes comme la génération procédurale de mondes. Elle ouvre également la possibilité d’intégrer des systèmes de sauvegarde plus élaborés, avec des états de jeu persistants et des mondes évolutifs.

La console elle-même comportera plusieurs éléments matériels qui la rapprochent d’une véritable console portable. Elle disposera de boutons physiques pour les contrôles de jeu, d’un petit haut-parleur d’environ deux watts pour le son, d’une sortie jack pour jouer au casque, de plusieurs LEDs qui pourront servir d’indicateurs ou d’éléments esthétiques, ainsi que d’un potentiomètre rotatif aplati qui pourrait être utilisé pour contrôler le volume ou certaines interactions dans les jeux. L’alimentation et la connexion passeront par un port USB-C, ce qui permettra à la fois la recharge et la communication avec un ordinateur.

En prenant un peu de recul, je réalise que la console que je suis en train de concevoir pourrait être sensiblement plus puissante que certaines consoles DIY existantes. Le RP2040 fonctionne à 133 MHz et dispose de beaucoup plus de mémoire que les microcontrôleurs utilisés dans l’Arduboy ou la Gamebuino META.

Cela signifie que je pourrai potentiellement mettre en place des effets graphiques plus avancés : un plus grand nombre de sprites à l’écran, des systèmes de particules, des couches de scrolling parallaxe ou même certains effets pseudo-3D inspirés des consoles rétro.

En avançant dans ce projet, je découvre également de nombreuses contraintes techniques que je n’avais pas forcément anticipées. Par exemple, la gestion de l’écran via SPI implique de réfléchir sérieusement à la bande passante disponible et à la manière dont les images sont transférées. Des concepts comme le DMA, les buffers graphiques ou les optimisations de rendu deviennent alors essentiels pour maintenir une bonne fluidité dans les jeux.

Pour l’instant, je reste encore dans une phase de conception et d’exploration. Je compare les composants, j’analyse les compromis techniques et j’essaie d’imaginer la manière dont tous ces éléments vont s’assembler dans une carte électronique cohérente. La prochaine étape sera probablement de commencer à dessiner le schéma de la console dans KiCad, puis de concevoir le circuit imprimé qui donnera réellement vie à la machine.

Ce qui me motive le plus dans cette aventure, ce n’est pas seulement l’idée de fabriquer une console. C’est surtout le fait de comprendre en profondeur comment une console fonctionne réellement : comment les données sont stockées, comment les pixels sont envoyés à l’écran, comment le son est généré et comment tout cela peut devenir une plateforme capable d’accueillir des jeux.

Je suis encore loin du résultat final, mais pour la première fois, j’ai réellement l’impression que le projet existe. Chaque composant choisi, chaque problème technique compris et chaque décision d’architecture prise rapprochent un peu plus cette console de la réalité.