Fast Disk V1.5 For AMIGA500/1000/2000 Written in Aztec C - V3.4a Written 1987 by: Torsten Stolpmann Wilhelm-Raabe Strasse. 26 6750 Kaiserslautern English Translation Provided by Stormin' Norman and Mark Dorn What is FastDisk? FastDisk is a program that optimizes the at times chaotic disk structure of an Amiga Disk. Everbody knows how long it can take for a long directory to be read into memory. Fast Disk accelerates this process between 3 and 5 times. Everybody knows the noise the drive makes when trying to read the Workbench icons. FastDisk reduces the head movement to a minimun, accelerates the validation time and the bootprocess, and also accelerates the load-time of a program up to 50%. What does Fast Disk do? FastDisk accomplishes the above by copying the disk by sectors, but the physical position on the destination disk is changed. That is all! The destination disk is still a regular AmigaDOS disk, so there are NO problems with compatibility. How does FastDisk work? To understand how FastDisk works, you have to understand a little about how AmigaDOS operates on a regular disk. More about this, but not sufficient information, can be found in the AmigaDOS manual. Here is just the most important information. The 1760 blocks on a disk (512 bytes each) are divided into the following: 1. Bootsector 2. RootBlock 3. Directory-blocks 4. Fileheader-blocks 5. FileExtension-blocks 6. DataBlocks BootSectors are always on sector 0 and 1. These are on every AmigaDOS disk and are read while booting up the system. (Only if the disk is bootable.) Then there will be a program executed. FastDisk copies these tracks without any changes. The RootBlock (Sector 880) holds the diskname, creation date, etc., and the Hash chart with 72 entries with pointers for all files/directories that are located in the Root Directory. These entries are sorted by the Hash-Algorithms. The file/directory name is used for this. If it is a Directory name, then the pointer points to the DirectoryBlock, which is setup similar to the RootBlock. If it is a File entry then the pointer points to a FileHeaderBlock. Not all entries in the chart must be occupied. That is why a pointer of "0" is interpreted as blank entry. It is possible that there is more then one entry occupying the same place on the Hash chart. These collisions are solved in a way that chains the needed headerblocks in a linear list by a certain pointer. The FileHeaderBlocks again have another chart, also with 72 entries with pointers to DataBlocks that belong to the specific file. If a file needs more than 72 entries, a chain of FileExtensionBlocks is constructed. These again can have 72 entries. Also it is important to know that Amiga disk I/O is track oriented. That means if the head starts to read a track, it reads all the sectors of this track automatically and saves it in ram until it has read the whole track, and the read/write head leaves the track completely. This is a advantage if the physical positioning of the blocks on the disk can be intentionally done when copying, like FastDisk does. These are the possibilities to optimize disk structure: 1. The physical order of the Files/Directories on the disk is written in the same order as the Hash chart. Because the DIR command follows the Hash chart the listing of directories is going to be accelerated. Validation time is shortened as well! 2. To place FileHeaderBlocks there are two possibilities: A) You group all the HeaderBlocks near the RootBlock (which accelerates the reading of directories). B) You place all the DataBlocks right behind the HeaderBlocks. (The HeaderBlocks are now all over the disk, but loading of files is accelerated. For Directory headers there are similar possibilities. For fast directories it is better to group inside the FileHeaderBlocks. For faster loading of files it is better to place Directory headers inside the Root track. Usually there is enough room to place all directory headers there. As you can see, there are advantages and disadvantages to both methods. Fo that reason a little of both methods is supported by the program, depending on what you want, fast directories (Datadisks) or to load a program faster (Workbench disks). AmigaDOS works in a strategy that combines both disadvantages described above. It tries to place the HeaderBlock and the first DataBlock of the file behind each other near the RootBlock. This accelerates the loading of small files (System-configuration, .info files). FastDisk places the following files right behind the HeaderBlock: Startup-Sequence System-Configuration All files with the .info ending When doesn't FastDisk work? FastDisk requires 2 disk drives and a lot of chip memory. When copying it reads all Header and DirectoryBlocks to ram. If there isn't sufficient room, FastDisk will fail! So, you should give FastDisk as much ram as possible. FastDisk tries to save sectors that are needed later to save in the cache. That means the more ram you give FastDisk, the faster the program will run! FastDisk assumes that you always use a standard AmigaDOS disk. There shouldn't be any sections that are not controlled by AmigaDOS. If there are such sectors, FastDisk will not copy, excluding the bootsector. FastDisk can't copy a disk with a corrupt disk structure. FastDisk notices these errors and suggests you run DiskDoctor. How to run FastDisk! You can use FastDisk from the CLI as well as from Workbench. If run from Workbench it opens its own window (a feature of Aztec 3.4a). An icon with the necessary tool types entries is included. Usage: FastDisk [FROM] drive [TO] drive [FASTDIR] [NOFORMAT] Default: FastDisk FROM df0: TO df1: FROM and TO are not nessesary, only if you want to reverse the order, i.e., from df1: to df0:. If you add FASTDIR, FastDisk will work so you get fast directories (the default is faster program loading). With the NOFORMAT parameter, FastDisk won't format the destination disk, and also accelerates the copying process; but this has the disadvantage that if you ever have to use DiskDoctor, there could be conflicts with older files already on the disk. In that case DiskDoctor sometimes even deletes the working files. Thus it is usually best to not use the NOFORMAT option, or to use a freshly formatted disk as the TO disk. These options are also available via Workbench and the icon's tool types gadget by selecting INFO from the Workbench menu. The tool types are: WINDOW= This is the definition of the window that is opened when running the file, and shouldn't be changed FROM= This is the source drive (df0:-df3:) TO= This is the destination drive (df0:-df3:) FASTDIR= On sets it to on, off or anything else shuts it off NOFORMAT= This should be on or off Defaults: FROM=df0: TO=df1: FASTDIR=OFF NOFORMAT=OFF ***************************************************************************** Addendum to FastDisk.doc August 1988 FastDisk takes approximately 3 minutes to copy a disk. The doc doesn't tell you, but if you're using FastDisk on a disk with lots of icons, and your main reason for using it is to speed up the display of those icons, use the FASTDIR option. Personally, I couldn't measure much of a difference between the two modes (specifying FASTDIR on the command line, or not specifying it) as far as load-time for a large program goes. Maybe I didn't do it quite right. However, doing a DIR of a disk with a lot of files on it is faster (and a LOT faster than a standard unaltered disk) when FASTDIR is specified. Also, this isn't mentioned, but it's very important: After making a copy with FastDisk, leave the new copy UNwrite-protected the first time you open it from Workbench. Whatever version of Workbench you're using will update its '.info' file. Then you can write-protect the disk, and from then on, there's a BIG decrease in the amount of time your new disk takes to display a window full of icons. Your disk drive will quiet down a lot too.