The ASL editor, illustrated in Figure 5-2, allows you to change the size and position as well as some requester specfic features of standared screen, font, and file requesters. Refer to the Requester section of Chapter 3 for more information on these requesters.
Figure 5-2. ASL Preferences Editor Window
The Position pull-down menu allows you to pick where the Amiga requesters pop up on the screen. The Default position is what is provided by the application. Selecting "Top left of screen" or "Top left of window," allows you to enter the number of pixels from the left edge and from the top edge of the window or screen into the LeftEdge and TopEdge gadgets, respectively.
Similiarly, the size of the ASL requester can be selected. The Default size is provided by the application. Selecting "Relative" from the pull down menu allows you to enter the Width and Height in terms of percent. Selecting "Override" will ensure the settings in the preference editor is used instead of what is set by the application.
The ASL Preferences Editor has several more options for standard Amiga file requester in terms of how a directory listing is displayed. By using the "sort by" pull-down menu, the directory listing can be sorted by name, size, or date. The "Sort Drawers" pull-down menu allows you either have the drawers listed first in the list or after the files are first listed. The "sort order" pull-down" menu determines if the listing is in alphanumeric order (0, 1, 2, 3 ..., A - Z) or in reverse alphanumeric order (Z - A, ..., 3, 2, 1, 0).
The CacheCDFS editor, illustrated in Figure 5-3, allows you to change some specfic settings of the CD-ROM filesystem of OS3.5/3.9. Refer to Chapter 4 on "Using CD-ROM" for information on mounting a CD-ROM drive so that is available to Workbench and AmigaDOS
Figure 5-3. CacheCDFS Preferences Editor Window
Before continuing, there are a few things about cache organization that you must know. In order to make cache access as fast and efficient as possible, the main cache "buffer" must be organized in a special way. We talk about "lines", "prefetch", "data buffer" and "minimal direct read".
These values all relate very closely to sector numbers. All devices that are used to store files on have sectors. One sector is a tiny bit of information - in case of a CDROM - 2048 bytes in size.
All devices have a controlling task (a running program) called a device driver, whose primary task it is to read and write these sectors. This might be the scsi.device for an A3000 with a SCSI-CD ROM drive, or the tandemcd.device for the wonderful TandemCD package from AlfaData. If a file system (like CacheCDFS) wishes to read sectors off a drive, it must ask the device driver to fetch those sectors. This device driver is sometimes called an "Exec" device driver.The file system is a kind of protocol that describes how data is organized on the physical device. The CacheCDFS can read ISO9660, RockRidge and MAC HFS formatted disks. As the filesystem is a kind of interface between the exec device driver controlling the hardware and AmigaDOS, it is sometimes called a "DOS" device driver. The term "prefetch" is an indication of how many sectors the cache will read or write for each physical device access. If prefetch is set to 4, then this means, that even if the DOS only asks for two sectors, four will be read. Since each drive access is a lengthy and time consuming procedure, much time can be saved by "guessing" what sectors will be needed next. Since the best guess is often that "the next sector will be needed next", prefetching sectors in clusters is indeed a good thing. Keep in mind that it only takes a bit longer to read four sectors than to read one. It would take much longer to read four sectors individually than to read them all in one go. Furthermore, as the FileSystem really knows how large a file actually is and how the disc is organized, those guesses have a very good chance to be correct. Prefetch, or "read-ahead" if you want, can boost performance a great deal, providing you set the prefetch value not too big. If you use too much prefetch, it will not help you one bit. In fact, it will probably work against you, slowing everything down. This is because the next sector in sequence probably is NOT the next sector that will be needed, and so the cache will be reading much more than it should, on each access.
The morale is to use prefetch with reason. Generally a prefetch of 2 or 4 gave very good results with ISO9660 formatted disks.
Moving on to the term "lines". Lines is a means of grouping together sectors in "blocks" of a certain length. If a cache buffer uses 32 sets of lines, this means that the cache can remember up to 32 different entries, with each entry consisting of 'prefetch' number of sectors. To illustrate this, consider the following sketch of a 32 line cache, with a prefetch of 4:
Set number Line contents 0 [sector][sector][sector][sector] (4*2048=8k) 1 [sector][sector][sector][sector] (4*2048=8k) 2 [sector][sector][sector][sector] (4*2048=8k) 3 [sector][sector][sector][sector] (4*2048=8k) 4 [sector][sector][sector][sector] (4*2048=8k) etc.... 31 [sector][sector][sector][sector] (4*2048=8k) 32*8k=256k
Each line can hold any four consecutive disk sectors with this prefetch configuration. If the file system asks for sector number 8, the cache will read sectors 8, 9, 10 and 11 into one of the lines. By now it must be obvious that more lines also mean more space available for sector data, and therefore a higher chance that a read operation will be able to complete with no or only little physical disk access. Unfortunately, it also means you have to set aside more memory for the buffers. A compromise you often encounter with computers.
A typical cache configuration is a 50-set, cache, with a prefetch (line size) of 4. The memory required by such a cache buffer will be:
50 sets x (4 x 2048 bytes) = 400k bytes
The CacheCDFS has also a special buffer, called "data buffer". This buffer has always the multiple size of one line.
If the line size is 4, and the data buffer has a size of 4, it is organized like this:
[line][line][line][line] (4*4*2048=32k)
If the FileSystem does caching (it does not always, see the term "direct read" later), it checks the actual file length. In case the file is longer as the amount actually requested, the rest is read immediately into the data buffer, and then copied to the appropriate cache line.
The main difference between the Data Buffer "read ahead" and the normal "read ahead" is as follows:
The cache lines are always filled (a "classic" read ahead cache), so even different directory sectors or sectors from different files are cached. The data buffer is a more "intelligent" special read-ahead cache line, existing only once and caching only files, if the filesystem "believes" they are worth it.
So you can do nice caching even on machines with not much free memory. Look at this (which is the default setting after first time installation):
50 sets with a line size of 1 (no "directory" prefetch!), but a data buffer of 8 (8 sectors "file" prefetch).
50 sets x (1 x 2048 bytes) = 100k bytes
+ 8 x ( 1 x 2048 bytes) (data cache) = 116k bytes
This gives pretty good results, even on a machine with not much memory available.
Now moving to the term "direct read". If you read large files (e.g. "off the disk animations") it is pretty useless to cache all these blocks. The file will purge all other sectors out of the cache, even such blocks like directory entries. To avoid this, you can specify a "minimum direct read" value. If DOS requests more sectors than specified here, the filesystem will bypass the cache and the device driver will copy its data directly into the callers buffer (if any of these sectors are already present in cache memory, these will be used).
Specifying a value of zero (0) will give you a sophisticated default. A very high value (e.g. 2000) will only do requests greater than 4MB directly, what is very unlikely to happen and the cache will always be used. Specifying a value smaller or equal to the data buffer size is not very useful, as you would in fact waste memory.
For best performance, use the default (0).
Before doing direct read, the Memory Type and Memory Mask of the callers buffer will be checked, if it fits to the device requirements (specified in the mountlist as BufMemType and Mask). If it doesn't, the data buffer will be used as a cache.
It's simply not possible to give you a recipe on how to create a perfect cache. The range of possible combinations of all the above values and the memory you wish to spend for caching is simply too vast. You will have to experiment to find the combination that best suit your needs.
You can adjust all these values in the filesystem's mountlist entry using a text editor, but this method is strongly discouraged - using the CDFSprefs program for this purpose is much easier and secure.
This will specify the protection bits all files on a CD-ROM should have, as the Protect command of AmigaDOS will not work because of the read-only nature of CD-ROM media. See Chapter 4 "Using Workbench" on the section "Information" or refer to the Protect command as mentioned in the AmigaDOS manual for more information.
The ISO 9660 group allows you to select partiulcar settings for ISO 9660 CD-Roms
The Mac HFS group allows you to select partiulcar settings for HFS CD-Roms
To play audio tracks on a CD you can either use the capabilities embedded in the CacheCDFS filesystem, or you may use an external audio player program. Usually CD-ROM Audio play will only work with SCSI-II or IDE-ATAPI CD-ROM drives.
If you have enabled Audio support for the CacheCDFS file system with the CDFSprefs program and if you have a SCSI-2 compatible CD-ROM drive the filesystem will show an audio icon on your Workbench, if a CD with audio tracks is inserted. The first track will be played, if you double click this icon. If you double click again, audio play will pause. If you double click again, audio play will resume. If you double - double click the icon the next track will be played. If you have defined the use of an external audio player program with CDFSprefs, double clicking the audio icon will start this external player.
You may use an own icon that will be displayed if a CD containing audio tracks is inserted. CacheCDFS will look for the file ENV:CDDA.info if it is started. If this file exists, it will be used instead of the built in design.
Some of this options are found in the CachCDFS Audio menu:
