On PC disks, sectors are arranged "linearly" as follows: the first sector
of the disk is located on the first sector of the first track. Reading then
proceeds through each sector of the first track, then the sectors from the
first track on the opposite side of the disk are read. Reading then proceeds
to the second track back on the first side, and the sequence repeats.
For the QL disks, things are different. I am not sure what the reason
for the different layout is - it may be for efficiency or perhaps it was
easier to program. The file system is based on logical
blocks that are 1536 bytes in length (three sectors). These blocks are
"interleaved" within a track - sectors alternate between the three blocks
stored on the track. So, a track actually looks like this:
The above two paragraphs might not be completely accurate. Since writing this document, I discovered the concept of sector interleaving that was used to give the CPU time to to process data as it was read from disk. So that explains the unusual sector ordering. But as the disks were read from a PC, I'm unsure whether the ordering is the result of PC floppies being interleaved or because QL floppies are interleaved.
To read a complete block, you must therefore read the first sector, jump forward three sectors, read the second sector, then jump forward three more sectors and read the third sector.
Sector Details 0 Block 0, Sector 0 1 Block 1, Sector 0 2 Block 2, Sector 0 3 Block 0, Sector 1 4 Block 1, Sector 1 5 Block 2, Sector 1 6 Block 0, Sector 2 7 Block 1, Sector 2 8 Block 2, Sector 2
In fact, things are more complicated than that. The blocks are grouped by track and read from alternate sides, so the first block is read from the first side, while the second block is read from the second side, etc. The sector layout actually looks like this:
In fact, it's even more complicated than that! The above diagram is accurate for the first track on the drive; however, on each track, the sectors are offset by an amount equal to the track number multiplied by four, so the second track has an offset of 4, the third has an offset of 8, etc. This is what the second track (offset of 4) looks like:
Side 0 Side 1 Sector Details Sector Details 0 Block 0, Sector 0 0 Block 1, Sector 0 1 Block 2, Sector 0 1 Block 3, Sector 0 2 Block 4, Sector 0 2 Block 5, Sector 0 3 Block 0, Sector 1 3 Block 1, Sector 1 4 Block 2, Sector 1 4 Block 3, Sector 1 5 Block 4, Sector 1 5 Block 5, Sector 1 6 Block 0, Sector 2 6 Block 1, Sector 2 7 Block 2, Sector 2 7 Block 3, Sector 2 8 Block 4, Sector 2 8 Block 5, Sector 2
Side 0 Side 1 Sector Details Sector Details 0 Block 8, Sector 1 0 Block 9, Sector 1 1 Block 10, Sector 1 1 Block 11, Sector 1 2 Block 6, Sector 2 2 Block 7, Sector 2 3 Block 8, Sector 2 3 Block 9, Sector 2 4 Block 10, Sector 2 4 Block 11, Sector 2 5 Block 6, Sector 0 5 Block 7, Sector 0 6 Block 8, Sector 0 6 Block 9, Sector 0 7 Block 10, Sector 0 7 Block 11, Sector 0 8 Block 6, Sector 1 8 Block 7, Sector 1
To read a file, the blocks with that file number are read in sequence, for each sequence number in succession. For example, to read file 5, a three block file, the blocks with entries (5, 0), (5, 1) and (5, 2) are read.
The contents of each file are prefixed with a 64 byte header, with the exception of the directory file (which is file 0). This appears to be left over from the old microdrive format. The header contains a copy of the file's name, but this does not seem to be updated when the file is renamed. The "definitive" name for the file is stored in the file's entry in the directory. Other than this, there seems to be no other useful information stored in the header.
When extracting files, it is worth noting that QL filenames can contain '/' characters, which cannot be used in filenames on Unix systems. They can also contain various other characters that cannot be used in filenames under various other operating systems (eg. Windows).
Offset (hex) Length (hex) Purpose 0 4 File length E 2 16-bit filename length 10 24 Filename 34 4 Modification date
The modification date uses a similar scheme to Unix time in counting seconds since an epoch; however, the epoch is different. Unix time measures seconds since 1970, but the epoch here is 1961 (for reasons unknown to me). To convert to Unix time, simply subtract 284000400. I was able to calibrate this by using various text files on the disks that I examined that contained textual representations of the date and time that they were created.
Deleted files have their length and filename length fields set to zero, so it is possible to recover files after they have been deleted.