qdosmsq:fs:dsed [QDOS Internals]

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== QL ED Floppy Discs ======
This section gives some information on QL ED floppy discs

This section only covers the 3.2 Mb DS/ED floppy discs known as //QL5A// and //QL5B// There is a page dedicated to the DS/DD and DS/HD floppies [[qdosmsq:fs:dsdd|elsewhere]].

There will be a section added, at some point, describing these enhanced discs.

===== The Disc Map =====
The very first sector of an ED disc holds the first map sector. A sector is 2,048 bytes in length, unlike the other floppy formats which have 512 byte sectors.

Sector 1 of the map contains 96 bytes of disc information as follows :

^Byte^Size^Description (Byte & size are in HEX)^
|00|04|Header flag QL5B. (Same as DS/HD)|
|04|0A|Medium name space padded.|
|0E|02|Format random number.|
|10|04|Update counter for this disc.|
|14|02|Free sector count.|
|16|02|Good sector count. Normally 1,600|
|18|02|Total sector count. Normally 1,600|
|1A|02|Number of sectors per track, 10.|
|1C|02|Number of sectors per cylinder, 10 (Single sided) or 20 (Double sided).|
|1E|02|Number of tracks per disc, 80.|
|20|02|Number of sectors per block, 1.|
|22|02|Block number of the directory end of file. Zero on a freshly formatted floppy.|
|24|02|Byte in block of directory end of file. 64 on a freshly formatted floppy.|
|26|02|Sector offset per track, 2 (Same as DS/HD).|
|28|14|Logical -> physical translation table.|
|3C|24|Spare bytes, currently unused.|

The format //random number// is used to detect when the disc has been swapped.

The //update counter// is used to detect when the disc has been removed, put into
another drive, updated & then returned to the original drive.

The //sector offset// is used to allow for some sectors passing under the heads
when the drive has to step from the current track to the next one.


The remaining 1,952 bytes make up the first part of the map for this disc. The map consists of three full allocation blocks (aka 3 sectors of 2,048 bytes each as an allocation block is one sector in the DS/ED format) and can hold up to 1,600 entries although there is enough room for 2,016 potential entries in the map - these are the //allocation units//. 

Each //allocation unit// is 24 bits in length, the first
12 bits hold the file number on the disc, the last 12 bits hold the block number
within the file (starting at 0) as follows :

The allocation unit details are stored sequentially in the map. Allocation unit 0 is the first one and 1,599 is the last one. Allocation units 0, 1 and 2 refer to the map itself, which has file number $F80. 

Allocation unit 4 is the root directory, which has file number zero.

There are other values used by the QL for its own internal workings, these are held in
the first 12 bits only and the last 12 bits are ignored.

  * Blocks pending a deletion are held as file number $FCx.
  * Free blocks are held as file number $FDx.
  * Bad blocks are held as file number $FEx.
  * Blocks that do not exist are held as file number $FFx.
  
**Note:** the lower 4 bits of the file number are not used for the last 3 of
these and may be undefined. My own experience shows that they are probably $F.

An allocation block which has a file number between $001 and $F7F will
belong to a user file, although a DS/ED disc can only have 1,600 files on it as 
an absolute maximum, so you are highly unlikely to see file numbers above $640.

The sectors making up the map are as follows:

==== QL5B (DS/ED) Map Sectors ====
<code>
+----------+------------------+------------------------------+-----------------------------+
|0       95|96            2047|2048                      4095|4096                     6143|
+----------+------------------+------------------------------+-----------------------------+
| Header   | Map (1600 entries)                                               | Unused     |
+----------+------------------+------------------------------+-----------------------------+
| 96 Bytes | 1952 bytes       | 2,048 bytes                  | 800 bytes      | 1248 bytes |
+----------+------------------+------------------------------+-----------------------------+
| Sector 0                    | Sectors 1                    | Sector 2                    |
+----------+------------------+------------------------------+-----------------------------+
</code>

A DS/ED disc has 1,600 map entries (three bytes each) plus a 96 byte header making three
2,048 byte sectors in all but with the final 1,248 bytes of the last sector unused. The map is therefore 96 bytes for the header plus 1,600 * 3 = 4,800 bytes for map entries giving a total of 5,076 bytes used out of 6,144. The final 1,248 bytes are unused.

//It should hopefully be obvious that 'number of sides' * 'sectors per track' * 'number of tracks' should be the total number of allocation units on the disc.//

===== Converting A Map Allocation Unit To A Disc Address =====

The allocation unit number must be in range 0 to 1,599.

<code>
The TRACK number is the UNIT DIV 'sectors per cylinder'.
The LOGICAL BLOCK number is the UNIT MOD 'sectors per cylinder'.
</code>

This gives TRACK from 0 to 'number of tracks' -1, and LOGICAL BLOCK within TRACK as 0 to 'sectors per cylinder' -1.

The offset into the Logical -> Physical table for this logical block is:

<code>
(logical block * 'sectors per block') + 1
</code>

assuming you are in SuperBASIC and count from 1 otherwise lose the 1.

The sector number for this logical block is the byte at offset 0 from the
calculated offset into the Logical -> Physical table.

Now for each sector number, if it is greater or equal to 128, then the side is
1 and the adjusted sector = sector - 128, otherwise the side is 0.

This is fine if we are still on track 0, however, as mentioned above, there is
a track offset to be taken into account as follows :

<code>
(adjusted sector + (TRACK * 'track offset')) MOD 'sectors per track'
</code>

this gives a 0 to 'sectors per track' -1 result, in SuperBASIC you would need to add 1 to get a true sector number of 1 to 9. In Assembly or C code, this is not required.

Now you have a SIDE, TRACK and the sectors for this allocation unit. Easy.

==== SuperBASIC EXAMPLE ====
Allocation unit 423:

<code>
TRACK     = 423 DIV 20 ===> 21.
BLOCK     = 423 MOD 20 ===>  3.
LP_OFFSET = (BLOCK * 1) + 1 ===> 4.
</code>

Assume that the LP table has byte $06 at LP_OFFSET:

<code>
LP_OFFSET byte = $06
SIDE = 0
ADJUSTED SECTOR = 6
</code>
As above, the sector offset is 2 (normally)

So the actual sector on track 21 of side 0 is:

<code>
(6 + (21 * 2)) MOD 10) ====> 8
</code>

Therefore, the sector of the disc that are used by the file are located at

SIDE 0, TRACK 21, SECTOR 8.

The file in question is of course unknown, but if you take the 24 bits held in
the 3 characters of the map that relate to this allocation unit and convert
them into hex, you will get something like $007002 which means that the actual
file number is 7 and the block within the file is 2.


===== Finding The File In The Directory =====
If the file number is not a 'special' as listed above, then the file name is
found as follows :

<code>
DIR_OFFSET = (File number - 1) * 64
</code>

it appears that there is no way to access the directories own information from
the directory, hence the minus 1.

The next 64 bytes of the directory hold all the information for that file,
including its name, dataspace, type etc etc.


The first 64 bytes of each files very first sector contain a copy of the file
header, this is never ever ever updated by the QL, so is of no use at all. All
it does is waste 64 bytes per file and eventually, as the disc gets used and
files deleted with others saved, these 64 bytes seem to contain what ever data
was on the disc when the file was written to the sector.


===== Deleted Files In The Map =====
When a file gets deleted, its map entries have the first byte set to $FD, the
other information in the map does not seem to be affected. This is slightly
unfortunate as it means that an UNDELETE program could not be entirely
successful as there could be more than one file in the map which had been
deleted from the disc.