CLK (Clock Signal): a multi-machine emulator that treats latency as a bug

The problem CLK solves: emulator setup as the obstacle, not the emulation

Most emulators ask the user to become a machine operator. You create a machine, pick a model, insert a disk image into a drive, remember the loading command for that particular system, and repeat the ritual for every title. Clock Signal takes the opposite position: the README says the emulator seeks to be invisible, and that the full process of loading software is to locate it in your OS and double click it. That is the whole interface promise.

The target user is someone with a folder of classic media in mixed formats who does not want to maintain a per-system mental model. The README states there is no import procedure and that CLK does not attempt to take ownership of your files or to usurp your OS. Files stay where they are, and the emulator is a viewer rather than a library manager.

The breadth is the other half of the pitch. The README lists emulations of the Acorn Electron, Amstrad CPC, Apple II/II+ and IIe, Atari 2600, Atari ST, BBC Micro, ColecoVision, Commodore Plus 4, Commodore Vic-20, Enterprise 64/128, Macintosh 128K through Plus, MSX 1 and 2, Oric 1/Atmos, Sega Master System, Sinclair ZX80/81, Sinclair ZX Spectrum, Tandy CoCo 1/2, and Thomson MO5/6. The Acorn Archimedes, Commodore Amiga and early PC compatible are present but the README describes them as less rounded, which is an unusually direct admission to leave in a front page.

Static and runtime analysis behind single-step loading

The single-click behaviour is not a shell script that guesses by file extension. The README says CLK uses static and runtime analysis to select and configure the appropriate machine for any provided disk, tape or ROM, to issue the commands necessary to run the software, and to provide accelerated loading where feasible. So the media file is inspected, a machine is chosen, the media is mounted, and the loading keystrokes that a human would type are generated.

That design has a consequence worth naming. Because the machine and the load procedure are derived from the media, there is no configuration file to inspect when something goes wrong. A title that defeats the analysis will not present you with a machine definition to edit; the README documents no manual override path for that case.

Signal processing is the second architectural choice. The README gives the Commodore Vic-20 as the example: its only video output is composite, therefore the emulated machine's only video output is composite, and the GPU decodes it. Composite artefacts appear because the real signal is being processed, not because a filter was applied afterwards. Audio follows the same rule: if a real machine generates audio at 192Khz, the emulator generates a 192Khz source signal and filters it down to what the host can output. The repository layout reflects this, with separate top-level directories for SignalProcessing, Outputs, Storage, Machines and Processors.

Installing CLK and launching your first piece of software

The README points to two distribution channels: macOS and source releases hosted on GitHub at github.com/TomHarte/CLK/releases, and a Qt-based Linux build available as a Snap. There is no homepage listed for the project, so the releases page is the place to get a binary.

On Linux, the Snap is the shortest path. Installing it makes the clock-signal command available:

snap install clock-signal

After that, the README's workflow applies unchanged: locate a disk, tape or ROM file in your file manager and open it. CLK analyses the media, picks the machine, and issues the loading commands itself. There is no import step and no machine to create first.

If you are building from source instead, the repository root contains BUILD.md and CMakeLists.txt, and the README states that under Linux, BSD and other UNIXes and UNIX-alikes the build uses OpenGL and can be built either with Qt or with SDL. The mac build is described as a native Cocoa and Metal application, so it is not a CMake target in the same sense. Read BUILD.md for the exact flags; the README does not reproduce them.

What you should see after launching media is the emulated machine already running the title, with no intermediate machine-selection screen. On a machine whose real output was composite, expect the composite decoding described above rather than a clean pixel-perfect image.

Latency, phosphor decay and what the host actually dictates

The README's low-latency claim is specific and testable in principle. The display is an emulated CRT with phosphor decay, so a 140Hz 4k monitor can produce 140 distinct frames per second at 4k, and the README states that latency is dictated by the host hardware rather than by the emulated machine or the emulator. Audio latency is handled separately from frame rate and is described as generally restrained to 5 to 10ms.

That separation matters. In many emulators, audio and video are locked together through a single frame clock, and reducing audio latency means changing the video timing. Here the README treats them as disjoint concerns, which is consistent with the signal-processing design: the audio path has its own sample rate and its own filtering stage before it reaches the host output device.

The honest limit is in the word generally. The 5 to 10ms figure is a description of typical behaviour, not a guarantee, and the README offers no measurement methodology or test case. If sub-frame audio latency is the reason you are evaluating CLK, treat that range as a design target to confirm on your own hardware rather than a specification.

Where CLK is the wrong tool, and what to use instead

The README says the emulator attempts cycle-accurate emulation of all supported machines and that in some cases it succeeds. That sentence is the most useful one on the page. It tells you accuracy is a per-machine property here, not a blanket claim, and it pairs with the list of machines described as less rounded: the Acorn Archimedes, the Commodore Amiga and the early PC compatible.

So the clear wrong-tool case is anyone whose primary interest is the Amiga. An Amiga user wants a hard disk, a Workbench, expansion configuration and a large software library, and CLK's own README places that machine in the partial group. For the Amiga, a dedicated emulator such as FS-UAE or WinUAE is the realistic choice, and the difference is architectural: those projects model a configurable Amiga with user-supplied ROMs and storage devices, while CLK derives a machine from the media and gives you no configuration surface to adjust.

The same reasoning applies to the Archimedes and to early PC compatibles. The second wrong-tool case is automation. CLK is a desktop application whose interface is the file manager. If you need to launch a title from a script, drive it from another program, or run a headless test suite, the README describes no command-line interface, no configuration format and no API. TomHarte's own 6502 test suite and JSON-encoded test data live in separate projects and are not part of CLK's user-facing surface. For scripted emulation, a library such as MAME's or a purpose-built core is the better fit.

Maintenance, build cost and the MIT licence

The repository is not archived, and the last push was on 2026-07-23. Releases are frequent enough to suggest the project is still moving: 2026-06-06, 2026-07-20 and 2026-07-23. Maintenance status is best read from that cadence rather than from any claim on the README.

Upgrade cost depends on how you installed it. A Snap updates through the Snap store, so the Qt Linux build tracks releases without you rebuilding. A source build means recompiling against CMakeLists.txt whenever you want a newer revision, and the README's note that the Linux build can use either Qt or SDL means you are maintaining that choice yourself. On macOS the README describes a native Cocoa and Metal application, so macOS users are expected to take the hosted release rather than build.

CLK is MIT licensed. The LICENCE file sits at the repository root. MIT is permissive: it allows use, modification and redistribution provided the copyright notice and permission notice are retained, and it comes with no warranty. That last point is the practical one for anyone embedding the emulation code in another product, because the licence text disclaims liability. This is a description of the licence, not legal advice; read LICENCE and your own obligations before redistributing a build.

One cost the README does not address is ROM images. The repository contains a ROMImages directory, but the README does not document which system ROMs are bundled, which must be supplied, or what the licensing position is for each. Verify that before packaging anything.

What CLK is not promising you

Three things are absent from the README and worth stating plainly. There is no documented save-state mechanism, no documented rollback, and no documented command-line or scripting interface. If any of those are requirements, the README does not support them and you should confirm against the source before committing.

There is also no homepage. Distribution is GitHub releases plus the Snap store, and that is the entire documented surface. For a project of this scope, that is a deliberate choice consistent with the invisible-emulator stance: fewer things to configure means fewer things to document.

The screenshots in the README are presented as comparisons, with columns labelled 1:1 Pixel Copying against Composite Decoded, and 1:1 Pixel Copying against Correct Aspect Ratio, Filtered. The image files themselves are not described in text, so the visual argument has to be judged by looking at READMEImages in the repository rather than by reading a claim.

Editorial conclusion

Adopt CLK if you want a single binary that opens a ZX Spectrum tape, an Amstrad CPC disk or a BBC Micro ROM by double click, and if the signal-processing approach to composite video and audio matters to you. Do not adopt it if you need a documented scripting API, per-machine configuration files, or a polished Amiga or Archimedes experience, since the README itself calls those less rounded. Verify first that a release exists for your platform (macOS and source on GitHub, Qt Linux via Snap) and that the software you care about is on the supported list rather than the partial one.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes