dmcrespo

Really cool project! The only thing I noticed is that the performance feels a bit slow at times, and it could use a little more fluidity, especially when interacting with the model.

Other than that, everything feels really well done. Building something like this in JavaScript/HTML, especially with a 3D model this detailed, must be quite challenging from an optimization standpoint.

Great work!

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.

Calling this paper "Dream" seems a bit speculative to me. The idea is interesting and reminded me somewhat of karpathy's work at https://github.com/karpathy/autoresearch

Since this is about old iPod technology, I thought this might be interesting here:

I’ve been working on getting the real Apple iPod Classic 6G firmware running in QEMU. It currently emulates two clickwheel iPods, including the display ,click wheel input and music player.

https://github.com/davidmonterocrespo24/qemu-ipod-classic

Still a work in progress

That's incredible, I never imagined that was possible. The Apple ecosystem is very closed.I was checking if it exists for the iPod Classic since it's my favorite

You're partially right. ESP32-C6 isn’t supported yet (only ESP32, S3, CAM, C3 for now), and the current flow is Arduino-based via arduino-cli — ESP-IDF support is planned a future You’re also right about binaries, you can’t upload an ELF/BIN yet, everything goes through the built-in compilation pipeline (but it’s on the roadmap).

Appreciate the feedback.

Yeah, definitely, ESPHome fits really well with what I’m building. I’m currently going through the docs to see how to integrate it properly

Both, with a nuance. The AVR simulator syncs to wall-clock time and each frame calculates cycles from real elapsed deltaMs, so delay(1000) takes 1 real second and timer-dependent code (PWM, millis()) runs at correct real time rates. The RP2040 and ESP32-C3 simulators use a fixed cycles-per-frame budget (125MHz/60 and 160MHz/60 respectively), which targets real time but doesn't compensate for frame drops . if the browser stutters, emulated time stretches slightly. All three are cycle-accurate at the instruction level though, so the logic and peripheral behavior is faithful to real hardware regardless of frame timing

Thanks, appreciate it! Glad you like it

Thanks, appreciate it!

Yes,peripherals are fully emulated, not just the CPU. LEDs blink, buttons respond to clicks, Serial Monitor works, servos rotate, displays render (ILI9341 TFT), and we have 48 o more components from the wokwi-elements library. The Blink example should show the built-in LED toggling on pin 13. If it didn't blink for you, it might be a compilation issue

try the example Traffic Light : Simulate a traffic light with red, yellow, and green LEDs

PIO isn't abstracted yet, we use rp2040js which has a full PIO emulator that executes the actual PIO instruction set (MOV, SET, PUSH, PULL, etc.) cycle by cycle, including the FIFOs and clock dividers. So it's not an abstraction. it's a direct emulation of the PIO state machines, same as how avr8js runs real AVR instructions

Thanks! The rendering is DOM-based, circuit components are Web Components (from the wokwi-elements library) wrapped in React, and wires are SVG. No Canvas/WebGL, which keeps it simple for the component count we're dealing with (typically dozens, not thousands).

The emulation itself is pure JavaScript (avr8js), not WebAssembly. The simulation loop runs on requestAnimationFrame and executes 267K AVR instructions per frame (16MHz / 60fps) in a synchronous batch. Port listeners use dirty-checking so the UI is only notified when a GPIO register actually changes value and since all those cycles run in one JS microtask, React reconciles exactly once per frame regardless of how many state changes happened during the batch

So there's no explicit throttle interval like your 2 sec approach, but the architecture achieves something similar. the CPU runs freely, state changes are coalesced within each rAF frame, and the DOM only sees the final result. For your deck.gl case with thousands of points, the 2s batch makes sense since you're dealing with a much higher entity count hitting the GPU , our problem domain is simpler (dozens of components) but the cycle-accurate emulation is the expensive part

You can add peripherals There’s a “+” button on the right side of the circuit editor where you can add components like LEDs

Thanks! Yeah, that’s probably the easiest way to get started, just load an example and hit “Compile + Play”.

I tried to make it as close to zero-setup as possible so people can just jump in and experiment

Fair enough , though there’s quite a bit of low-level work behind it (emulation cores, QEMU integration, protocol timing, etc)

Definitely inspired by existing tools, but trying to push further into full multi-board emulation and local-first workflows

That’s awesome — and exactly the kind of use case I had in mind

Being able to iterate without constantly flashing hardware can save a lot of time early on.

If you end up trying it in your workflow, I’d love to hear how it goes

Mobile support is something I’ve been paying a lot of attention to, so it's really good to know it runs well even on older devices.

And glad you liked the oscilloscope, that was a fun one to build.You can select the motherboard and ping you want to monitor.

That’s exactly the direction I’m aiming for

A lot of simulators stop at simple sketches, but the goal with Velxio is to support more realistic workflows , multiple boards interacting, real toolchains, and more complex setups

Still early, but definitely moving in that direction

Quick update: traffic is still coming in waves, had to scale up compilation workers to keep up with demand

Things are more stable now, but still tuning performance under load

If anyone finds it useful, the source is here: https://github.com/davidmonterocrespo24/velxio

Always happy to get feedback or contributions.

I’m currently working towards that.

The Raspberry Pi emulation already runs Python, and I’d like to extend that into proper MicroPython / CircuitPython support for microcontrollers as well

It’s a bit tricky depending on the board/emulator, but definitely a priority!

Thanks! The visual editor is actually a big part of the project

I used a little AI to create the graphical interface since I focused heavily on emulation, testing, and refining and optimizing the circuit editor. But now I have plans to improve the UI and make it faster and more intuitive

Still a lot to improve there, but glad it’s useful already

Good catch!!! thanks for pointing that out

The container pulls additional assets on first run (mainly emulation dependencies), which is why there's extra downloading even with -d.

You're right that it can be confusing. I'll update the instructions to make this clearer (and probably remove -d so users can see what's happening)

Quick update: this should be fixed now. It was an overly aggressive CrowdSec rule blocking some legitimate traffic.

If anyone still has issues accessing velxio.dev, let me know

Oh, thanks for reporting this.that definitely shouldn’t happen. It’s likely an overly aggressive CrowdSec rule blocking some legitimate traffic. I’ll look into it and adjust the configuration

Velxio is definitely inspired by Wokwi, and I really like what they’ve built. Parts of Velxio also reuse open-source components , for example, the wokwi elements are used for the visual SVG rendering of boards and peripherals, but they don’t include any emulation logic.

I also integrated a couple of existing open-source emulators, like the Raspberry Pi Pico and Arduino ones. And I even reached out to the creator of Wokwi to share the project.

In terms of differences, one of the biggest ones is that Velxio supports multiple heterogeneous boards in the same circuit: for example, two Arduinos connected over SPI or serial, ESP32 with Arduino, Raspberry Pi 3 with a Pico, etc.

Another major difference is the focus on full emulation, including ESP32 (via QEMU) and a Raspberry Pi 3 running Linux (still in beta).

There are also quite a few other differences, but those are probably the most notable ones

Thanks! That’s a great suggestion, supporting WS2812B strips with arbitrary length is definitely something I’d like to add. I also have in mind adding many more LED based components. I’ll take a look at improving the canvas scrolling too

Good point.I’ll improve that. Thanks!

Exactly,that’s the idea. Not having to flash the chip a thousand times just to see if everything works. The goal is to let you test the setup as fast as possible, ideally without installing anything locally

That’s a really interesting use case. I’m currently evaluating integrating the ESPHome compiler into the project, so it could potentially compile and run ESPHome YAMLs during the development stage

It’s still exploratory, but it could definitely go in that direction