Assembler - Christian-Ioan Szasz

The Assembler desktop app: source editor, processor schematic with buses and registers, and stacked memory, machine code and microcode panes. — assembler · desktop simulator

Overview

A desktop CPU simulator that assembles a 47-instruction set and executes it one microcode step at a time, with the datapath drawn and lit as it goes.

A student writes ten lines of assembly, presses Step, and watches a value travel along the bus into a register.

Write or open assembly source in the editor
Run, pause, step or reset, at a speed you choose
See the active buses and registers light up on the processor schematic

Key facts
Role	Sole author, layered port of an educational simulator
Shape	Four projects, dependency arrow one way, domain depends on nothing
Instruction set	47 mnemonics in four encoding classes, four addressing modes
Targets	Windows and Mac Catalyst, English and Romanian
Tests	83 test methods over 80 data rows, in three test projects
Gate	StyleCop and .NET analyzers, warnings as errors
Source	Closed source

Architecture

Four layers, and a domain that could run from a console tomorrow.

textDependency direction: Maui to Presentation to UseCases to Domain

src/
├── Assembler.Domain/        Pure CLR: ISA, assembler, microcode, simulator core
├── Assembler.UseCases/      Facades and fluent builders over the domain
├── Assembler.Presentation/  AppPresenter (MVP), AppStateMachine (FSM), view ports
└── Assembler.Maui/          .NET MAUI: one ViewModel per pane, drawn schematic, dialogs

The domain uses no UI framework and starts no timers. Delay comes from an injected clock.
Every effect leaves the domain as a typed event over a channel.
I chose MVP over plain MVVM so one presenter holds the coordination, not every pane.
The only packages are MAUI and CommunityToolkit.Mvvm. The schematic is drawn by hand.

Domain design

An instruction set where the opcode is derived, not looked up.

47 mnemonics in four encoding classes, four addressing modes, sixteen registers.
Each instruction runs as a microcode program that names the exact bus it uses.
The domain says "the S bus was activated", never "highlight this", so the drawing can change without touching the simulator.

Data and control flow

One press of Step, from the button to the lit bus.

The presenter fires a trigger at the state machine. A rejected transition does nothing.
The simulator fetches, decodes and runs one instruction's microcode.
Each step publishes what it touched: bus, registers, flags.
The presenter routes each event to the open panes, and the schematic redraws.

Testing strategy

Three test projects below the UI, and none above the presenter.

A golden-encoding suite pins the exact machine code each instruction assembles to.
The state machine is tested exhaustively: 42 rows, every accepted and rejected transition.
The injected clock lets a twenty-second run finish in microseconds under test.
StyleCop and .NET analyzers with warnings as errors. An undocumented member fails the build.

What I would change

The schematic keeps its own light palette while every other pane is dark. It should read the theme.
Nothing above the presenter is tested. An automation-driven smoke test is the realistic next gate.
The state machine has no entry or exit actions: fine at nine states, not at thirty.
The microcode catalogue is built in. Loading one from a file would help students most.