AWESOME. you should try on a s3 with a parallel display. the p4 would have the same sort of issues but an s31 would be great. the mmu could further solve the memory issue. i like the fact that you chose the size because it was smaller. i have some p4 boards and some s3 panels like a panel lan that has a parallel screen and a hosyond s3 thats not bad. ill get into it this weekend. adam, phirzcol at the google same on git

I spent the last few months porting the original PlayStation Metal Gear Solid (1998) decompilation directly to an ESP32-S3 microcontroller, targeting the Seeed XIAO ESP32-S3 Sense and Waveshare handhelds.

AI was used to port to ESP32, and human talent was used to assemble the circuit, hardware, and proprietary knowledge of ESP32 and FreeRTOS optimizations.

Rather than running an emulator, the decompiled C source from mgs_reversing is compiled natively to Xtensa machine code. Everything the original PS1 hardware provided, including the GTE, GPU, BIOS scheduler, and CD drive, is reimplemented in software on top of ESP-IDF and FreeRTOS.

SoC: ESP32-S3, dual-core Xtensa LX7 @ 240 MHz, 512 KB internal SRAM, 8 MB Octal PSRAM.

Display: 320×240 LCD (ST7789 / ILI9341) over SPI at 40 MHz.

Storage: MicroSD card over SPI containing the full game stage assets (STAGE.DIR).

Internal SRAM is fast but limited, while PSRAM provides 8 MB of additional memory but sits behind the same cache subsystem used for external Flash.

Placing FreeRTOS task stacks in PSRAM initially appeared to work, until a task performed file I/O such as fopen().

When external Flash cache was disabled during Flash/PSRAM access, the CPU could no longer safely access task stacks stored in PSRAM, causing an immediate SoC crash.