Pocket Pi SF32 휴대용 게임기¶

Pocket Pi란 무엇인가?¶

SiFliSparks/PocketPi는 SF32LB52용 휴대용 게임기 및 에뮬레이터 레퍼런스입니다. 고정된 리비전에서 이 프로젝트는 Nofrendo NES 에뮬레이터, LVGL 게임 브라우저, 320 × 240 ST7789 8080 디스플레이 경로, 오디오, 세이브/로드 스테이트, 내장 파일 시스템, TF 카드 ROM 디렉터리를 통합합니다. 공개된 빌드 기준 구성은 Huangshan Pi / sf32lb52-lchspi-ulp 타깃을 사용합니다.

SF32LB52 시스템에서 로컬 그래픽, 입력, 오디오, 외부 스토리지, PSRAM 할당, 에뮬레이터 부하가 어떻게 공존하는지 테스트하는 데 유용합니다. 저장소에는 상용 게임 ROM이 포함되어 있지 않으며, 사용자는 사용 권한이 있는 .nes/.NES 파일을 직접 준비해야 합니다. 또한 공개된 소스는 완전한 양산용 휴대용 게임기 설계가 아니며, 배터리 안전, 오디오, EMC, 열, 라이선스, 콘텐츠 배포에 대한 검토를 대체하지 않습니다.

왜 SF32 구현인가?¶

NES 에뮬레이션은 CPU 에뮬레이션, PPU 그래픽, 오디오 샘플링, 저지연 입력, 파일 읽기, 프레임 버퍼링, 세이브 스테이트가 함께 동작해야 하므로, 여러 임베디드 시스템의 경계를 직관적인 하나의 워크로드로 모아 놓습니다. SF32LB52 기반 시스템은 이 워크로드에 필요한 디스플레이, 오디오, 외부 스토리지, PSRAM 리소스를 함께 갖추고 있으며, Huangshan Pi는 배터리로 구동하는 평가 플랫폼도 제공합니다.

가치는 모든 NES 타이틀이 완전히 호환된다고 주장하는 데 있지 않습니다. ROM 매퍼 지원, 프레임 레이트, 오디오, 세이브 동작, 최대 메모리 사용량, 입력 지연 시간은 게임마다 다를 수 있습니다. ROM이나 매퍼를 추가할 때마다 호환성과 저작권에 대한 별도의 결정이 필요합니다.

목표, 범위, 시작 조건¶

목표: 소프트웨어 사양에 고정된 PocketPi 커밋에서 반복 가능한 이미지를 빌드하고, 사용이 허가된 테스트 ROM을 하나 이상 부팅하고, 디스플레이, 입력, 오디오, 일시 정지, 저장, 로드, 종료, 복구를 검증한 다음, 범위가 제한된 적용 하나를 완료합니다.

이 페이지는 모든 NES 매퍼, PAL/NTSC 타이밍, 게임 오디오 경로, 세이브 형식, 서드파티 ROM을 보장하지 않습니다. 게임 콘텐츠를 복사하거나 배포할 권리도 부여하지 않습니다. 고정된 저장소 리비전에는 최상위 라이선스 파일이 없습니다. 코드를 제품에 복사하거나 바이너리를 배포하기 전에, 담당자가 PocketPi, Nofrendo, 포함된 모든 서드파티 구성 요소의 라이선스를 확정해야 합니다.

시작하기 전에 다음을 준비하십시오.

• SF32LB52-DevKit-ULP / Huangshan Pi 또는 저장소의 sf32lb52-lchspi-ulp 보드 정의와 일치하는 하드웨어;
• 고정된 소스가 기대하는 320 × 240 디스플레이, AW9523 I²C 입력 익스팬더, 키, 오디오, 선택적인 TF 카드 경로. 보드 이름만으로는 모든 주변 장치가 실장되어 있음이 증명되지 않습니다;
• SiFli-SDK, SCons, UART 플래싱 및 로깅 도구;
• 직접 제작했거나, 퍼블릭 도메인이거나, 적법하게 라이선스를 받은 .nes 테스트 ROM;
• 내장 파일 시스템용으로는 저장소의 disk/ 아래에, TF 카드용으로는 펌웨어에 구성된 TF 카드 ROM 디렉터리에 둔 ROM. 고정된 소스는 런타임에 /sdcard/roms/nes를 스캔하므로 해당 리비전을 기준으로 카드의 마운트 경로를 확인하십시오;
• 프레임 동작, 오디오, 입력, 메모리, 전류를 관찰할 수 있는 수단.

하드웨어 및 소프트웨어 사양¶

하드웨어 사양¶

소프트웨어 사양¶

지원되는 기준 구성 선택¶

현재 main의 최신 커밋을 빌드하지 말고, 소프트웨어 사양에 고정된 PocketPi 리비전을 사용하십시오.

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

빌드 스크립트는 ../disk를 파일 시스템 이미지로 만들고 fs_root로 펌웨어에 추가합니다. Windows에서는 생성된 build_sf32lb52-lchspi-ulp_hcpu\uart_download.bat가 플래싱 경로를 제공합니다. 다른 호스트에서는 해당하는 SiFli-SDK 플래싱 도구를 사용하고 동등한 파라미터를 기록하십시오.

프로젝트 개발 단계와 의사결정 지점¶

시스템 아키텍처와 의존성¶

flowchart LR
    B["빌드 입력\ndisk/ 아래의 사용이 허가된 NES ROM"] --> F["fs_root 파일 시스템 이미지"]
    C["TF 카드\n/sdcard/roms/nes"] --> L["LVGL 게임 브라우저"]
    F --> L
    L --> N["Nofrendo NES 에뮬레이터\nCPU, PPU, 매퍼, 스테이트"]
    I["AW9523 I²C 키\nA/B, 방향키, Start, Select, Menu, L/R"] --> N
    N --> V["320 × 240 ST7789 디스플레이"]
    N --> A["32 kHz 오디오 경로"]
    N <--> S["Save State / Load State"]
    D["SiFli-SDK와 보드 지원\nPSRAM, 플래시, TF 카드, 배터리"] --> L
    D --> N

주요 장애 영역은 파일 시스템/ROM, 매퍼/에뮬레이터, PSRAM/메모리, 디스플레이/프레임 타이밍, AW9523 입력, 오디오, 세이브 스테이트, 전원/리셋입니다. 검은 화면은 에뮬레이터 장애라고 뭉뚱그려 보고하지 말고, 먼저 "ROM이 발견되지 않음", "아트워크 디코딩 실패", "지원되지 않는 매퍼", "프레임버퍼 할당 실패", "LCD 경로 실패" 중 어디에 해당하는지 구분하는 것이 좋습니다.

1단계 — 수정하지 않은 게임 기준 구성 확립¶

목표: 사용이 허가된 테스트 ROM 하나로 빌드 입력에서 게임 실행까지의 전체 경로를 증명합니다.

1. PocketPi와 SiFli-SDK 커밋, 보드 및 주변 장치 리비전을 고정하십시오.
2. 사용이 허가된 .nes ROM을 disk/ 아래에 두십시오. 아트워크를 제공하는 경우 기본 파일 이름이 같은 .jpg를 사용하십시오. ROM 해시, 출처, 매퍼를 저장하십시오.
3. 클린 빌드를 수행한 뒤 fs_root가 생성되어 플래싱 산출물에 포함되었는지 확인하십시오.
4. 펌웨어를 보드에 기록한 뒤 콜드 스타트하십시오. 목록에 게임이 나타나고 커버 아트 또는 기본 이미지가 보이며 게임이 실행되는지 확인하십시오.
5. 시작 시간, 안정적인 영상, 키 응답, 오디오, 시리얼 로그를 기록한 뒤 리셋하고 다시 수행하십시오.

보관할 증거: 저장소/SDK 커밋, 보드와 주변 장치, ROM 해시/라이선스, 빌드 로그, 파일 시스템 이미지, 플래싱 로그, 시리얼 로그, 게임 목록/실행 화면 사진.

게이트 1 종료 기준: 두 번의 콜드 스타트에서 같은 ROM이 목록에 표시되고 실행되며, 디스플레이, 기본 방향키/A/B/Start/Select, 오디오 동작이 반복됩니다.

2단계 — 입력, 스테이트, 장애 복구 검증¶

목표: "게임이 시작된다"는 수준을 검토할 수 있는 휴대용 게임기 기준 구성으로 끌어올립니다.

게이트 2 종료 기준: 선택한 ROM에 대해 입력, 디스플레이, 오디오, 일시 정지, 저장, 로드, 종료, 리셋이 기록되어 있으며, 각 실패가 정의된 영역에 대응됩니다.

3단계 — 재현 가능한 소스 및 콘텐츠 기준 구성 빌드¶

목표: 다른 엔지니어가 같은 펌웨어와 콘텐츠 이미지를 다시 빌드할 수 있게 합니다.

1. PocketPi, SiFli-SDK, 모든 서드파티 코어 리비전을 기록하십시오.
2. 각 ROM과 커버의 파일 이름, 해시, 출처, 라이선스를 담은 disk/ 매니페스트를 만드십시오. 재배포할 수 없는 ROM은 커밋하지 마십시오.
3. 빈 출력 디렉터리에서 빌드하고 fs_root, 펌웨어, 메모리/파티션 출력, 플래싱 스크립트, 해시를 저장하십시오.
4. 다른 컴퓨터에서 또는 클린 디렉터리에서 다시 빌드하고 2단계의 핵심 테스트를 반복하십시오.

게이트 3 종료 기준: 문서화되지 않은 로컬 파일 없이 소스와 콘텐츠 매니페스트로 해시가 일치하는 이미지를 재현하거나, 차이가 있으면 그 이유를 설명할 수 있습니다.

4단계 — 한 번에 하나의 변수만 적용¶

목표: 에뮬레이터, 콘텐츠, 하드웨어의 경계를 측정합니다.

게이트 4 종료 기준: 변경 사항과 콘텐츠 권리가 검토되었고, 원래 이미지를 복구할 수 있으며, 선택한 ROM에 대한 2단계 테스트가 모두 통과합니다.

5단계 — 제품 준비 상태 검토¶

커스텀 휴대용 게임기 하드웨어나 콘텐츠 배포에 앞서 다음 질문에 답하십시오.

• 의도한 게임 세트에는 어떤 매퍼가 필요하며, 각 ROM의 프레임 레이트, 오디오, 메모리, 세이브 동작이 검증되었는가?
• PocketPi, Nofrendo, SiFli-SDK, 폰트, 커버, 사운드, ROM의 라이선스와 배포 권리가 명확한가?
• AW9523, LCD, 오디오, TF 카드, 배터리, 충전 하드웨어에 완전한 회로도, BOM, 양산 테스트가 갖춰져 있는가?
• 게임, 목록, 일시 정지, 슬립, 꺼짐 상태의 전류와 배터리 수명, 온도, 배터리 부족 시 동작은 어떠한가?
• 전원 손실, 버전 업데이트, 가득 찬 미디어, 손상이 발생한 뒤 세이브 스테이트를 어떻게 보호하고 마이그레이션하는가?
• 손상된 파일 시스템, 업데이트 실패, 검은 화면, 부팅되지 않는 ROM에서 디바이스는 어떻게 복구하는가?

게이트 5 종료 기준: 호환성 매트릭스, 콘텐츠/소프트웨어 라이선스, 하드웨어 소유권, 전력, 복구 리스크에 지정된 담당자가 있고 진행/보류/중단 결정이 내려져 있습니다.

제품 설계로의 인계¶

SF32/모듈 선택, PSRAM과 플래시 최대 사용량, 디스플레이/프레임버퍼 경로, AW9523 입력 매트릭스, 오디오 앰프와 스피커, TF 카드와 내장 파일 시스템, 세이브 스테이트 형식, 배터리/충전, 복구용 플래싱 포트, ROM/매퍼 호환성 매트릭스, 전체 라이선스 매니페스트를 가져가십시오. SF32LB52x, SF32LB52-DevKit-ULP, SiFli-SDK 빌드, 플래시, 모니터, 양산 설계로 이어서 진행하십시오.

주요 정보 출처¶

• SiFliSparks/PocketPi
• 고정된 레퍼런스 커밋 7d9fac2
• LCKFB Huangshan Pi SF32LB52-ULP 보드
• OpenSiFli/SiFli-SDK
• SiFli Wiki: Huangshan Pi 개발 보드 가이드
• SiFli-SDK 시작 가이드
• pebri86/esplay-retro-emulation
• LVGL 문서

최종 업데이트: 2026-10-19