Console de jeu portable Pocket Pi SF32¶

Qu'est-ce que Pocket Pi ?¶

SiFliSparks/PocketPi est une référence de console de jeu portable et d'émulateur pour SF32LB52. La révision figée intègre l'émulateur NES Nofrendo, un navigateur de jeux LVGL, une chaîne d'affichage 320 × 240 ST7789 sur bus 8080, l'audio, la sauvegarde et le chargement d'état, un système de fichiers embarqué et un répertoire de ROM sur carte TF. Sa base de compilation publique utilise la cible Huangshan Pi / sf32lb52-lchspi-ulp.

Ce projet permet d'évaluer la coexistence des graphismes locaux, des entrées, de l'audio, du stockage externe, de l'allocation PSRAM et de la charge de l'émulateur sur un système SF32LB52. Le dépôt ne fournit pas de ROM commerciales : les utilisateurs doivent apporter des fichiers .nes ou .NES qu'ils sont autorisés à utiliser. Le code public ne constitue pas non plus une conception complète de console portable prête pour la production et ne remplace pas l'évaluation de la sécurité de la batterie, de l'audio, de la CEM, du comportement thermique, des licences ou de la distribution des contenus.

Pourquoi l'implémentation SF32 ?¶

L'émulation NES réunit plusieurs contraintes embarquées dans un même scénario concret : émulation CPU, graphisme PPU, échantillonnage audio, entrées à faible latence, lecture de fichiers, tampon d'image et sauvegardes doivent fonctionner de concert. Un système basé sur SF32LB52 fournit les ressources d'affichage, audio, stockage externe et PSRAM nécessaires à ce scénario ; Huangshan Pi offre aussi une plateforme d'évaluation alimentée par batterie.

Cela ne signifie pas que tous les jeux NES sont entièrement compatibles. La prise en charge des mappers ROM, la fréquence d'image, l'audio, le comportement des sauvegardes, le pic de mémoire et la latence des entrées peuvent varier d'un jeu à l'autre. Chaque ROM ou mapper ajouté nécessite une vérification spécifique de compatibilité et de droits d'auteur.

Résultat, portée et critères d'entrée¶

Résultat attendu : produire une image reproductible à partir du commit PocketPi figé dans la spécification logicielle, démarrer au moins une ROM de test dont l'utilisation est autorisée, valider l'écran, les entrées, l'audio, la pause, la sauvegarde et le chargement d'état, la sortie et la récupération, puis réaliser une adaptation de portée limitée.

Cette page ne garantit pas la prise en charge de tous les mappers NES, du minutage PAL/NTSC, de la chaîne audio utilisée par chaque jeu, des formats de sauvegarde ou des ROM tierces. Elle n'accorde aucun droit de copie ou de distribution des contenus de jeu. Dans la révision figée, le dépôt ne contient pas de fichier de licence à sa racine ; avant d'intégrer le code à un produit ou de distribuer des binaires, il faut établir les licences de PocketPi, de Nofrendo et de chaque composant tiers intégré.

Avant de commencer, préparez :

• SF32LB52-DevKit-ULP / Huangshan Pi, ou un matériel conforme à la définition de carte sf32lb52-lchspi-ulp du dépôt ;
• l'écran 320 × 240, l'expandeur d'entrées I²C AW9523, les boutons, l'audio et la prise en charge optionnelle de la carte TF attendus par le code source figé. Le nom de la carte ne prouve pas à lui seul que tous les périphériques sont montés ;
• SiFli-SDK, SCons, un outil de flashage par UART et des outils de journalisation ;
• une ROM .nes de test créée par vos soins, appartenant au domaine public ou correctement licenciée ;
• la ROM dans disk/ du dépôt pour le système de fichiers intégré ou dans le répertoire ROM de la carte TF configuré par le firmware. La révision figée recherche les ROM à l'exécution dans /sdcard/roms/nes ; vérifiez dans cette révision que le chemin correspond au point de montage de la carte ;
• un moyen d'observer le comportement des images, l'audio, les entrées, la mémoire et le courant.

Spécifications matérielles et logicielles¶

Spécification matérielle¶

Spécification logicielle¶

Choisir une configuration de référence prise en charge¶

Utilisez la révision PocketPi figée dans la spécification logicielle, plutôt que de compiler le commit qui se trouve actuellement en tête de main :

git clone https://github.com/SiFliSparks/PocketPi.git
cd PocketPi
git checkout 7d9fac2cb577d6c9b66a99521aebf3c9de0ae163
cd project
scons --board=sf32lb52-lchspi-ulp -j8

Le script de compilation transforme ../disk en image de système de fichiers et l'intègre au firmware sous le nom fs_root. Sous Windows, le fichier généré build_sf32lb52-lchspi-ulp_hcpu\uart_download.bat fournit la procédure de flashage. Sur les autres systèmes, utilisez l'outil de flashage SiFli-SDK correspondant et consignez les paramètres équivalents.

Étapes du projet¶

Architecture système et dépendances¶

flowchart LR
    B["Entrée de compilation\nROM NES dont l'utilisation est autorisée dans disk/"] --> F["Image du système de fichiers fs_root"]
    C["Carte TF\n/sdcard/roms/nes"] --> L["Navigateur de jeux LVGL"]
    F --> L
    L --> N["Émulateur NES Nofrendo\nCPU, PPU, mappers, état"]
    I["Touches I²C AW9523\nA/B, directions, Start, Select, Menu, L/R"] --> N
    N --> V["Écran 320 × 240 ST7789"]
    N --> A["Voie audio 32 kHz"]
    N <--> S["Enregistrer / charger l'état"]
    D["SiFli-SDK et prise en charge de la carte\nPSRAM, Flash, carte TF, batterie"] --> L
    D --> N

Les principaux domaines de panne sont le système de fichiers/ROM, le mapper/émulateur, la PSRAM/mémoire, l'écran et le minutage des images, les entrées AW9523, l'audio, les sauvegardes et l'alimentation/reset. Face à un écran noir, déterminez d'abord si la ROM n'a pas été détectée, si la jaquette n'a pas été décodée, si le mapper n'est pas pris en charge, si l'allocation du framebuffer a échoué ou si la voie LCD est en panne ; ne signalez pas simplement une « panne de l'émulateur ».

Étape 1 — Établir la référence de jeu intacte¶

Objectif : utiliser une ROM de test dont l'utilisation est autorisée pour vérifier tout le chemin, de l'entrée de compilation au jeu en cours d'exécution.

1. Verrouillez les commits de PocketPi et de SiFli-SDK, ainsi que les révisions de la carte et des périphériques.
2. Placez une ROM .nes autorisée dans disk/ ; si vous ajoutez une jaquette, utilisez un fichier .jpg de même nom. Conservez l'empreinte, la provenance et le mapper de la ROM.
3. Effectuez une compilation propre et vérifiez que fs_root est généré et inclus dans les artefacts destinés au flashage.
4. Flashez le firmware, puis démarrez à froid. Vérifiez que le jeu apparaît dans la liste, que sa jaquette ou l'image par défaut s'affiche et que le jeu se lance.
5. Consignez le temps de démarrage, la stabilité vidéo, la réponse des touches, l'audio et les journaux série ; réinitialisez ensuite et recommencez.

Éléments à conserver : commits du dépôt et du SDK, carte et périphériques, empreinte/licence de la ROM, journal de compilation, image du système de fichiers, journaux de flashage et série, photos de la liste et du jeu en cours d'exécution.

Critère de sortie du point de contrôle 1 : deux démarrages à froid affichent et exécutent la même ROM ; l'écran, les directions/A/B/Start/Select de base et l'audio se comportent de manière reproductible.

Étape 2 — Valider l'entrée, l'état et la récupération après erreur¶

Objectif : transformer « le jeu démarre » en une base de console portable vérifiable.

Critère de sortie du point de contrôle 2 : entrées, écran, audio, pause, sauvegarde, chargement, sortie et reset sont documentés pour la ROM sélectionnée ; chaque panne est rattachée à un domaine défini.

Étape 3 — Établir une base reproductible pour le code source et le contenu¶

Objectif : permettre à un autre ingénieur de reconstruire le même firmware et la même image de contenu.

1. Consignez les révisions de PocketPi, de SiFli-SDK et de tout cœur tiers.
2. Créez un manifeste disk/ indiquant les noms de fichiers, empreintes, provenances et licences de chaque ROM et jaquette. Ne versionnez pas les ROM que vous n'êtes pas autorisé à redistribuer.
3. Compilez depuis un répertoire de sortie vide et conservez fs_root, le firmware, les sorties mémoire/partition, le script de flashage et les empreintes.
4. Recompilez sur un second ordinateur ou dans un répertoire propre et répétez les principaux tests de l'étape 2.

Critère de sortie du point de contrôle 3 : les manifestes des sources et contenus permettent de reproduire une image aux empreintes identiques ou aux différences expliquées, sans fichier local non documenté.

Étape 4 — Adapter une variable à la fois¶

Objectif : mesurer les limites de l'émulateur, du contenu et du matériel.

Critère de sortie du point de contrôle 4 : la modification et les droits sur le contenu sont vérifiés, l'image d'origine peut être restaurée et tous les tests de l'étape 2 pour la ROM sélectionnée réussissent.

Étape 5 — Revue de préparation produit¶

Avant de concevoir un matériel portable spécifique ou de distribuer du contenu, répondez aux questions suivantes :

• Quels mappers sont requis par les jeux visés, et la fréquence d'image, l'audio, la mémoire et les sauvegardes de chaque ROM ont-ils été qualifiés ?
• Les licences et droits de distribution de PocketPi, Nofrendo, SiFli-SDK, des polices, jaquettes, sons et ROM sont-ils clairs ?
• Les circuits AW9523, LCD et audio, la carte TF, la batterie et le chargeur disposent-ils de schémas complets, d'une nomenclature et de tests de production ?
• Quels sont le courant en jeu, dans la liste, en pause, en veille et à l'arrêt, l'autonomie, la température et le comportement de batterie faible ?
• Comment les sauvegardes sont-elles protégées et migrées après une coupure, une mise à jour de version, un support plein ou une corruption ?
• Comment l'appareil récupère-t-il après un système de fichiers endommagé, une mise à jour échouée, un écran noir ou une ROM impossible à démarrer ?

Critère de sortie du point de contrôle 5 : la matrice de compatibilité, les licences logicielles et de contenu, la responsabilité matérielle, l'alimentation et les risques de récupération ont des responsables désignés et font l'objet d'une décision de poursuivre, différer ou arrêter.

Passage à la conception du produit¶

Transférez vers la suite de la conception le choix du composant ou du module SF32, les pics d'utilisation de PSRAM et de Flash, l'architecture d'affichage et du framebuffer, la matrice d'entrées AW9523, l'amplificateur et le haut-parleur, la carte TF et le système de fichiers intégré, le format des états sauvegardés, la batterie et son circuit de recharge, le port de flashage et de récupération, la matrice de compatibilité ROM/mapper et le manifeste complet des licences. Consultez SF32LB52x, SF32LB52-DevKit-ULP, SiFli-SDK : compiler, flasher et surveiller la sortie série et Conception pour la production.

Sources de référence¶

• SiFliSparks/PocketPi
• Commit de référence verrouillé 7d9fac2
• Carte LCKFB Huangshan Pi SF32LB52-ULP
• OpenSiFli/SiFli-SDK
• Wiki SiFli : guide de la carte de développement Huangshan Pi
• Guide de démarrage SiFli-SDK
• pebri86/esplay-retro-emulation
• Documentation LVGL

Dernière mise à jour: 2026-10-21