qdosmsq:fs:dsed

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

qdosmsq:fs:dsed [2018/11/05 12:24]
norman created
qdosmsq:fs:dsed [2018/11/05 12:25] (current)
norman Fixed broken link.
Line 1: Line 1:
 +====== 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.
  
  • qdosmsq/fs/dsed.txt
  • Last modified: 2018/11/05 12:25
  • by norman