Pocket Pi SF32 Handheld-Spielkonsole¶

Was ist Pocket Pi?¶

SiFliSparks/PocketPi ist eine Referenz für eine tragbare Spielkonsole und einen Emulator auf SF32LB52-Basis. Der fixierte Quellstand integriert den Nofrendo-NES-Emulator, einen LVGL-Spielebrowser, einen 320 × 240 großen ST7789-Displaypfad mit 8080-Schnittstelle, Audio, Speichern und Laden von Spielständen, ein eingebettetes Dateisystem sowie ein ROM-Verzeichnis auf TF-Karte. Die öffentliche Build-Basis verwendet das Ziel Huangshan Pi / sf32lb52-lchspi-ulp.

Das Projekt eignet sich, um das Zusammenspiel lokaler Grafiken, Eingaben, Audio, externem Speicher, PSRAM-Belegung und Emulatorlast auf einem SF32LB52-System zu prüfen. Das Repository enthält keine kommerziellen Spiel-ROMs; Nutzer müssen .nes- oder .NES-Dateien bereitstellen, zu deren Verwendung sie berechtigt sind. Der öffentliche Quellcode ist außerdem kein vollständiges Design für eine serienreife Handheld-Konsole und ersetzt keine Prüfung von Akkusicherheit, Audio, EMV, Temperaturverhalten, Lizenzen oder Inhaltsweitergabe.

Warum die SF32-Implementierung?¶

Die NES-Emulation bündelt mehrere typische Anforderungen eingebetteter Systeme in einem anschaulichen Testfall: CPU-Emulation, PPU-Grafik, Audioabtastung, Eingaben mit geringer Latenz, Dateizugriffe, Framebuffer und gespeicherte Spielstände müssen zusammenspielen. Ein System auf Basis des SF32LB52 stellt die dafür nötigen Anzeige-, Audio-, externen Speicher- und PSRAM-Ressourcen bereit; Huangshan Pi bietet zudem eine akkubetriebene Evaluierungsplattform.

Der Nutzen liegt nicht in der Behauptung, dass jeder NES-Titel vollständig kompatibel ist. Unterstützung für ROM-Mapper, Bildrate, Audio, Speicherverhalten, Spitzenbedarf an Arbeitsspeicher und Eingabelatenz können je nach Spiel variieren. Für jedes zusätzliche ROM und jeden Mapper sind Kompatibilität und Urheberrechte gesondert zu prüfen.

Ergebnis, Umfang und Eintrittskriterien¶

Ergebnis: Aus dem in der Softwarespezifikation fixierten PocketPi-Commit ein reproduzierbares Image erstellen, mindestens ein rechtmäßig nutzbares Test-ROM starten, Display, Eingaben, Audio, Pause, Speichern, Laden, Beenden und Wiederherstellung prüfen und anschließend eine klar begrenzte Anpassung umsetzen.

Diese Seite garantiert weder die Unterstützung aller NES-Mapper noch PAL-/NTSC-Timing noch Audioverhalten in jedem Spiel noch ein bestimmtes Speicherformat noch die Funktion beliebiger ROMs Dritter. Sie gewährt keine Rechte zum Kopieren oder Verbreiten von Spielinhalten. Das Repository enthält in der fixierten Revision keine Lizenzdatei auf oberster Ebene. Vor der Übernahme von Code in ein Produkt oder der Verteilung von Binärdateien muss ein Verantwortlicher klären, welche Lizenzen für PocketPi, Nofrendo und sämtliche integrierten Komponenten Dritter gelten.

Halten Sie vor dem Start Folgendes bereit:

• SF32LB52-DevKit-ULP / Huangshan Pi oder Hardware, die zur Boarddefinition sf32lb52-lchspi-ulp des Repositorys passt;
• das vom fixierten Quellstand erwartete 320 × 240 Display, den AW9523-I²C-Eingabeexpander, Tasten, Audio und optional den TF-Kartenpfad. Der Boardname allein belegt nicht, dass alle Peripheriegeräte bestückt sind;
• SiFli-SDK, SCons sowie Werkzeuge zum Flashen per UART und zur Protokollierung;
• ein selbst erstelltes, gemeinfreies oder ordnungsgemäß lizenziertes .nes-Test-ROM;
• das ROM im Verzeichnis disk/ des Repositorys für das integrierte Dateisystem oder im von der Firmware konfigurierten ROM-Verzeichnis auf der TF-Karte. Der fixierte Quellstand durchsucht zur Laufzeit /sdcard/roms/nes; prüfen Sie anhand dieser Revision, ob der Einhängepfad der Karte dazu passt;
• eine Möglichkeit, Frameverhalten, Audio, Eingaben, Speicherbedarf und Stromaufnahme zu beobachten.

Hardware- und Software-Spezifikationen¶

Hardware-Spezifikation¶

Software-Spezifikation¶

Unterstützte Referenzkonfiguration auswählen¶

Verwenden Sie die in der Softwarespezifikation fixierte PocketPi-Revision, statt den Commit zu bauen, auf den main gerade verweist:

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

Das Build-Skript wandelt ../disk in ein Dateisystemimage um und bindet es als fs_root in die Firmware ein. Unter Windows enthält die erzeugte Datei build_sf32lb52-lchspi-ulp_hcpu\uart_download.bat den Ablauf zum Flashen. Auf anderen Hostsystemen sollte das entsprechende SiFli-SDK-Flashwerkzeug verwendet werden; dokumentieren Sie dabei gleichwertige Parameter.

Projektphasen und Entscheidungspunkte¶

Systemarchitektur und Abhängigkeiten¶

flowchart LR
    B["Build-Eingabe\nrechtmäßig nutzbare NES-ROMs unter disk/"] --> F["Dateisystemimage fs_root"]
    C["TF-Karte\n/sdcard/roms/nes"] --> L["LVGL-Spielebrowser"]
    F --> L
    L --> N["Nofrendo-NES-Emulator\nCPU, PPU, Mapper, Spielzustand"]
    I["AW9523-I²C-Tasten\nA/B, Richtung, Start, Select, Menu, L/R"] --> N
    N --> V["320 × 240 ST7789-Display"]
    N --> A["32-kHz-Audiopfad"]
    N <--> S["Spielstand speichern / laden"]
    D["SiFli-SDK und Boardunterstützung\nPSRAM, Flash, TF-Karte, Akku"] --> L
    D --> N

Die wichtigsten Fehlerbereiche sind Dateisystem/ROM, Mapper/Emulator, PSRAM/Speicher, Display/Frame-Timing, AW9523-Eingabe, Audio, Spielstand sowie Stromversorgung/Reset. Bei einem schwarzen Bildschirm ist zunächst zu unterscheiden, ob das ROM nicht gefunden wurde, die Bilddatei nicht dekodiert werden konnte, der Mapper nicht unterstützt wird, die Framebuffer-Zuweisung fehlgeschlagen ist oder der LCD-Pfad nicht funktioniert. Melden Sie dies nicht pauschal als Emulatorfehler.

Phase 1 — Die unveränderte Spielbasis einrichten¶

Ziel: Mit einem rechtmäßig nutzbaren Test-ROM den vollständigen Pfad von der Build-Eingabe bis zum laufenden Spiel prüfen.

1. Fixieren Sie die PocketPi- und SiFli-SDK-Commits sowie die Revisionen von Board und Peripheriegeräten.
2. Legen Sie ein rechtmäßig nutzbares .nes-ROM unter disk/ ab. Falls Sie ein Titelbild verwenden, muss es ein gleichnamiges .jpg sein. Sichern Sie Hash, Herkunft und Mapper des ROMs.
3. Führen Sie einen sauberen Build aus und prüfen Sie, ob fs_root erzeugt und in die zum Flashen bestimmten Artefakte eingebunden wird.
4. Flashen Sie die Firmware und führen Sie einen Kaltstart durch. Prüfen Sie, ob das Spiel in der Liste erscheint, Titelbild oder Standardbild angezeigt wird und sich das Spiel starten lässt.
5. Dokumentieren Sie Startzeit, stabiles Bild, Tastenreaktion, Audio und serielle Protokolle. Setzen Sie das Gerät zurück und wiederholen Sie den Test.

Aufzubewahrende Nachweise: Repository- und SDK-Commits, Board und Peripheriegeräte, ROM-Hash und Lizenz, Build-Protokoll, Dateisystemimage, Flash- und serielle Protokolle sowie Fotos der Spieleliste und des laufenden Spiels.

Abnahmekriterium für Kontrollpunkt 1: Bei zwei Kaltstarts wird dasselbe ROM aufgelistet und ausgeführt; Display, grundlegende Richtungstasten/A/B/Start/Select und Audio verhalten sich reproduzierbar.

Phase 2 — Eingabe, Zustand und Fehlerwiederherstellung validieren¶

Ziel: Aus „das Spiel startet“ eine überprüfbare Handheld-Basis machen.

Abnahmekriterium für Kontrollpunkt 2: Eingabe, Display, Audio, Pause, Speichern, Laden, Beenden und Reset sind für das ausgewählte ROM dokumentiert; jeder Fehler ist einem definierten Bereich zugeordnet.

Phase 3 — Eine reproduzierbare Quell- und Inhaltsbasis erstellen¶

Ziel: Einem anderen Entwickler ermöglichen, dasselbe Firmware- und Inhaltsimage erneut zu erstellen.

1. Notieren Sie die Revisionen von PocketPi, SiFli-SDK und allen Cores von Drittanbietern.
2. Erstellen Sie für disk/ ein Manifest mit Dateinamen, Hashes, Herkunft und Lizenzen aller ROMs und Titelbilder. Committen Sie keine ROMs, die Sie nicht weitergeben dürfen.
3. Bauen Sie in einem leeren Ausgabeverzeichnis und sichern Sie fs_root, Firmware, Speicher-/Partitionsausgaben, Flashskript und Hashes.
4. Wiederholen Sie den Build auf einem zweiten Rechner oder in einem sauberen Verzeichnis und führen Sie die wichtigsten Tests aus Phase 2 erneut aus.

Abnahmekriterium für Kontrollpunkt 3: Quell- und Inhaltsmanifeste erzeugen ein Image mit übereinstimmenden Hashes oder dokumentierten Abweichungen – ohne undokumentierte lokale Dateien.

Phase 4 — Jeweils eine Variable anpassen¶

Ziel: Die Grenzen von Emulator, Inhalten und Hardware vermessen.

Abnahmekriterium für Kontrollpunkt 4: Änderung und Inhaltsrechte sind geprüft, das ursprüngliche Image ist wiederherstellbar und alle Phase-2-Tests für das ausgewählte ROM sind bestanden.

Phase 5 — Produktreife-Überprüfung¶

Klären Sie vor der Entwicklung kundenspezifischer Handheld-Hardware oder der Verteilung von Inhalten folgende Punkte:

• Welche Mapper benötigt die vorgesehene Spielesammlung, und wurden Bildrate, Audio, Speicherbedarf und Speicherverhalten jedes ROMs qualifiziert?
• Sind Lizenzen und Vertriebsrechte für PocketPi, Nofrendo, SiFli-SDK, Schriftarten, Titelbilder, Audiodateien und ROMs geklärt?
• Gibt es vollständige Schaltpläne, Stücklisten und Produktionstests für AW9523, LCD, Audio, TF-Karte, Akku und Ladeschaltung?
• Wie hoch sind Stromaufnahme im Spiel, in der Liste, Pause, im Schlaf und im ausgeschalteten Zustand sowie Akkulaufzeit, Temperatur und Verhalten bei niedrigem Akkustand?
• Wie werden Spielstände nach Stromausfall, Versionsupdate, vollem Speicher oder Datenbeschädigung geschützt und migriert?
• Wie lässt sich das Gerät nach beschädigtem Dateisystem, fehlgeschlagenem Update, schwarzem Bildschirm oder nicht startendem ROM wiederherstellen?

Abnahmekriterium für Kontrollpunkt 5: Für Kompatibilitätsmatrix, Inhalts- und Softwarelizenzen, Hardwareverantwortung, Stromversorgung und Wiederherstellungsrisiken sind Zuständige benannt und eine Entscheidung zum Fortfahren, Zurückstellen oder Abbrechen getroffen.

Übergabe an das Produktdesign¶

Übernehmen Sie die Auswahl des SF32-Geräts oder -Moduls, den Spitzenbedarf an PSRAM und Flash, den Display-/Framebufferpfad, die AW9523-Tastenmatrix, Audioverstärker und Lautsprecher, TF-Karte und integriertes Dateisystem, das Spielstandsformat, Akku und Ladeschaltung, den Flash- und Wiederherstellungsanschluss, die ROM-/Mapper-Kompatibilitätsmatrix sowie das vollständige Lizenzmanifest in die nächste Designphase. Fahren Sie mit SF32LB52x, SF32LB52-DevKit-ULP, SiFli-SDK: Bauen, Flashen und Überwachen und Design für die Produktion fort.

Maßgebliche Quellen¶

• SiFliSparks/PocketPi
• Fixierter Referenz-Commit 7d9fac2
• LCKFB Huangshan Pi SF32LB52-ULP-Board
• OpenSiFli/SiFli-SDK
• SiFli Wiki: Leitfaden zum Huangshan-Pi-Entwicklungsboard
• SiFli-SDK – Getting Started Guide
• pebri86/esplay-retro-emulation
• LVGL-Dokumentation

Zuletzt aktualisiert: 2026-10-21