ZX Spectrum system photo: Dr. Bernd Gross, CC BY-SA 4.0, via Wikimedia Commons.
Sinclair Research launched the ZX Spectrum in the UK in April 1982: a Zilog Z80A CPU, 16 or 48 KB of RAM, and a rubber "dead-flesh" keyboard, all undercutting rival home computers on price. A single custom chip, the ULA, generated video directly from memory with no dedicated color RAM — a cost-saving design that gave the Spectrum's screen its famous "attribute clash" look, and its own small ecosystem of software tricks built around working past that limit. Later models — the 128K, +2, and +3 — added more memory, a proper keyboard, and (eventually) a floppy drive, but the core 256×192 display stayed the same throughout, and so did the format family built on top of it.
Every format below is a variant of the same fixed 256×192 screen: 6,144 bytes of 1-bit-per-pixel bitmap, split into three 64-line thirds with a non-linear, interleaved line order, plus 768 bytes of color attributes — one byte per 8×8 pixel cell, each byte picking one of 15 colors for "ink" (set pixels) and another for "paper" (clear pixels) within that cell. Nearly everything on this page is either that raw layout wrapped in a different container, or a software trick for getting more color out of it than the hardware wanted to allow. What's below is what survives of that: still opened today by ZX Spectrum emulator users, homebrew developers, and demoscene preservationists.
| Format | Extension | Kind | Introduced |
|---|---|---|---|
| Screen, Snapshot & Tape | .scr, .sna, .tap | Bitmap & container | 1982 / early 1990s |
| Multicolour | .mc, .mlt, .ifl | Hi-color bitmap | 1985 / 2011–2016 |
| Gigascreen | .gsc, .img, .hlr, .mg1–.mg8 | Truecolor bitmap | early 1990s |
| FZX Font | .fzx | Proportional bitmap font | 2013 |
These three formats all carry the exact same thing — the Spectrum's raw SCREEN$
memory image — wrapped for a different purpose: a bare picture file, a full-machine emulator
save state, or a cassette-tape recording.
| Aspect | Detail |
|---|---|
| SCR (Screen) | 6,912 bytes: the 6,144-byte bitmap plus the 768-byte attribute block, dumped exactly as they sit in memory at $4000–$5AFF |
| SNA (Snapshot) | 27-byte Z80 register header followed by a full RAM dump from $4000, so the screen sits at a fixed offset (27) inside a 49,179-byte (48K) or 131,103/147,487-byte (128K) file |
| TAP (Tape) | A stream of length-prefixed blocks, byte-for-byte what the Spectrum ROM's own SAVE routine writes to cassette; a screen is stored as a 6,912-byte "code" block |
| Extensions | .scr, .sna, .tap |
None of these three has a single inventor — each is a case of a program simply dumping
what the Spectrum's own hardware and ROM already handed it. SCR is nothing more than the
display file as it sits in memory: Sinclair BASIC could save one directly with
SAVE "pic" SCREEN$, a built-in command available from the machine's
launch in 1982, so any program that wanted to save a picture already had the format for
free. TAP is much the same story one level up: it is exactly the sequence of bytes the ROM's
tape-saving routine writes to cassette, minus the analog pilot-tone and timing information a
real tape recording also carries — which is also why the later, richer TZX format exists, to
capture the custom "turbo loaders" many commercial games used that TAP's plain block
structure can't represent. Several early-1990s Spectrum emulators, including Gerton Lunter's
DOS-based "Z80" emulator, converged on the same simple block-length-plus-raw-bytes convention
for TAP.
SNA is the odd one out in being tied to a specific piece of hardware rather than the ROM
itself: its 27-byte register header plus full RAM dump layout originates from the Mirage
Microdriver, a real Spectrum peripheral interface. From there it was picked up for
emulator save states — first, per the Sinclair Wiki, in Peter McGavin's "Spectrum" emulator
for the Commodore Amiga, then adopted by Arnt Gulbrandsen's MS-DOS emulator JPP, which is
likely where the .sna extension itself took hold. The format was later extended
to cover 128K machines, developed around the Pentagon 128, a Russian clone popular in the
demoscene.
All three remain the baseline formats of ZX Spectrum preservation and emulation. Fuse, the
reference Spectrum emulator, loads and saves SNA snapshots and TAP tapes (alongside the
newer Z80/SZX and TZX/PZX formats) through its shared libspectrum library, and
the same trio is supported across other current emulators like EightyOne and ZEsarUX. SCR
itself is still a live interchange format outside any emulator too, readable by tools like
ImageMagick, XnView, and RECOIL, and produced by a steady stream of modern homebrew
conversion utilities.
Paintapp reads standard 6,912-byte SCR screens (and the rarer 6,144-byte bitmap-only variant, rendered without color as a mono fallback), extracts the screen from a 48K or 128K SNA snapshot at its fixed offset, and scans a TAP tape image for its embedded 6,912-byte screen data block.
Multicolour is the Spectrum's answer to its own attribute-clash problem: instead of one color-attribute byte per 8×8 pixel cell, the attribute is rewritten every single pixel row, giving each 8×1 strip its own ink and paper colors. On real hardware this means reprogramming the attribute data in careful sync with the ULA's own screen-drawing timing — a cycle-counted software trick played out over every one of the screen's 192 lines, not a hardware feature.
| Aspect | Detail |
|---|---|
| Technique origin | No single inventor; commercial games experimented with line-by-line "rainbow graphics" attribute changes as early as 1985, and the demoscene was using the same idea by the late 1980s |
| Format & tooling origin | Andrew S. Owen's ZXodus Engine (2011) and Einar Saukas's BIFROST* (2012), BIFROST*2 (2016), and Nirvana (2013) Engines turned the trick into reusable authoring tools and the .mc/.mlt/.ifl file formats |
| Resolution | .mc/.mlt: one attribute byte per 8×1 pixel strip (12,288 bytes); .ifl: one attribute byte per 8×2 strip, a coarser variant (9,216 bytes) |
| Related hardware mode | The Timex TC2048/TS2048, a Spectrum-compatible clone, offers the same 8×1 hi-color resolution natively via its Timex SCLD chip, reachable in this codebase's reader as a 12,288-byte .scr variant |
| Extensions | .mc (Multicolour), .mlt (Multicolour), .ifl (8×2 hi-color), .scr (Timex TC2048 hi-color, 12,288-byte variant) |
The underlying raster trick has no single credited inventor and no one founding demo —
it shows up in commercial software as early as 1985's Hyper Sports (Imagine
Software/Ocean), and demoscene productions were already using line-by-line attribute
effects by 1989–1990, well before it had a name or a reusable tool behind it. What did
eventually crystallize into a proper format family was the authoring side: Andrew S. Owen's
ZXodus Engine, released free in 2011, and Einar Saukas's BIFROST* Engine the following
year (with sample tiles by Dave Hughes) gave developers a general-purpose way to build
multicolour graphics into real games rather than hand-coding the trick from scratch every
time. Saukas followed with the coarser 8×2 variant in his Nirvana Engine (2013) — the
.ifl format here — and a wider BIFROST*2 Engine in 2016, with Nirvana later
integrating into the Boriel ZX BASIC and z88dk toolchains.
The Timex Sinclair 2048's clone maker, Timex Portugal, took a different route to the same result: rather than a software trick, its Timex SCLD video chip generates 8×1 hi-color resolution natively as a selectable hardware mode. The TC2048 launched in Portugal in 1984 (Polish production followed from 1986, and an NTSC version shipped in Chile) and was discontinued in 1989; nothing found here connects its hardware approach to the later software-trick lineage above beyond arriving at the same visual result by different means.
Multicolour graphics remain a live part of ZX Spectrum homebrew development today, largely
through the Nirvana and BIFROST* engine lineage. On the tooling side, the Windows converter
DaDither treats SCR, IFL, MLT, and MC as one recognized sibling format family, converting
ordinary image files into any of them — a good sign of how standardized this format group
has become. Fuse, the reference Spectrum emulator, is confirmed to render Timex hi-color
.scr screens and .mlt images; its support for the plain
.mc/.ifl extensions specifically wasn't confirmed in researching
this page, though nothing suggests it's absent either.
Paintapp decodes Multicolour (.mc) and its .mlt counterpart as a
single 256×192 indexed frame with a per-scanline attribute, the coarser 8×2
.ifl variant with a per-two-scanline attribute, and the Timex TC2048 hi-color
.scr variant through the same per-scanline decode path.
Gigascreen takes a different approach to the same problem: rather than changing attributes faster, it stores two complete standard screens and flickers between them at 50 Hz. On a real CRT, the eye fuses the two images into one, perceiving colors between the Spectrum's normal 15 — a software trick that trades resolution in time for resolution in color, much like interlacing in reverse.
| Aspect | Detail |
|---|---|
| Origin | No single credited inventor found; an emergent demoscene technique, in use by at least the mid-1990s and still actively used today |
| How it works | Two full 256×192 screens (bitmap + attributes each) are stored back to back and blended by averaging each pixel's color between the two frames |
| Effective colors | Commonly cited as around 100 on screen at once, though the exact figure varies by source and is inherently approximate — the real effect depends on CRT phosphor persistence, not a fixed digital blend |
| Related variants | .hlr — a rarer, undocumented-origin gigascreen variant with no real bitmap, just a repeating 8-byte dither pattern and two attribute maps; .mg1–.mg8 ("MGH") — a mixed 8×8/8×1 gigascreen scheme from deMarche's MultiArtist editor (2009–2010), blending standard attributes at the screen edges with per-scanline hi-color down the center |
| Extensions | .gsc, .img (standard two-frame gigascreen), .hlr, .mg1–.mg8 |
Unlike Multicolour, no source found while researching this page credits a specific
programmer, group, or founding demo with inventing Gigascreen — English- and
Russian-language demoscene references alike describe it only as a technique that emerged
from the ZX Spectrum scene, in active use by the mid-1990s. The MultiArtist editor behind
the .mg1–.mg8 "MGH" variant is better documented: built by a
scener known as deMarche around 2009–2010, it extends the same flicker-fusion idea across
four selectable attribute resolutions (8×8, 8×4, 8×2, and 8×1, the last matching
Multicolour's own per-scanline resolution down the center band of the image). The .hlr
variant's byte layout is documented by more than one modern conversion tool, but nothing
found credits it to a specific author or tool by name.
Gigascreen is still an active category in ZX Spectrum demoscene graphics competitions today, with dedicated "gigascreen" and "multigigascreen" divisions at demoparties distinct from plain single-screen art — Artfield 2015's gigascreen compo, won by Dimidrol's "Capri rendezvous," is one well-documented example, and new gigascreen artwork continues to be released as recently as a December 2023 piece published in WOOT! Tape Magazine.
Paintapp decodes standard two-frame Gigascreen images (.gsc/.img,
including the 128-byte-header variant) into a blended truecolor image, along with both
related variants: .hlr's dither-pattern-plus-two-attribute-maps scheme, and the
full .mg1–.mg8 "MGH" family's mixed standard/hi-color attribute
layout.
FZX is a proportional bitmap font format for the ZX Spectrum — variable character widths and kerning instead of the ROM font's fixed 8×8 monospace grid, aimed at homebrew software that wants better-looking text than the stock character set allows.
| Aspect | Detail |
|---|---|
| Format design | Andrew S. Owen |
| Rendering driver | Einar Saukas, with sample fonts assisted by Paul van der Laan |
| Announced | June 2013, on the World of Spectrum forums |
| Character range | A configurable run starting at ASCII 32, with per-character width, kerning, and vertical-shift metadata alongside packed 1-bit glyph bitmaps |
| Extensions | .fzx (FZX Font) |
Einar Saukas — also known for the ZX7 and Salvador compression tools in the same community — announced FZX on the World of Spectrum forums in June 2013 as "a new standard format and driver for proportional fonts," crediting Andrew S. Owen with designing the format and sample fonts, assisted by Paul van der Laan. It was built to give Spectrum BASIC and assembly software a way to render proportional text without hand-rolling a custom font engine each time.
FZX support is built into z88dk, the actively maintained Z80 C cross-development
toolchain, and FZX fonts show up regularly in ZX Spectrum Next homebrew projects. The
format itself has been stable since its 2013 introduction, but its tooling remains
current: the cross-platform bitmap font editor Bits'N'Picas reads and writes
.fzx files and, as of this writing, is still under active development.
Paintapp reads FZX fonts as a proportional bitmap font, decoding each character's individual width, kerning, and vertical shift alongside its packed 1-bit glyph data.
A few more ZX Spectrum formats round out Paintapp's support — narrower in scope than the ones above, but real:
| Format | What it is | Paintapp support |
|---|---|---|
ATR | A 768-byte attribute-only "preview" file — no real bitmap, just the color attribute block, rendered with a synthetic checkerboard pattern standing in for the missing pixels | Decoded |
CH4/CH6/CH8 | A packed black-and-white font/character-set sheet, laid out as 32 glyphs per row | Decoded |
RGB/RGB3 | Three stacked attribute-less bitmaps, one per color channel, combined into a single truecolor image | Decoded |
ZXP | A plain-text image format from ZX-Paintbrush, a modern PC editor for ZX Spectrum graphics, with an optional embedded 64-color ULAplus palette | Decoded |