นี่คือ Native Port ไม่ใช่ PlayStation Emulator

ถ้าพูดว่า “ESP32-S3 เล่นเกม PlayStation ได้” หลายคนอาจนึกว่า ESP32-S3 กำลังจำลอง CPU, GPU, BIOS และ Hardware ของ PlayStation ทั้งเครื่อง

แต่ Project นี้ใช้วิธีคนละแบบ

สิ่งที่ PlayStation Hardware เคยให้เกม ต้องถูกสร้างขึ้นใหม่ใน Software ตั้งแต่ SDK, GPU, GTE Geometry Coprocessor, CD Drive, VBlank Interrupt ไปจนถึง Controller Input

จุดเริ่มต้นมาจาก mgs_reversing

David ไม่ได้เริ่มจาก Binary ของเกมแล้วเขียน Engine ใหม่ทั้งหมด แต่ต่อยอดจากโครงการ FoxdieTeam/mgs_reversing ซึ่ง reconstruct Code ของ Metal Gear Solid ให้กลับมาอยู่ในรูป C source

จากนั้นจึงสร้าง Branch สำหรับ ESP32 และค่อย ๆ แก้ส่วนที่ผูกกับ MIPS CPU, PSY-Q SDK และพฤติกรรมเฉพาะของ PlayStation

Current Port อยู่ใน Repository: davidmonterocrespo24/mgs_reversing branch esp32-port

XIAO ESP32S3 Sense เล็กแค่ไหน แต่ต้องแบกเกม PS1 อะไรบ้าง?

ตัวเลขที่น่าสนใจที่สุดคือ Internal SRAM เพียง 512 KB เพราะเกมยุค PlayStation ไม่ได้ถูกออกแบบมาให้รันบน Memory Layout แบบ Microcontroller สมัยใหม่ ดังนั้น PSRAM จึงกลายเป็นหัวใจสำคัญของ Port นี้

จาก C เก่าปี 1998 ไป Xtensa: Compile ได้ไกลแค่ไหน?

ก่อนเริ่มเขียน Platform Layer จำนวนมาก David วัดก่อนว่า Engine เดิมห่างจาก Xtensa แค่ไหน

ผลแรกคือ Engine Libraries:

57 จาก 58 Files Compile ได้แทบจะทันที

หลังแก้ Compatibility Issues เป็นกลุ่ม ผลกลายเป็น:

• 497 / 497 C files Compile สำเร็จ
• 0 Undefined References
• 0 Duplicate Definitions ณ จุดที่วัด
• Text: 987,073 bytes
• BSS: 2,434,276 bytes

ตัว Game Memory เองถูกประเมินไว้ราว:

804 KiB จาก Heap 428 KiB และ Packet Buffers 188 KiB สองชุด

Compiler รุ่นใหม่ก็สร้างปัญหาได้

Source ระบุว่าต้องใช้ -std=gnu17 เพราะ GCC 14 Default เป็น gnu23 ซึ่งไม่ยอมรับ Construct เก่าบางแบบ

อีก Flag สำคัญคือ -mlongcalls เพราะ Xtensa call8 เข้าถึง Function ได้ประมาณ ±512 KB แต่ Program Image มีขนาดใหญ่กว่านั้น

Architecture ของ Port: MGS → psyz → ESP32-S3

1. MGS Engine

Game Logic ที่ reconstruct เป็น C ถูก Compile ไปเป็น Xtensa โดยตรง

2. psyz

ทำหน้าที่แทนส่วนที่ PlayStation SDK เดิมเคยให้ รวมถึง GTE Operation และ Interface ด้าน Graphics

3. ESP32 Platform Layer

จัดการสิ่งที่ Console เดิมเคยมีเป็น Hardware หรือ BIOS Service:

• FreeRTOS-based scheduler mapping
• VBlank tick
• Virtual CD
• LCD output
• Input

4. ESP32-S3

สุดท้ายทุกอย่างรันบน Xtensa cores ของ Microcontroller จริง

Konami Scheduler ถูกย้ายมาทำงานบน FreeRTOS ยังไง?

Metal Gear Solid ไม่ได้ใช้ FreeRTOS เพราะเกมถูกสร้างมาก่อน ESP32 หลายสิบปี

Engine เดิมใช้ Cooperative Scheduler ของ Konami ที่ทำงานบน Thread API ของ BIOS PlayStation

ใน Port นี้ mts thread แต่ละตัวถูก Mapping ไปเป็น FreeRTOS Task แต่ระบบควบคุมไม่ให้ทุก Task วิ่งพร้อมกันแบบ FreeRTOS Application ทั่วไป เพื่อรักษา Behavior เดิมของ Scheduler

การแบ่งงานผิด Core เคยสร้าง Race Condition จน Task ที่ควร Suspend กลับตื่นขึ้นกลาง Stack ดังนั้น Dual-core ไม่ได้ถูกใช้เพียงเพื่อเพิ่ม FPS แต่ต้องรักษา Timing Model ของเกมด้วย

512 KB SRAM กับ 8 MB PSRAM แบ่งงานกันยังไง?

ปัญหาคือ Internal SRAM เร็ว แต่มีเพียง 512 KB ขณะที่ PSRAM มีพื้นที่มากกว่า แต่ Latency สูงกว่า

VRAM อย่างเดียวกิน 1 MB

PlayStation VRAM ถูกจำลองเป็น Buffer ขนาด 1 MB ซึ่งใหญ่เกินกว่าจะเอาไปวางใน Internal SRAM จึงต้องอยู่ใน PSRAM

Task Stack ก็เคยถูกย้ายไป PSRAM แต่พบปัญหาเมื่อ Code เรียก Flash-related Function: Cache ถูกปิดชั่วคราว ขณะที่ Stack เองก็พึ่ง PSRAM ผ่าน Cache จน SoC Reset ได้

สุดท้าย Task Stack จึงกลับมาอยู่ Internal SRAM และต้องวัด High-water Mark จริง เพื่อหาขนาดที่เหมาะ

ไม่มี CD Drive แล้วเกมโหลด Stage จากไหน?

Game Engine เดิมไม่ได้ขอเปิด File ด้วยชื่อแบบ Application สมัยใหม่ แต่ libfs ทำงานด้วย Absolute Sector ตามแนวคิดของ CD-ROM

Port จึงสร้าง virtual_cd.c เพื่อรับ Sector Number แล้ว Mapping กลับไปเป็น:

การส่ง Data ยังต้องรักษา Behavior แบบ Asynchronous เพราะ Game Parser และ “CD” ใช้ Buffer ร่วมกัน หาก Copy ทุก Sector รวดเดียว File ถัดไปอาจเขียนทับ Data ก่อน File ก่อนหน้าถูก Parse เสร็จ

STAGE.DIR เต็มมีขนาดเท่าไร?

Source ระบุ Full STAGE.DIR มีขนาด:

71,892,992 bytes

และถูกอ่านจาก microSD ตามต้องการ แทนการโหลดทั้งหมดเข้า PSRAM

มีข้อมูล 96 Stages แต่ทำไม Port ยังเล่นได้ไม่ครบ?

ตรงนี้เป็นอีกจุดที่ต้องแยกให้ชัด

Full STAGE.DIR มีข้อมูล Stage บน Disc ครบ แต่ Code ของทุก Stage ยังไม่ได้ถูก Reconstruct เป็น C ครบ

Source ระบุ:

• มี 93 Stage Files ที่เกี่ยวข้อง
• 65 Stage Files มี Fully Symbolic Actor Tables
• 28 Stage Files ยังมี Raw MIPS Addresses
• Current Generated Whitelist มี 56 Stages และ 149 Actor Classes

Software Rasterizer ต้องเลียนแบบ “สิ่งที่ PS1 GPU ไม่ยอมวาด” ด้วย

Bug หนึ่งทำให้เวลา Enemy เห็น Snake เกิดแผ่นสีขาวขนาดใหญ่ปิด Scene

ตอนแรกดูเหมือนเป็น Rendering Bug ธรรมดา แต่ Root Cause ส่วนหนึ่งคือ Software Rasterizer ยังไม่เลียนแบบข้อจำกัด Hardware ของ PS1 GPU

Source ระบุว่า PS1 GPU ปฏิเสธ Polygon ที่ใหญ่กว่า:

1023 × 511 pixels

เมื่อ Polygon ผ่านหลัง Camera GTE สามารถ Saturate Coordinate จนเกิด Polygon ยักษ์

Console เดิม Drop มัน แต่ Software Renderer วาดมันจริง จึงเกิดทั้ง White Screen และ Rasterization Cost สูงมาก

Port เกมเก่าไม่ได้ยากแค่เรื่อง CPU ช้า

Ordering-table Tag: 4 bytes กลายเป็น 8 bytes

บน PlayStation Primitive ใช้ Tag 32-bit ที่รวม:

• 24-bit address
• 8-bit length

แต่ Pointer บน Platform ใหม่ ใส่ใน 24 bit ไม่ได้ psyz จึงแยก:

tag + len

ทำให้ Header โตขึ้น 4 bytes และ Field หลัง Header ขยับ Position ทั้งหมด Code เก่าที่สมมติ Layout เดิม จึงพังแบบที่มองยากมาก

Strict Aliasing ทำ Skeleton พัง

Code ปี 1998 ใช้ Type Punning ในรูปแบบที่ Compiler เก่ารับได้ แต่ GCC 14 ที่ Optimize ด้วย -O2 ตัด Store บางส่วนทิ้ง เพราะสรุปว่าไม่มีใครอ่าน

ผลคือ Matrix Translation ไม่ถูก Rotate ตาม Parent จนแขน ขา และ Joint ของตัวละคร อยู่ผิดตำแหน่ง

Fix หลักคือ:

• แก้ Arithmetic ให้ไม่ Type-pun แบบเดิม
• ใช้ -fno-strict-aliasing สำหรับ Game

Division by zero: MIPS รอด แต่ Xtensa Reset

Code บางจุดมี Runtime Divisor ที่อาจกลายเป็นศูนย์

R3000 ของ PlayStation ยังเดินหน้าต่อด้วย Undefined Result แต่ Xtensa Raise IntegerDivideByZero และ Reset Board

Pointer ที่เคยเป็น Negative กลับกลายเป็น Positive

PS1 RAM อยู่แถว 0x8xxxxxxx ซึ่งเมื่อตีความแบบ Signed มี Sign Bit เป็น 1

แต่ ESP32 PSRAM อยู่ใน Address Range คนละแบบ ทำให้ Logic ที่เคยใช้ “Pointer ติดลบ = Memory Pointer” ไม่สามารถใช้ตรง ๆ ได้อีก

Performance ตอนนี้ได้กี่ FPS?

อะไรทำให้ 3D ช้า?

Source ระบุว่าต้นทุนหนักคือ Textured Pixels + PSRAM Latency

Textured Pixel บน MGS ใช้ประมาณ:

207 cycles / pixel

เกม 3D มี Texture Coordinate เปลี่ยนไปตาม Triangle ทำให้ Cache Miss บ่อยกว่าเกม 2D ที่อ่าน Texture เรียงต่อกัน

Data Cache ถูกใช้ถึง Maximum 64 KB แล้ว ดังนั้นแนวทางถัดไปคือ ย้าย Hot Texture Pages บางส่วนจาก PSRAM เข้า Internal SRAM

จาก Port บน Board สู่ Handheld จริง

Creator ประกอบ Prototype บน Perfboard โดยใช้:

• XIAO ESP32S3 Sense
• ILI9341 SPI 320×240
• Analog Stick แบบ 2-axis
• Push Buttons 8 ปุ่ม
• Resistors สำหรับ Button Ladder
• microSD บน Sense Expansion Board

ทำไม ILI9341 กลับเหมาะกว่าที่คิด?

แผนแรกคิดว่าจะใช้ ILI9488 480×320 แต่ Hardware ที่มีจริงกลับเป็น:

ILI9341 320×240

ซึ่งตรงกับ Resolution ที่เกม Render อยู่แล้ว จึงไม่ต้องทำ Image Scaling

6 Buttons ใช้ ADC Pin เดียวได้ยังไง?

XIAO มี Pin จำกัด แต่ Handheld ต้องใช้ทั้ง:

• 2 Analog Stick Axes
• LCD SPI
• microSD
• 8 Buttons

Creator จึงใช้ Resistor Ladder ให้ 6 Buttons แชร์ ADC Input เพียง Pin เดียว

Ladder ประกอบด้วย:

• 10 kΩ pull-up
• 0 Ω
• 2.2 kΩ
• 4.7 kΩ
• 10 kΩ
• 22 kΩ
• 47 kΩ

แต่มีข้อจำกัด: หากกดสองปุ่มใน Ladder พร้อมกัน Design นี้จะ Register ปุ่มที่มี Resistance ต่ำกว่า

ดังนั้น Action ที่ต้องกดพร้อมกันบ่อย อย่าง Fire + Aim จึงถูกแยกออกไปใช้ Pin ของตัวเอง

Official Wiring ของ Handheld

LCD และ microSD แชร์ SPI Bus

microSD บน Sense Board ใช้ SPI Lines เดียวกับ Display โดย SD CS อยู่บน GPIO21 ภายใน Board

Port เคย Reboot เมื่อ SD Read แทรกเข้ามากลาง LCD Asynchronous Transfer

Fix จึงต้องมี Explicit Bus Ownership และรอ Transfer ที่ยังค้างให้จบ ก่อนปล่อย SPI Bus

Hardware Caveats จาก Build จริง

• LCD RESET ต้องต่อที่ D4 จริง ไม่ใช่พึ่ง Software Reset อย่างเดียว
• Potentiometer ใช้ 3.3V ไม่ใช่ 5V เพราะ ESP32-S3 ADC ไม่ 5V tolerant
• Button 4 ขาควรใช้ขาแนวทแยงตาม Hardware Guide
• Prototype ที่ใช้ Jumper Wire เสถียรที่ LCD SPI 40 MHz แต่ 80 MHz เกิดภาพเลื่อนเป็นแถบ

Analog Stick ต้อง Calibration ไม่ใช่สมมติว่ากลางคือ 2048

Drone Gimbal ที่ Creator ใช้ ไม่ได้พักตรง Mid-scale ของ ADC

Measurement ของ Stick ตัวอย่าง:

• Resting position: 2317
• X travel: 141 → 2888
• Measured noise: ประมาณ ±15 counts
• Dead zone ที่ใช้: 60 counts

Firmware จึงใช้ค่าที่อ่านตอน Boot เป็น Center แล้วเรียนรู้ Range จากการขยับไปแต่ละด้าน

ดู Metal Gear Solid รันบน ESP32-S3 จริง

ตอนนี้อะไรยังไม่ทำงาน?

คำว่า “Metal Gear Solid รันบน ESP32-S3 ได้” เป็นเรื่องจริง แต่ไม่ควรตีความว่าเกมสมบูรณ์แบบเทียบกับ PlayStation แล้ว

Loading ยังเป็น Bottleneck อีกจุด

Source ให้ Measurement หนึ่งชุดว่า:

อ่านข้อมูล 1.1 MB ใช้เวลาประมาณ 11.5 s

หรือประมาณ:

95 KB/s

Creator ระบุว่า Card ทำงานเสถียรที่ 20 MHz บน Board ที่ทดสอบ แต่ 40 MHz เกิด CRC Error

Build จาก Official GitHub

Current README ระบุว่า Port ใช้ ESP-IDF v5.5 และพึ่ง Companion SOTN Port ซึ่งให้ psyz และ Header บางส่วน

ด้านล่างเป็น Command ที่ยกมาจาก Current README ไม่ใช่ Installation Guide ที่แต่งเพิ่ม

git clone -b esp32-port --recurse-submodules https://github.com/davidmonterocrespo24/sotn-decomp

powershell -File esp32/build.ps1 xiao
powershell -File esp32/flash.ps1 COM9 -Xiao

ต้องมี Metal Gear Solid Disc ของตัวเองหรือไม่?

ใช่ ตาม Current Repository ผู้ใช้ต้องมี Disc / Disc Image ที่ได้มาอย่างถูกต้องของตัวเอง

Repository ระบุชัดว่า ไม่ได้แจก Game Data ที่ Derived จากตัวเกม

มี Script: port/extract_disc.py สำหรับ Extract File จาก Disc Image ของผู้ใช้เอง

Maker และ Embedded Developer ได้อะไรจาก Project นี้?

1. Measure ก่อน Guess

Creator ย้ำหลายครั้งว่า Explanation ที่ดูสมเหตุสมผลจำนวนมาก กลับผิดเมื่อวัด Hardware และ Runtime จริง

วิธีที่ใช้ได้ผลคือ สร้าง Probe ที่สามารถพิสูจน์ว่า Hypothesis ผิดได้จริง ไม่ใช่ Probe ที่ให้คำตอบ “ผ่าน” อยู่แล้ว

2. Port Software เก่าคือการ Port Assumption ด้วย

Game ไม่ได้พึ่งแค่ API ของ PS1 แต่ยังพึ่ง:

• Integer behavior
• Pointer layout
• GPU limits
• Scheduler timing
• Compiler behavior ในยุคนั้น

3. Memory Size อย่างเดียวไม่พอ

แม้มี PSRAM 8 MB แต่ Stack บางชนิดย้ายไป PSRAM ไม่ได้ง่าย เพราะ Cache Behavior และ Flash Access สามารถทำให้ระบบ Reset ได้

4. Dual-core ไม่ได้หมายถึงโยนงานไปสอง Core แล้วจบ

Legacy Scheduler มี Timing Assumption ของตัวเอง การย้าย Task ไปผิด Core สามารถสร้าง Race Condition ที่ Console เดิมไม่เคยมี

5. Hardware Constraint บางอย่างคือส่วนหนึ่งของ Game Logic

กฎ Polygon Size ของ PS1 GPU ดูเหมือนข้อจำกัด แต่ตัวเกมพึ่ง Behavior นี้จริง

FAQ: คำถามที่พบบ่อย

References / แหล่งข้อมูลต้นฉบับ

• David Montero Crespo — Metal Gear Solid running natively on the ESP32-S3
• Hackaday — Metal Gear Solid Moves From PlayStation To ESP32
• Official ESP32 Port — davidmonterocrespo24/mgs_reversing
• ESP32 Port README
• ESP32-S3 Handheld Hardware Guide
• psyz — PlayStation SDK reimplementation used by the port
• FoxdieTeam — mgs_reversing
• Gameplay Video — Metal Gear Solid running on an ESP32-S3