FGCBA10@BLEKUL11.BITNET (07/01/86)
Date: Tuesday, 1-Jul-86 9:07 MET
From: Luc Dekens <FGCBA10@BLEKUL11.BITNET>
Subject: diskorganization on ST
To: INFO-ATARI16@SU-SCORE.ARPA
Hi, is there anybody out there how could give me some info
concerning the disk-structure. I know where to find the bootblock
and how it is organized, but I'm in the dark what concerns directory-
organization, allocation tables and so on.
Luc Dekens FGCBA10@BLEKUL11.BITNET
Chemistry Department
University of LEUVEN
Belgiumturner@imagen.UUCP (07/05/86)
> Date: Tuesday, 1-Jul-86 9:07 MET > From: Luc Dekens <FGCBA10@BLEKUL11.BITNET> > Subject: diskorganization on ST > To: INFO-ATARI16@SU-SCORE.ARPA > > Hi, is there anybody out there how could give me some info > concerning the disk-structure. I know where to find the bootblock > and how it is organized, but I'm in the dark what concerns directory- > organization, allocation tables and so on. > > Luc Dekens FGCBA10@BLEKUL11.BITNET > Chemistry Department > University of LEUVEN > Belgium ~~~~~~~~~~~~~~~~~\ lineater, \~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ask and thou shalt receive... ST Disk Directory For those of you that have gone from the 8-bit ATARI computers to the 16-bit ATARI ST's, there have been many surprises for you in the past months. Among them is probably " What do I do with all of this extra memory.", or maybe " The graphics on this system sure are something." and one of my favorites, " That disk holds a lot of data." All of these statements are true for obvious reasons. For the longest time there was only 48K of ram available in the ATARI Systems, so jumping to 512K is a fantastic leap. The same holds true for the graphics capability of the new ATARI, by going to a monitor and improving the resolution, another big leap has been made. But, one of the most important improvements to me has been the disk storage. After using an ATARI 810 disk drive for several years, going to 360K per disk is great. Now, since I have that off my chest, I would like to go a little deeper and try to explain some of the differences in the way the ST disks (single sided) are handled. The ST disk is divided into 80 tracks (0 thru 79), 9 sectors per track (1 thru 9), and is written in QUAD density (512 bytes per sector). When a disk is formatted, a Boot sector (track 0, sector 1), the File Allocation Tables (it starts at track 0, sector 2) and the Directory (it starts at track 1, sector 3) are established using all 18 sectors in the first two tracks. The remaining sectors (tracks 2 thru 79, sectors 1 thru 9) are initialized in pairs or by cluster (two sectors = one cluster). As a cluster is initialized the File Allocation Table (F.A.T.) is updated to indicate the status of the cluster; this continues until all 351 data clusters have been completed. If a cluster cannot be formatted or initialized, the corresponding entry in F.A.T. is marked not-available and will remain that way until the disk is re-formatted or thrown-away. If a cluster is marked as bad, the F.A.T. entry will contain a number between $FF0 and $FF7. That range of numbers simply means the cluster is un-usable and will never used to store data. The ST disk uses track 2, sector 1 thru track 79, sector 9 to store any files you write to the disk. All filenames are listed on the disk directory in the order they are entered. The directory is seven (7) sectors long and has room for 112 entries, with each entry being 32 bytes in length. Each entry contain the Filename and Extension, the file Attributes, the Time the last change was made to the file, the Date the last change was made to the file, the number of the first cluster in the file, and the length (in bytes) of the file. In addition, there are 10 bytes that have been reserved for future use (see fig.1). fig.1 ST Directory Fields 1) Filename 8 bytes bytes 0 thru 7 2) Filename Ext. 3 bytes bytes 8 thru 10 3) Attributes 1 byte byte 11 4) RESERVED 10 bytes bytes 12 thru 21 5) Time of Last Change 2 bytes bytes 22 and 23 6) Date of Last Change 2 bytes bytes 24 and 25 7) First Cluster Number 2 bytes bytes 26 and 27 8) File Size (in bytes) 4 bytes bytes 28 thru 31 The Filename and Extension are the first two fields in each entry of the directory. They take up the first 11 bytes of an entry and follow the same format as the ATARI 800 or the IBM PC, with one small exception. If the first character of an entry is $E5, the file has been deleted and is no longer available for your use. If no changes have been made to the disk since the file was deleted, it may be possible to recover it by using one of the many sector editors available. The Attributes field is one byte long and contains a number that indicates any special or unique characteristics about this entry. There are only five bits of the entry used on the floppies at this time, and they are listed in Fig. 2. fig.2 Attributes Bit 0 = Read Only (not set if the file is Read-Write) Bit 1 = Hidden Bit 2 = System Bit 3 = Volume Label (Name assigned to the disk) Bit 4 = Sub-Directory (Folder Name) Bit 5 = Archive (This will be used on the Hard Disks) Bit 6 & 7 are not used at this time The next field is marked RESERVED and is 10 bytes long. This field will be filled with 00's on all disk entries and no plans for its use are known at this time. The Time of Last Change field is 2 bytes long and is updated each time you write to a file. This field contains the HOURS, MINUTES, and SECONDS(/2) of the last change to the file. This field is in the low-byte, high-byte format and uses all 16 bits. Starting with the highest bit, it uses 5 bits for the Hour, 6 bits for the Minutes and the last 5 bits for the Seconds. (The value in the seconds portion of the field must be multiplied by 2 to get the correct seconds count.) The Date of Last Change field is handled almost the same as the previous field. This field is changed along with the Time of Last Change, and is also in the low-byte, high-byte format. Starting with the highest bit, use 7 bits for the Year, 4 bits for the Month, and the last 5 bits for the Day. Don't be to surprised when the year equals a 5 (as most files will) because the year stored has 1980 subtracted from it. The First Cluster field contains the number of the first cluster used for the file. The cluster information is stored in high-byte, low-byte order and should never go above $15F (351), since there are only 351 clusters. The File Size field is a value equal to the number of bytes used in the file. This number divided by 1024 (1k) will tell you how many clusters are being used for the file (cluster * 2 = sectors). The File Allocation Table (F.A.T.) starts on track 0, sector 2, and may be the most important table on the disk. F.A.T. is used to keep track of the sector linkage for all data sectors. It is also used for files listed in Folders (sub-directories, see Attributes). The F.A.T. is five sectors long and is valuable enough to be have a duplicate table on the same disk. The location of the second F.A.T. is currently track 0, sector 7, but that is subject to change at any time. The best way to think of the F.A.T. is like a puzzle. Each entry of the F.A.T. is 12 bits long (not bytes, bits), and the values range from $000 to $FFF (see fig.3). Byte 0 of F.A.T. tells what density the disk is formatted in ($F7 is normal for byte $00), and bytes 1 and 2 will $FF as they are not used. The rest of the table is used as follows. (I'll be using the F.A.T. from the disk I have been working on for my examples. see fig.3) Before I begin I should point out that 12 bits per entry means that 2 entries equal 3 hex characters (bytes). We will start with bytes 03, 04, and 05 for our first 2 entries (see fig.3). Byte 03 will be bits 0 thru 7 of the first 12 bit entry, and bits 0 to 3 of byte 04 will be bits 8 thru 11 of the first entry. As you can see in the first example, the number is $FFF. In F.A.T., if an entry contains $FF8 thru $FFF it means the cluster is the last cluster of the file (EOF). Also, if an entry contains $FF0 thru $FF7 it means the cluster is not usable for some reason. Now, if you will return to byte 04, you will remember that we have only used 4 bits (0 to 3). Bits 4 thru 7 of byte 04 will become bits 0 thru 3 of the second entry and byte 05 will be used as bits 4 thru 11. This entry indicates that cluster 4 will be the next cluster for this file and it continues in that manner for the rest of the table. Now you know what cluster to look at but maybe you want to know which track and sector that is. The quickest way I've come with is one of the following formulas, a) To convert from Cluster to Track and Sector; ( ( ( cluster # + 9) * 2 ) - 1 ) / 9 = track ( ( ( cluster # + 9 ) * 2 ) - ( track # * 9 ) = sector b) To convert from Track and Sector to Cluster; ( ( ( track # * 9) + sector # ) - 17 ) / 2 = cluster # A brief explanation. Data sectors start at Track 2, Sector 1. That means 18 sectors (or 9 clusters) have to be accounted for in the formula. Also there are 2 sectors per cluster so you must multiply by 2 at some point. Here is all there is to it, what cluster is Track 22, Sector 3 ?? I'll put the numbers into the formula. ( ( ( 22 * 9) + 3 ) - 17) / 2 = cluster # ( ( 198 + 3) - 17 ) / 2 = cluster # ( 201 - 17 ) = cluster # 184 / 2 = cluster # 92 = cluster # If there had been a remainder, it would have been the second sector in the cluster. Thats all there is to it, but just so you can practice a little, I included a chart with some of the Clusters marked with the Track and Sector (see fig.4). fig.3 (in hex) -- F.A.T. -- 0 1 2 3 4 5 6 7 8 9 A B C D E F 0 F7 FF FF FF 4F 00 05 60 00 07 80 00 09 A0 00 0B 10 C0 00 0D E0 00 0D 00 01 11 F0 FF 13 40 01 15 60 20 01 17 F0 FF 19 A0 01 1B C0 01 1D E0 01 1F 00 02 30 21 20 02 23 40 02 25 60 02 27 80 02 29 A0 02 2B fig.4 Track & Sectors = CLUSTERS BOOT SECT < FAT #1 > < FAT +-----+-----+-----+-----+-----+-----+-----+-----+-----+ | 0.1 | 0.2 | 0.3 | 0.4 | 0.5 | 0.6 | 0.7 | 0.8 | 0.9 | +-----+-----+-----+-----+-----+-----+-----+-----+-----+ #2 > < Disk Directory (7 Sectors) > +-----+-----+-----+-----+-----+-----+-----+-----+-----+ | 1.1 | 1.2 | 1.3 | 1.4 | 1.5 | 1.6 | 1.7 | 1.8 | 1.9 | +-----+-----+-----+-----+-----+-----+-----+-----+-----+ < CLU #2 > < CLU #3 > < CLU #4 > < CLU #5 > < CLU +-----+-----+-----+-----+-----+-----+-----+-----+-----+ | 2.1 | 2.2 | 2.3 | 2.4 | 2.5 | 2.6 | 2.7 | 2.8 | 2.9 | +-----+-----+-----+-----+-----+-----+-----+-----+-----+ #6 > < CLU #7 > < CLU #8 > < CLU #9 > < CLU #10 > +-----+-----+-----+-----+-----+-----+-----+-----+-----+ | 3.1 | 3.2 | 3.3 | 3.4 | 3.5 | 3.6 | 3.7 | 3.8 | 3.9 | +-----+-----+-----+-----+-----+-----+-----+-----+-----+ || \||/ < CLU #334> < CLU #335> < CLU #336> < CLU #337> < CLU +-----+-----+-----+-----+-----+-----+-----+-----+-----+ |76.1 |76.2 |76.3 |76.4 |76.5 |76.6 |76.7 |76.8 |76.9 | +-----+-----+-----+-----+-----+-----+-----+-----+-----+ #338> < CLU #339> < CLU #340> < CLU #341> < CLU #342> +-----+-----+-----+-----+-----+-----+-----+-----+-----+ |77.1 |77.2 |77.3 |77.4 |77.5 |77.6 |77.7 |77.8 |77.9 | +-----+-----+-----+-----+-----+-----+-----+-----+-----+ < CLU #343> < CLU #344> < CLU #345> < CLU #346> < CLU +-----+-----+-----+-----+-----+-----+-----+-----+-----+ |78.1 |78.2 |78.3 |78.4 |78.5 |78.6 |78.7 |78.8 |78.9 | +-----+-----+-----+-----+-----+-----+-----+-----+-----+ #347> < CLU #348> < CLU #349> < CLU #350> < CLU #351> +-----+-----+-----+-----+-----+-----+-----+-----+-----+ |79.1 |79.2 |79.3 |79.4 |79.5 |79.6 |79.7 |79.8 |79.9 | +-----+-----+-----+-----+-----+-----+-----+-----+-----+ -- ---- "I ain't gay, but there are sure times when i wish i could say that i wasn't straight" Name: James M. Turner Mail: Imagen Corp. 2650 San Tomas Expressway, P.O. Box 58101 Santa Clara, CA 95052-8101 AT&T: (408) 986-9400 UUCP: ...{decvax,ucbvax}!decwrl!imagen!turner CompuServe: 76327,1575 GEnie : D-ARCANGEL
dclemans@mntgfx.UUCP (07/07/86)
The ST (i.e., GEMDOS) uses the MS-DOS (3.X) disk and directory structure with
a couple of "minor" quirks: (these are the ones I know about; there may
be others).
a. The media type is only put into the BPB. It is not put into the
FAT. Thus an MS-DOS disk driver that only looks at the FAT to get
the media type will not be able to read an ST disk. In the other
direction, the ST will only be able to read the disk if the BPB
was fully built (i.e., MS-DOS 2.X and greater).
b. The ARCHIVE bit in the file attributes seems to have exactly the
opposite meaning for the ST as for MS-DOS.
dgc