AI-generated editorial concept image: WonderSift.
The first thing you meet is a blank screen and a blinking cursor. Then comes a chirp, a blocky menu, or the faint sensation that you should be hunting for a cassette deck. Except there is no cassette deck. There is not even an installation wizard. You are staring at an entire 8-bit computer squeezed into a browser tab.
Tiny Emulators offers one gallery, many vintage machines, and almost no ceremony. The better story sits under the hood: old hardware, modern WebAssembly, and unusually tidy open-source code meet in the middle.
A whole computer, flattened into a tab
The core chips repository is not a folder of game downloads. It describes itself as a toolbox of chip emulators, helper code, and complete embeddable systems written as dependency-free C headers. A companion project, chips-test, contains tests and sample emulators. Its README points to Tiny Emulators as the live home of those examples compiled to WebAssembly.
The deployment code packages each demo's .wasm and JavaScript files into the site. That makes local, client-side execution a reasonable inference from the architecture, not a marketing slogan. The repositories also document separate native desktop builds. Those sample builds have prerequisites even though the core chips headers themselves are described as dependency-free.
Browser emulation is not new, and Tiny Emulators did not invent it. What feels special is the clean bridge from readable source code to a machine you can poke five seconds later.
The project’s documented build path, simplified.
C headers
Chip and system models live in the open-source
chips project.
Examples
Tests and sample emulators are assembled in
chips-test.
WASM + JavaScript
WebAssembly modules and browser glue are packaged for the site.
Browser tab
Client-side execution is a reasonable inference from that architecture.
Remember: Open-source emulator code does not automatically grant rights to every ROM, game, firmware, tape, or disk image.
Nostalgia's guest list just got more interesting
The current gallery includes familiar names: Commodore VIC-20 and C64, ZX Spectrum 48K and 128, Amstrad CPC464 and CPC6128, and Acorn Atom. Then the tour takes a welcome turn into machines that appear less often in English-language retro roundups: KC85/2, KC85/3, KC85/4, KC Compact, LC-80, Robotron Z1013, Z9001 with BASIC and RAM modules, and KC87.
There are also visual remixes of the 6502, Z80, and 2A03 processors. In other words, this is not only a C64-versus-Spectrum reunion. It is a small museum where home computing, education, regional manufacturing, and processor design share a hallway.
Calling these “full computers” needs one useful asterisk. The project models a CPU, memory, video and sound devices, and input/output hardware closely enough that software sees a recognizable system. It does not reproduce every transistor or the physical machine. The chips README says components exchange bit masks representing chip pins and are wired together roughly like parts on a breadboard; it also openly notes some callbacks and address-decoding shortcuts.
Your five-minute field trip
Start with one of the gallery's UI links. The project's help page says arrow keys usually handle direction and the space bar acts as jump or fire. Some demos wait for Space or 1 at their own title screen. If the opening is silent, click or press a key: browser audio policies may be holding the sound until you interact.
The UI builds are also the recommended choice for loading a local file because they let you toggle joystick emulation. Drag a supported file onto the browser window; a green flash means success and red means error. The accepted formats depend on the machine—C64 supports PRG and TAP, ZX Spectrum supports Z80 snapshots and TXT, and Amstrad CPC supports DSK, TAP, SNA, BIN, and TXT, among others.
Loading is not the same as launching. A CPC disk image may ask you to type CAT and then RUN"filename; a C64 PRG usually needs RUN. That tiny bit of friction is historically honest. You are meeting the original machine's habits, not a universal media player wearing a beige costume.
Try this responsibly: Begin with the built-in examples, software you wrote, or files whose rights holder authorizes your use. Keep a note of the source and license. An emulator can be open source while a ROM, game, firmware image, tape, or disk file remains separately protected.
The breadboard is made of bits
Why bother putting this in a browser? A URL turns setup into an invitation. A teacher can place an emulator beside a manual. A developer can share a reproducible bug or timing experiment. A curious reader can compare several computer designs without installing a shelf's worth of desktop packages.
The browser can also become a window into timing. Weissflog's account of his cycle-stepped Z80 core explains how advancing one clock cycle at a time simplifies whole-system emulation and debugging; the Z80-based Tiny Emulators gained cycle stepping in their CPU debugger. His earlier 6502 article shows why coordination between a processor and its peripheral chips matters.
There are limits. Browser sound can wait for interaction, modern keyboards do not reproduce every original layout, touchscreens are poor substitutes for vintage joysticks, and the project's documented modeling shortcuts can affect edge-case fidelity. Code can preserve behavior remarkably well; it cannot recreate the weight of the keyboard, glow of a CRT, or room in which somebody first typed 10 PRINT.
Open code is not an all-access pass
The distinction is simple and worth repeating. The chips code uses the zlib license, while chips-test uses the MIT license. Those licenses grant permissions for the emulator projects. They do not automatically grant rights to every program the emulator could run.
Some software is public domain, openly licensed, distributed with permission, or yours because you created it. Other material may still be protected. Use authorized copies and check the terms attached to them. That is practical housekeeping, not legal advice—and it keeps a lovely technical project from being confused with a software free-for-all.
The tab is small; the rabbit hole is not
Tiny Emulators is less a technological first than a beautifully made bridge. On one side: C headers, clock cycles, pin masks, and test programs. On the other: a link that boots a computer many readers have never touched.
That crossing turns nostalgia into curiosity. Click for the blinking cursor; stay to compare designs, read the code, try a BASIC program, or discover why a machine from another place and decade behaved the way it did. The computers may be tiny on screen. The history they open is anything but.
Primary and authoritative sources
- Tiny Emulators live gallery — current systems and configurations shown
- Tiny Emulators help — controls, browser audio behavior, drag-and-drop feedback, file formats, and launch commands
floooh/chipsrepository and README — project purpose, architecture, WebAssembly examples, and modeling shortcutsfloooh/chips-testrepository and README — tests, sample emulators, native/WebAssembly build paths, and live-demo relationshipchips-testweb deployment code — packaged.wasmand JavaScript assets- “A new cycle-stepped Z80 emulator” — developer explanation of cycle stepping and debugger behavior
- “A new cycle-stepped 6502 CPU emulator” — developer explanation of CPU/system timing
chipszlib license andchips-testMIT license — open-source project licenses
