Hello Gus, the entire GHI team, and all the engaged members of this community — especially Mike, whose appreciation for the staff was spot‑on. It’s a pleasure to share something with people who not only build technology, but also remember where their own engineering journey began.
I’d like to share a pedagogical perspective on how AluLab came into existence and what it is meant to demonstrate.
The idea started from something very simple:
I realized that many younger people today no longer know what a computer actually is at its core. They know devices, operating systems, apps, frameworks — but not the fundamental logic that makes all of it possible. The Arithmetic Logic Unit, the ALU, is the heart of every CPU, GPU, DSP, microcontroller, and SoC. Without it, nothing computes.
Back in 1978, at the age of 14, I had a 74181 on my breadboard.
That chip — introduced in 1970 and widely used throughout the 1970s — is a real, physical embodiment of computation. Not an emulation, not a simulation, not a diagram. The actual thing.
So I decided to bring it back.
Not as nostalgia, but as part of my Back to the Future project series:
a modern .NET‑based, platform‑independent system that uses a real 1977 ALU to teach what computation fundamentally is.
But the ALU is only the anchor.
The real purpose of AluLab is to show something far more important:
AluLab demonstrates true platform‑independent architecture.
One shared codebase runs on:
- Windows desktop
- Linux (Raspberry Pi, Domino/Endpoint framebuffer)
- Browser (WASM)
- TinyCLR hardware
- and, in principle, also Android, iOS and macOS
The only difference between these platforms is the platform‑specific entry point.
Everything else — domain logic, synchronization, UI model, hardware abstraction — is identical.
Clarification
- Android is not limited by hardware — it is limited by the constantly shifting build environment, which makes stable development unnecessarily time‑consuming.
- Apple platforms (iOS/macOS) are hardware‑dependent, which is why those projects are not yet started.
There is no architectural barrier.
Only practical constraints.
Hybrid modern + legacy by design
Most of the solution uses modern .NET SDK‑style projects, Avalonia, WASM, Linux, and structured logging.
One project uses classic MSBuild with packages.config and TinyCLR net48.
This duality is intentional: it shows that the architecture does not depend on the toolchain.
Hardware‑first domain model
The board layer orchestrates:
- I²C/SPI/GPIO
- expander probing
- reset sequencing
- ALU controller wiring
- touch/display drivers
Hardware is treated as a first‑class domain, not as an afterthought.
Real‑time synchronization backbone
The server provides:
- SignalR‑based synchronization
- state endpoints
- a live HTML monitor
- an ALU evaluation API that distributes pin toggles and waits for hardware feedback
This is a precise technical reflection of the ALU hardware.
The Endpoint Domino as dedicated hardware host
One of the three intended hosts is the Endpoint Domino, running .NET 10 flawlessly.
It connects directly to the ALU hardware and acts as the autonomous, unattended operator:
- It handles all I/O to the 74181.
- It communicates via SignalR with any number of clients.
- It runs independently of desktop or browser hosts.
- It is designed for 24/7 operation in a dedicated environment currently being built.
This allows anyone, from anywhere, at any time, to connect to the ALU —
and observe or control a real 1977 logic unit through a modern .NET system.
Open, structured, didactic
Everything is source‑open.
Everything is cleanly separated.
Everything is designed to show how modern .NET, hardware abstraction, and deterministic logic can coexist without friction.
Now that I have more time for such projects, I will continue to publish TinyCLR drivers for various devices.
Feel free to use them to extend your own suite — they are open by design.
Why this matters
GHI and Microsoft have been working for many years on a technology stack where developers can focus on the actual task — not on the platform, not on the toolchain, not on the plumbing.
AluLab is meant to make that visible.
Implicate-X/AluLab
The video under media.homelabs.one/docs/alulab1.mp4 shows an earlier version in action. Two Android devices, one Windows machine, and one Raspberry Pi, with the output also rendered again on the ALU Lab display. Everything updates each other in real time via SignalR. The Domino endpoint is still missing. Since Domino is the fastest and thinnest system that always keeps its cool, it’s intended to serve as the workhorse for 24/7 operation. This already makes the project visible as a feasibility study — showing that the entire architecture works across all hosts simultaneously.
And through https://iot.homelabs.one/sync/monitor you can see the events coming from the clients and the responses returned by the ALU Lab.
And of course, there is also a full Web API available at https://iot.homelabs.one/swagger. The ALU Lab board is currently not connected to any host, because the new setup is being built around the Endpoint Domino.
Although Endpoint Domino takes the visible role as the real‑time edge host, TinyCLR is still present — quietly and reliably running on a FEZ Pico beneath the ALU Lab board, handling the safe switching of hosts.
