From the Sinclair wiki page “SCL format”, read through a summarising fetch tool: “our words”. The page’s data table is inconsistent (it labels a row “file header entry” where it means file data); the sector-based sizes are the reliable part.
Layout
A header of 9 bytes, then n descriptors of 14 bytes, then the data of the files, then a checksum. The size of a well-formed file is 9 + 14 × n + 256 × (the sum of the files’ sectors) + 4.
Header
| Offset | Size | Meaning |
|---|---|---|
$00 | 8 | The signature, the characters SINCLAIR |
$08 | 1 | The number of files, n (a TR-DOS catalogue holds 128) |
Descriptors
From offset 9, n descriptors of 14 bytes: the TR-DOS descriptor without its last two bytes (the first sector and the first track):
| Offset | Size | Meaning |
|---|---|---|
$00 | 8 | Name |
$08 | 1 | Type: B, C, D or # |
$09 | 3 | The parameters, which depend on the type: the two bytes of the TRD descriptor at $09 and $0B (the page gives them as three bytes; the TRD page’s layout is two bytes at $09 and two at $0B, so the viewer reads $09 and $0B as the TRD does) |
$0D | 1 | The length in sectors |
Data
From offset 9 + 14 × n: each file’s data, its number of sectors times 256 bytes, in the order of the descriptors, with nothing between. On a TR-DOS disk the files would start at logical track 1, sector 0 and follow one another.
Checksum
The last 4 bytes. The Sinclair wiki page we read does not document it, but two other sources do (checked 2026-11-14): the Spectrum FAQ, file formats section (rk.nvg.ntnu.no/sinclair/faq/fileform.html), says the sectors are followed by “a 4 bytes long simple sum (not a checksum!) of all the previous bytes in the file”, and the FlashFloppy issue 145 (github.com/keirf/FlashFloppy/issues/145) says “the last 4 bytes are the control sum (the arithmetic sum of all previous bytes)”. Neither states the byte order; the FAQ’s general rule that values are little-endian unless stated otherwise is what the viewer follows (our inference). The viewer therefore compares the stored number with the sum of all the bytes before it, modulo 232, little-endian, and says “differs” when it does not match. Both sources were read through a summarising fetch tool (our words), and no real SCL file was available to confirm the byte order.
Not described
Known, not yet covered
- Nothing known is missing from the layout; the conversion to a TRD image is not done by the viewer.
Unknown
- The byte order of the checksum (little-endian is inferred, see above); the exact meaning of the three parameter bytes in a descriptor.