12 points par GN⁺ 2025-02-14 | 3 commentaires | Partager sur WhatsApp
  • Game Bub est une console portable d’émulation rétro open source basée sur un FPGA, compatible avec les jeux "Game Boy, Game Boy Color, Game Boy Advance"
  • Elle peut utiliser des cartouches physiques, et peut aussi lancer des jeux émulés à partir de fichiers ROM stockés sur une carte microSD
  • Il n’existait jusqu’ici aucun émulateur FPGA open source capable de lire de vraies cartouches, et l’un des objectifs principaux était de tout réaliser soi-même et de comprendre tous les composants
  • Le créateur a donc conçu lui-même le PCB, écrit le firmware, développé des émulateurs Game Boy et Game Boy Advance pour FPGA (avec Chisel HDL) et dessiné un boîtier imprimé en 3D
  • Le câble Game Link est pris en charge, ce qui permet aussi le multijoueur en mode GB et GBA
  • L’appareil inclut des fonctions comme la sortie HDMI (via un dock), un moteur de vibration, une horloge temps réel, et a été conçu pour pouvoir être étendu via de futures mises à jour logicielles
  • Il repose sur un PCB à 6 couches embarquant un FPGA Xilinx XC7A100T, intégré dans un boîtier personnalisé imprimé en 3D

Objectifs du projet

  • Créer une console portable FPGA autonome avec batterie rechargeable
  • Minimiser le coût et la complexité, et utiliser autant que possible des composants du commerce
  • Pouvoir exécuter des jeux Game Boy / Game Boy Color / Game Boy Advance
  • Prendre en charge les cartouches physiques et les fichiers ROM sur carte microSD
  • Proposer une interface intuitive et un overlay en jeu
  • Intégrer écran, haut-parleur et sortie casque
  • Prendre en charge la sortie HDMI
  • Prévoir les possibilités d’extension futures (prise en charge d’autres systèmes, Wi-Fi, etc.)
  • Développer en interne les cœurs d’émulation FPGA, et concevoir aussi le matériel et les pilotes afin de comprendre complètement le système

Vision du rétro gaming sur FPGA

  • L’affirmation selon laquelle « le gaming sur FPGA est plus précis que l’émulation logicielle » relève d’un marketing exagéré
  • Un FPGA reste lui aussi un émulateur, dont la précision dépend de la manière dont il a été programmé
  • Les émulateurs logiciels peuvent également atteindre un très haut niveau de précision et offrent une excellente accessibilité
  • Le principal avantage des émulateurs sur FPGA est leur facilité de connexion avec du matériel physique (cartouches, câble link, etc.)

Aperçu de la conception matérielle

  • Architecture FPGA + microcontrôleur (MCU) : le FPGA gère l’émulation principale, tandis que le MCU s’occupe de l’interface, du chargement des ROM, de la gestion de l’alimentation, etc.
  • Prise en charge Wi-Fi et Bluetooth : utilisation d’un module ESP32-S3 (sans support de Bluetooth Classic toutefois)
  • Écran : LCD 320x480 de 3,5 pouces (avec possibilité d’agrandissement x2 de l’image du jeu)
  • Batterie et gestion de l’alimentation : batterie lithium-ion, circuit de charge TI BQ2407x, avec jauge de batterie MAX17048 pour surveiller l’état énergétique
  • Audio : codec audio TLV320DAC3101 avec sortie stéréo et réglage numérique du volume
  • Entrées : boutons à clic issus de la GBA SP pour offrir un bon ressenti
  • Mémoire : 32 Mo de SDRAM pour stocker les ROM émulées
  • Port cartouche et port link : connexion directe de cartouches physiques, avec détection du basculement GBA/GBC
  • Autres fonctions : IMU (capteur de mouvement), horloge temps réel (RTC), moteur de vibration

Conception du PCB et tests

  • Le PCB a été conçu avec KiCad
  • Le FPGA (Artix-7) utilise un boîtier BGA, ce qui a conduit à un PCB à 6 couches
  • Les tests du premier prototype ont montré que la plupart des fonctions marchaient correctement, avec quelques problèmes de gestion de l’alimentation
  • Les premiers tests ont été effectués avec MicroPython, puis le firmware du MCU a été écrit en Rust

Développement de l’interface graphique et du firmware

  • Une interface Rust a été développée avec le framework UI Slint
  • La vitesse de mise à jour du LCD a été optimisée, et le système a été conçu pour que le FPGA pilote directement l’écran plutôt que le MCU
  • Une fonction de transfert de données via TinyUSB a été ajoutée pour que la microSD puisse être reconnue comme un périphérique USB Mass Storage

Ajout du support Game Boy Advance

  • Implémentation du CPU ARM7TDMI (architecture pipeline à 3 étages)
  • Implémentation directe sur FPGA des composants matériels GBA tels que le PPU, le DMA, les timers et l’audio
  • Analyse du protocole de bus spécifique de la GBA et reproduction sur FPGA afin de prendre en charge les cartouches physiques
  • Prise en charge du multijoueur GBA-GBA via câble link ainsi que de la connexion à la GameCube

Deuxième révision matérielle

  • Refonte du circuit et du boîtier pour adopter un design plus fin et plus ergonomique
  • Ajustement de la position des boutons pour retrouver des sensations proches de la GBA SP
  • Suppression du port HDMI, et conception d’un dock personnalisé basé sur USB-C pour ajouter la sortie HDMI et le support des manettes
  • Fabrication sur mesure de la vitre de protection de l’écran LCD pour un design plus haut de gamme

Conception du dock et sortie HDMI

  • Le dock a été conçu pour émettre un signal HDMI personnalisé via le port USB-C
  • Utilisation d’un MCU basé sur Raspberry Pi Pico W pour permettre la prise en charge de manettes sans fil
  • Le dock fournit une fonction de hub USB, permettant aussi de connecter des manettes filaires

Plans futurs et possibilités d’extension

  • Finaliser le dock et ajouter la prise en charge des manettes Bluetooth
  • Améliorer encore la précision de l’émulateur Game Boy Advance avec pour objectif de passer les tests mGBA
  • Rechercher une émulation sans fil du câble link (implémentation de l’adaptateur GBA Wireless basée sur le Wi-Fi)
  • Étudier la prise en charge de fonctions supplémentaires comme la communication IR Game Boy, le capteur solaire de Boktai ou la Game Boy Camera

Liste de souhaits pour une éventuelle production en volume

  • Dalle LCD personnalisée en 720x480 (permettant un agrandissement x3 pour la GBA)
  • Boîtier injecté et boutons de haute qualité
  • Batterie personnalisée (optimisation de l’espace interne)
  • Utilisation de SRAM et SDRAM en BGA (pour permettre un PCB plus compact)

Open source et ressources de référence

  • Code source et schémas du projet : GitHub
  • Documentation matérielle Game Boy et GBA : Pan Docs, GBATEK
  • Outils open source : KiCad, FreeCAD, Chisel, Verilator, Slint, etc.

En résumé

  • Game Bub n’est pas juste une simple console rétro, mais un projet ambitieux qui repousse les possibilités de l’émulation sur FPGA
  • Le projet prévoit d’ajouter diverses fonctions d’extension à l’avenir et d’évoluer avec la communauté open source

3 commentaires

 
blurblah 2025-02-17

Il existait aussi des modèles fabriqués artisanalement en FPGA que seuls les initiés s’échangeaient ou vendaient entre eux, mais je ne savais pas qu’il y en avait aussi en open source. C’est amusant.

 
botplaysdice 2025-02-15

Ils ont même implémenté directement le CPU sur FPGA ! Je me demandais combien de lignes de code ça représentait, alors je suis allé voir... Apparemment, on peut coder un FPGA en Scala, pas seulement en Verilog. J’ai été surpris que ce soit plus simple que je ne l’imaginais.

https://github.com/elipsitz/gamebub/…

Comme on dit, parmi les passionnés, les plus passionnés sont souvent les Occidentaux... haha

 
GN⁺ 2025-02-14
Avis Hacker News
  • C’est un projet vraiment génial. J’ai aimé le fait que l’article de blog soit rédigé de manière très approfondie. Je me demandais s’il pouvait être connecté à une GameCube, et c’était déjà mentionné dans le blog

    • L’un des avantages de la compatibilité avec les cartouches réelles est qu’il n’y a pas besoin de se préoccuper des memory mappers. Je connais les différents mappers de la NES, mais je ne sais pas vraiment si les cartouches GB fonctionnent de la même manière. Du matériel spécial comme la caméra, le vibreur ou la machine à coudre semble aussi pouvoir fonctionner avec les cartouches d’origine sans support particulier
    • Je me demande si, s’il prend en charge le chargement de ROM, il faut alors émuler tous les mappers dans le FPGA
  • Merci pour ce super projet et pour la rédaction de l’article. J’adore ce genre de choses

    • J’avais été déçu, la fois précédente en lisant les commentaires, de voir beaucoup de réactions du type « pourquoi une chose pareille existe ? ». La plupart des gens n’ont jamais essayé ne serait-ce que 1 % d’un projet aussi ambitieux. Ce projet est cool et constitue une expérience d’apprentissage amusante
    • Je l’ai soumis à la tip line de Hack-A-Day, donc un article à ce sujet pourrait paraître dans quelques jours
  • J’ai un Analogue Pocket, mais le fait qu’il utilise un FPGA n’a pas vraiment beaucoup de sens pour moi. Je me demande s’il y a réellement une grande différence par rapport à l’émulation logicielle

    • Je connais la différence entre les deux approches, mais je ne comprends pas pourquoi l’émulation logicielle ne serait pas aussi bonne que l’émulation sur FPGA. La solution logicielle semble plus flexible
  • Je me demande quel est le coût total du PCB avec tous les composants montés. J’imagine que ça doit tourner autour de 60 à 70

    • Merci pour l’article de blog et sa rédaction ; ce serait bien de l’inclure dans le dépôt
    • J’essaie un design similaire et je prévois d’utiliser un RP2350B et un ESP32-C61 comme contrôleurs système. Ce serait bien d’avoir une puce et un layout de pads prenant en charge le BT legacy
    • Ajouter un port USB pour prendre en charge quelque chose comme l’adaptateur sans fil USB 8bitdo est aussi une option. La prise en charge du BT legacy pourrait devenir un travail annexe qui fait dérailler le projet. Une autre possibilité serait d’exposer la connexion SPI en interne pour permettre de bidouiller le contrôleur de son choix
  • J’aime l’open source hardware, mais je me demande ce qu’il se passe quand des composants ne sont plus produits

    • Le mainteneur peut mettre à jour la nomenclature, mais il peut alors falloir plusieurs composants à cause de problèmes de compatibilité. Si, au moment d’acheter les pièces, elles deviennent toutes introuvables, que faut-il faire ? Une possibilité serait que le mainteneur vende des kits de composants. Mais il pourrait y avoir des problèmes liés au droit de la propriété intellectuelle
  • Le problème de MISO avec le contrôleur d’affichage est tristement célèbre. Je l’ai découvert pour la première fois il y a quelques années. Il est recommandé d’utiliser un buffer tri-state sur la ligne de chip select ou de séparer le bus

    • Les problèmes de domaines d’alimentation arrivent aussi souvent. Sur la plupart des appareils, les E/S se composent de Vdd, d’une diode ESD, de la broche d’E/S, d’une diode ESD et de la masse. Si Vdd a un chemin résistif vers la masse, cela pose problème. Cela se produit quand la puce d’alimentation autorise un courant vers la masse via une résistance de décharge en sortie ou un transistor. Dans ce cas, la broche d’E/S se retrouve avec une diode en parallèle vers la masse. Si l’on n’y prend pas garde, le courant maximal que le driver peut fournir passera par cette diode
  • Je n’ai aucune expérience en matériel, donc c’est peut-être une réflexion idiote, mais les anciens systèmes comme la NES, la SNES ou la Genesis sont relativement simples. Les brevets ont aussi une durée de vie limitée. Je me demande pourquoi il n’existe pas de recréation matérielle via SoC capable d’émuler ces systèmes presque parfaitement. Les projets FPGA semblent être ce qui s’en rapproche le plus, mais les FPGA paraissent chers par rapport à des CPU vieux de 40 ans et à 1 kb de RAM

  • Super projet. Le fait que l’UI soit construite avec Rust et Slint est vraiment cool. C’est le framework GUI sur lequel je travaille

  • Fantastique. Je ne sais pas s’il a expliqué pourquoi il a choisi un format vertical. Dans l’écosystème FPGA existant, tout le monde est plutôt sur un style GBC. Je me demande si c’est juste une préférence personnelle ou s’il y a une autre raison

  • Excellent article. Je ne m’intéresse pas particulièrement aux consoles portables de jeu, mais je suis toujours curieux des choix de conception actuels concernant l’affichage, le boîtier, l’alimentation sur batterie et la connectivité. L’intégration du Pico W est appréciable. C’est l’un des éléments de développement les plus sous-estimés de ces dernières années. Merci du partage