A latency-hating emulator of: the Acorn Electron, BBC Micro and Archimedes, Amstrad CPC, Apple II/II+/IIe and early Macintosh, Atari 2600 and ST, ColecoVision, Enterprise 64/128, Commodore Vic-20 and Amiga, MSX 1/2, Oric 1/Atmos, early PC compatibles, Sega Master System, Sinclair ZX80/81 and ZX Spectrum. - Release 2026-02-20

This release:

• addresses some but not all of the regressions in output under macOS and Metal that can cause corrupted displays. Diagnosis continues as to other issues;
• resolves an issue where systems that produce entire frames with no PCM-clocked content whatsoever — in practice most likely to be the Amstrad CPC and BBC Micro during loading transitions — would retain a static frame of output under both Metal and OpenGL;
• bundles the Amstrad CPC, ZX Spectrum, ZX80 and ZX81 ROM images into the executable for all targets per @stevexyz’s work on obtaining permission for the ZX80 and ZX81 ROMs, and my reading of Amstrad’s historical comments on the others;
• implements provisional read support for MOOF-format floppy disks; and
• forces the emulator’s characteristic slender-diagonal scan lines into strict horizontals.

On the last point: on a real CRT you get very shallow diagonals. Within the emulator you get the same. CRTs treat horizontal and vertical timing as disjoint, which makes things like interlacing and progressive each ‘just work’. It’s not about being modal, it’s a result of the general model.

But philosophically, the diagonals create aliasing and aliasing is by definition a misrepresentation of the underlying signal. CRTs definitely don’t do an essentially-horizontal line with one or two stair steps along them. So are exact horizontals actually less accurate? Another way to frame it is two potential forms of output, neither of which looks exactly like the original, and one of which has distracting artefacts.

I’ve left the door open e.g. to do diagonals on very high DPI displays but forced horizontals everywhere else, and may vacillate.