Section 3: Configuration.


3.1) What is ADFSBuffers and what is the best setting for it?

ADFSBuffers are Read Ahead and Write Behind buffers for ADFS on your Archimedes. These are designed to improve the speed of filing operations by doing work at optimum times. There are some side effects of using them though. When active under RISC OS v2.00 and v2.01 discs must be dismounted before being removed from the floppy drive. Failure to do so results in the dreaded 'FileCore in use.' error. However if you are prepared to sacrifice the speed improvement they give configuring the buffers to 0 does remove this problem. (Or so I am informed.)

Under RISC OS v3.00, as supplied with the early A5000 machines, these buffers generate a different problem and must always be configured off. Failure to do so results in spurious errors when using the Hard Drive on an early A5000. Symptoms include reformatting of crucial sectors of the disc, disc address errors and general failure to save files to the drive. So when using an A5000 with RISC OS 3.00 remember to configure them off!

With RISC OS v3.10 all of the old problems have been cured with a new one introduced. Namely that if you have only a few ADFSBuffers configured and are accessing the floppy drive then your machine can occasionally lock up completely for you. It appears that any value of ADFSBuffers above 8 causes that problem to be largely alleviated (read it only occurs rarely at these settings). So under RISC OS 3.10 it is recommended that you set your ADFSBuffers to 8+. There is a patch module available, called ADFSUtils, that does fix this problem - contact your local dealer for a copy of it.

By default RISC OS 3.5 seems to have all of these problems cured and no new bugs introduced. Under 3.5 the number of ADFSBuffers can be left at the OS's discretion and generally the OS chooses a number based on the amount of memory present in your RiscPC. Unfortunately this cannot be said of RISC OS 3.6, 3.7 or 3.5 using a softloaded copy of the 'extended' FileCore. When running under these conditions if you have a hard drive partition larger than 2 GB then the buffers must be configured off to allow the drive to work, however installing ROM Patch 3 from the Acorn ftp site will fix this bug with large hard discs.

As for the optimum settings for ADFSBuffers, from some speed tests conducted on an A5000, then it has been observed that configuring the maximum of 255 buffers increases drive access speeds by 40-50% (this varies considerably with the type and make of drive) over accesses with no buffers at all. However it achieves only a 15-20% gain over using 32 buffers.

All in all ADFSBuffers behave in a fashion standard for caches. Enlarging the cache size does produce increasing gains, but there are increasingly limited gains as the cache size enlarges. So 255 buffers is better than 128 buffers but not twice as good. However at the low end there does seem to be a degree of synergy between the caches and the drive that means that 64 buffers is twice as good as 32 buffers. Accordingly I recommend that people use at least 64 buffers, more if they can spare the RAM.

Return to the index.

3.2) How do I enable solid drags in RISC OS 3?

Solid drags are controlled by bit 1 in byte 28 of the CMOS RAM. Setting this bit enables solid drags on all solid drag 'aware' applications. However setting this bit using a *FX command from the command line is a foolish way to do it, as this will unset/set the other 7 bits in that byte which have meaning to FileSwitch and the Wimp. Accordingly the recommended way to set this bit is using a program like this BASIC one enclosed below :-

   REM Toggle state of DragASprite bit in CMOS

   REM Read byte
   SYS "OS_Byte",161,&1C TO ,,byte%
   REM EOR byte with mask for bit 1
   byte% = byte% EOR %10
   REM Write byte back again
   SYS "OS_Byte",162,&1C,byte%
   END
Which safely sets bit 1 while preserving the settings of the other bits.
Return to the index.

3.3) To what size should I partition my Hard Drive?

This is a complicated question to answer with any hard and fast rules. For starters the media and filing system being used must be considered. If you are using an IDE drive under ADFS then you usually should have your drive formatted as one whole partition due to ADFS' inability to support multiple partitions. (Although third party extensions, like Alsystems PowerIDE software, can extend the default IDE interface to include partioning.) However this is not always true and sometimes it can be beneficial to sacrifice a few Mbs of partition size to gain tens of Mb savings in reduced space wastage when storing files.

RISC OS uses, and through FileCore virtually all filing systems share this, a fairly complicated map system that tries to make a reasonable compromise between filing system overheads, speed and flexibility. For drives 512Mb or less this system works quite well. With the advent of easily available multiple Gb size drives the system begins to suffer a little.

For reasons that are beyond the scope of the FAQ to explain RISC OS links the LFAU (Large File Allocation Unit) to the minimum object size on a disc by a ratio of sixteen to one. Thus a two byte sized file occupies a minimum of sixteen kilobytes of actual disc space to store. There is an important exception to this involving the sharing of map entries, and thus disc space, but the general rule is as above. This table summarises the relationship between LFAU, disc size and minimum object size.

lfau   max disc size   min object
----   -------------   ----------
 1K      499M bytes        16kb
 2K      998M bytes        32kb
 4K     1996M bytes        64kb
 8K     3992M bytes       128kb

Consequently it can be easily seen that the larger the partition size the larger the individual file overheads of storing it becomes. (NB It is worth pointing out that Image Filing systems do not share this overhead directly.)

Thus which partition size you should aim for depends on what you intend doing with the drive. If you are primarily storing Replay films then given the multi-megabyte size of the files the overheads required for storing each file is percentage wise less and it is more important to have bulk disc storage available than it is efficiency of space utilisation. On the other hand running a news spool will involve thousands of files averaging around the seven kilobyte mark, thus a smaller partition size will greatly reduce space wastage to filing system overheads.

In the FAQ maintainers experience a good compromise size seems to be the just sub one gigabyte mark.

Return to the index.

Return to Index page
Comments and Feedback