_______________________________________ |+ +| | | | AMIGA DISK STRUCTURE | | | |+ +| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ by Steve Wright ===========================================================================   Wouldn't it be nice to have a common operating system for all computers and be able to buy off the shelf software for many makes of machines. Of course differences in hardware design and applications make this impossible, but it is possible to have a common Operating.System (O.S.) among similar machines &/or processors. e.g. 68000 - UNIX, 80xx - MS/DOS, etc. The popularity of the IBM PC range and compatibles has proven this to be an advantage. With every new model the manufacturer adopts an O.S. which they feel suits the machine best and realizes the machines full potential. Commodore when designing the Amiga is no exception. Common O.S. is no guarantee of common disk file structure. e.g. both the NEC APC and the IBM PC run MS/DOS, and the disks are not interchangeable. Most machines are different in the way they write information to disk in either encoding & decoding of data &/or packing and sectoring the stream of data. If common disk file structures along with O.S. exist, many books would be available to understand fully its operation, but for us Amigans we have the Amiga Dos Manual and the ROM Kernal Reference Manuals. These manuals are poorly written and very cryptic in their information. It is for this reason that I have written this small article in plain English, so the next time you pick up one of these manuals, it may make a little more sense. I don't intend to go into any depth as further information can be sort in these manuals. Disk encoding and decoding. ~~~~~~~~~~~~~~~~~~~~~~~~~~~ The Amiga is capable of working with two recording methods, MFM (Modified Frequency Modulation) and GCR (Group Code Recording). Both of these methods are of a double density type and achieve about 80% efficiency. MFM has been adopted as the standard because of its speed and efficiency (twice the speed of GCR). MFM is a modified version of FM. FM is single density and is the norm for the IBM disks, and achieves about 50% efficiency, that is, 50% of the disk contains data, the rest is clocking information or for every data bit there is a clock pulse. For MFM, clock pulses are present between two consecutive "0" bits, thus freeing up disk space. Any disk recording method has a encoding and decoding method, ensuring error free writing and reading. MFM uses a grouping method of odd bits first, followed by even bits. The two groups when decoded are AND separately and OR'd together. Decoding 8 MFM bytes produces 4 decoded bytes. MFM encoding and decoding method sync's the bits for accurate retrieval and reduces the incidence of repeated "0" bits. Disk format ~~~~~~~~~~~ The Amiga formats its disk into 160 tracks, 80 cylinders both sides and has 11 sectors each track, cylinder 0 has the longest track being on the outside. Each sector has a block of data each 512 bytes. Thus :- 160 * 11 * 512 = 901120 bytes ------ 1024 (1k) = 880k bytes Each sector is organised into 6 sections :- 1 - Sync bytes; MFM 44894489, GCR A1A1. ( This tells the computer that it's at the start of a sector.) 2 - Header information; ( Sector information ) byte 1 - $FF " 2 - Track number. " 3 - Sector number. " 4 - Sector offset ( 11 less sector number). 3 - O.S. recovery data, 32 MFM AA's, 16 decoded 00's (nulls) ( Reserved by Commodore for future use ). 4 - Header checksum. 5 - Data block checksum. 6 - Data block. There are 11 sectors on each track organised as above, end on end. Between the first and last sector is a gap. Commodore fills this space with a string of nulls ($00) which are AAAA in MFM. This string of nulls is written before the data information to ensure the complete track has been encoded with valid bit patterns. Filing system ~~~~~~~~~~~~~ The AmigaDos filing system consists of directories and files arranged in a hierarchical tree method. That is each directory may hold more directories &/or files, and so on indefinitely. There is one master directory called the Root Block. This is the only directory that is consistent with its physical location on the disk, which is block number 880 or cylinder number 40 - top side. Every one of the 1760 blocks has either a directory, file or file information and can be one of five types : root block, user directory block, file header block, file list block, data block. Each block has 512 ($1FF) bytes of information or 128 * 32 bit slots. Other than data and string information, all block information is within these slot boundaries. Root block ~~~~~~~~~~ Slot 0 /byte $00 - $02 " 1 / " $04 - $00 " 2 / " $08 - $00 " 3 / " $0C - Hashtable size (blocksize - 56) Blocksize = 128 less 56 slots = 72 slots avaliable. " 4 / " $10 - $00 " 5 / " $14 - Checksum (used to check for read errors). " 6 / " $18 - Hashtable. This is like Telecom's directory assistance, tell them a name and receive a number in return. Do a hash function on a file or directory and this returns an offset in the hashtable. This offset points to the block number of the file or directory. A hashtable is just block numbers of files or directories associated with the current directory. " 78 / " $138 - Bitmap flag ($01 = valid, $00 = not valid). " 79 / " $13C - Bitmap pages Used to indicate the blocks containing the bitmap. " 105/ " $1A4 - Days, min, ticks. Date and time of volume last altered. " 108/ " $1B0 - Disk name (e.g. Workbench, Mydisk, etc). " 121/ " $1E4 - Create days,min,ticks (creation date and time of volume). " 124/ " $1F0 - $00 " 125/ " $1F4 - $00 " 126/ " $1F8 - $00 " 127/ " $1FC - $01 User directory block ~~~~~~~~~~~~~~~~~~~~ Slot 0 /byte $00 - $02 " 1 / " $04 - Header key (self pointer). " 2 / " $08 - $00 " 3 / " $0C - $00 " 4 / " $10 - $00 " 5 / " $14 - Checksum. " 6 / " $18 - Hashtable. " 78 / " $138 - Spare. " 80 / " $140 - Protection bits. Indicates flag status for read,write,delete & execute. " 81 / " $144 - $00 " 82 / " $148 - Comment (e.g. Music_created_using_Soundscape). " 105/ " $1A4 - Days,min,ticks. Creation date and time. " 108/ " $1B0 - Directory name (e.g. Studio_music). " 124/ " $1F0 - Hashchain. To give us an almost endless supply of sprouting directories and files (space allowing), more than one directory or file may be allocated to the same hashtable offset of its parents directory. So when the Amiga is seeking for a directory or file it looks at the block indicated by the parents hashtable offset and if not found it goes to the block pointed to by the hashchain and so on till it's found. If many directories or files exist this hashchain may be fairly long. " 125/ " $1F4 - Pointer to parent directory. " 126/ " $1F8 - $00 " 127/ " $1FC - $02 File header block ~~~~~~~~~~~~~~~~~ Slot 0 /byte $00 - $02 " 1 / " $04 - Header key. " 2 / " $08 - Highest sequence number. Total number of blocks in file. " 3 / " $0C - Data size. Number of data blocks slots used. " 4 / " $10 - Fist data. Pointer to first data block. " 5 / " $14 - Checksum. " 6 / " $18 - List of data block keys. Data blocks are read sequentially starting from slot 77 (byte $134) moving upwards to slot 6 (byte $18). " 78 / " $138 - Spare. " 80 / " $140 - Protection bits. " 81 / " $144 - Total size of file in bytes. " 82 / " $148 - Comment. " 105/ " $1A4 - Days,min,ticks (creation date and time). " 108/ " $1B0 - File name. " 124/ " $1F0 - Hashchain. " 125/ " $1F4 - Pointer to parent directory. " 126/ " $1F8 - Extension. Of course, on a large file not all the data block pointers will fit in the 72 slots of the data block key list. A number of file list blocks is created to hold the remaining key pointers. A $00 is inserted if not needed. " 127/ " $1FC - $FFFFFFFD File list block ~~~~~~~~~~~~~~~ Slot 0 /byte $00 - $10 " 1 / " $04 - Header key. " 2 / " $08 - Number of data blocks in block list. " 3 / " $0C - Number of data block slots used. " 4 / " $10 - First data block. " 5 / " $14 - Checksum. " 6 / " $18 - Extended list of data block keys. Used in the same fashion as the file header block. " 78 / " $138 - Unused. " 124/ " $1F0 - $00 " 125/ " $1F4 - Pointer to file header block. " 126/ " $1F8 - Next extension block. $00 if not needed. " 127/ " $1FC - $FFFFFFFD Data block ~~~~~~~~~~ Slot 0 /byte $00 - $08 " 1 / " $04 - Header key. Points to file header block. " 2 / " $08 - Sequence number of the data block. " 3 / " $0C - Number of slots of data. Generally 121 (blocksize - 6), less if last in sequence. " 4 / " $10 - Pointer to next data block in sequence. $00 if last in sequence. " 5 / " $14 - Checksum. " 6 / " $18 - Data. Example ~~~~~~~ As a simple example let us go through what we have just learnt. Assuming we are in CLI and we are seeking to load a program from within a user directory. The program is called "MyProg", the directory is called "MyDir" and many files exist within this directory. For simplicity no error trapping or checking is covered: 1- Type from CLI "MyDir/MyProg". 2- A Root block hash is done on the directory name "MyDir". 3- An offset then points to the block number within the hashtable (say 920) 4- Drive head now moves to block 920 (user directory block). 5- A check is now done to see if the directory name matches the it is seeking (slot 108). If there is no match the drive head is moved to the block number pointed to by hashchain (slot 124) where the check is done again, and so on till the directory is found. Let's assume it found the directory on the first leg of the chain (block 920). 6- A User directory block hash is now done on the file name "MyProg". 7- Again, an offset points to a hashtable slot. Say 950. 8- Drive head moves to block 950 (file header block). 9- Check file name : negative (see 5 above). 10- Move disk head to block pointed to by hashchain (slot 124) say 960. 11- Check file name : OK. 12- Slot 4 points to the first data block in sequence, say 300. 13- disk head moves to block 300. 14- Load data from block (slot 6-127). 15- Move disk head to next data block pointed to by slot 4 (next data block pointer) and so on till the complete file is loaded. Of course much more happens than indicated above, but it gives an idea of the procedure involved. This information is vital if ever you need to reconstruct a corrupt block. There exist many good public domain and commercial utility programs to view individual blocks &/or files: Mirror hackers pack, Filezap, Sector edit just to name a few. Remember work with COPIES only. Till next time..................Steve Wright  _____________________END OF DISKSTRUCTURE___________________________