Simulator86

Introduction

Simulator86 brings cheap, fast iteration to embedded development.

Embedded teams move slowly because hardware ties everything together. Every change needs testing on physical boards, and that creates a feedback loop completely different from modern software development.

But hardware isn’t the culprit. When software and hardware are separated, hardware becomes the launch point, not the development environment. The feedback loop becomes faster, cheaper, and far more predictable. Just like pure software.

Every team already practices a form of simulation without realizing it. Writing requirements is simply a low-resolution simulation of the final product: a rough model that helps catch mistakes early. When requirements aren’t clear, teams fall into guesswork, refactors, and rewrites.

As the team grows, communication overhead grows with it. Clear expectations and fast feedback matter even more, so do simulators, because alignment becomes the difference between smooth delivery and expensive delay. Even in pure software, where mistakes cost nothing, this “early simulation” still saves time.

Hyperreal

Our goal is to make simulations as realistic as possible. The closer they are to real hardware, the more risks disappear and the more users save on time, boards, and debugging effort.

And even with perfect realism, simulators have one advantage hardware can’t match: debugging visibility. Visibility over everything¹, signals, state, timing, memory, without probing or soldering a thing.

“…but it’s not 100% accurate”

Simulations don’t need to be perfect to be valuable. We use them everywhere, in planning, decision-making, brainstorming, and early design. Even when a simulation drifts from reality, the cost of correcting it is still far cheaper than discovering the same mistake on real hardware.

It’s instinctive to model before executing.

Simulation-first development

Traditional embedded development is hardware-first. Each engineer waits for a dev board, flashes firmware, reboots, repeats tests, burns time, and occasionally burns components. Every iteration depends on physical hardware, which is slow, limited, and expensive.

That entire model is obsolete.

In simulation-first development, engineers start instantly. They run simulations directly against their code, explore scenarios that are expensive or impossible to reproduce on hardware, and push edge-case feedback into a virtual environment instead of risking physical devices. Hardware is only needed at the end — for real-world validation, not for iteration.

GUI is a high-bandwidth path to truth.

Visual feedback is the fastest feedback and the easiest to validate. That’s why AI is more effective in generating UIs, because visuals are quick to validate, quick to iterate on, and quick to correct. They compress the feedback loop far more effectively than working in deep, low-level code.

Footnotes

1. Some debugging features will be added soon. ↩