This document gives an overview of how MultiFS works.

MultiFS is the word used to describe the handling of multiple, dissimilar, disc formats on the Archimedes. The desired end point for the MultiFS project is to have a system which can handle multiple disc formats with least learning required by a user. This means that when a user accesses a foreign format disc, be it a floppy disc or a PCEmulator hard disc partition, the user won't notice any change in the things needed to be done. Clicking on the disc icon will open the root directory viewer. Inside this will be the familiar table of directory and file icons with their names. All the functions available normally will be available on these too IN THE SAME WAY. The main point of the MultiFS system's existance is to have DOS disc access. This will be implemented as it is required in its own right, and also as a test of the MultiFS system.

• All functions available IN THE SAME WAY: This criterion forces a foreign disc to be presented to the system like any ordinary Risc OS filing system. Fortunately, this is not hard as all filing system access goes through the FileSwitch module.
• Accessing discs and PCEmulator partitions: A short bit of thinking quickly illustrates that the way to handle this is to present to a MultiFS the image it has to handle as a file. This requires work by FileSwitch to identify MultiFS files (eg PCEmulator disc partitions) and to translate the original request into requests, as necessary, to MultiFSs. Also, this requires FileCore (the majority of the code handling ADFS, RAMFS and SCSIFS) to present discs it has identified as a MultiFS discs as a file of the required type, so that FileSwitch recognises this as a standard MultiFS file.

Structure:

        FileSwitch
           /   \
          /     \
        a/       \b
        /         \
       /     e     \

   |            /---/
   |c      /---/d

The names identify the component parts and the lines communications between them. Links a and c are the standard FileCore filing system links as Risc OS 2.00 defines them. Link b is the communication made by FileSwitch when it encounters a foreign disc format file, and the use DOSFS makes of FileSwitch to read the contents of that file. Link e is the communication between FileCore and DOSFS to identify a disc. Link d is the communication between DOSFS and ADFS made when ADFS wishes to format a disc in a non-ADFS form.

It would be possible to separate a MultiFS filing system into three component parts:

• The image handler.
  
• The identifier.
  
• The formatter.
  Indeed, for the purpose of this description I shall treat these as separate. In practice, however, it is better to have these parts in one module as this ensures a complete, working, system is loaded, rather than a partial system. Also, having the parts in one module saves a small quantity of space, due to the sharing of the module overhead, and, possibly, of code.

The Image Handler

This is the most complex component of a MultiFS. Its job is to manage files in a MultiFS image (eg a DOS image). The image handler only talks to FileSwitch, accessing images as files. FileSwitch tells it when it has found a MultiFS file which is relevant to the handler, and makes requests to access files, directories which the handler translates to file accesses which FileSwitch passes to the relevant filing system. Any image handler must identify itself to FileSwitch as such. This process is similar to that done by a native filing system, but the number of calls the image handler needs to support is fewer, the rest of the work being handled by FileSwitch.

The Identifier

This part of a MultiFS is used to identify what format a disc is. Its job is to check an image's contents against what would be expected for this particular filing system. The request to check an image is made using service calls. If the image is recognised, the service call is claimed, if not the call is passed on. Ihe issuer of the service call waits for its return. An unclaimed service call indicates the image wasn't recognised, and so the issuer can complain about the disc being duff.

The Formatter

This part of MultiFS is used to help format a disc for use as a MultiFS disc (eg DOS disc). It provides services to other sections of the system which do the actual formatting. It communicates using service calls and SWIs. The service calls, one for menu format selection, and one for *-command format selection, are used to identify parameters defining a format. These parameters are in the form of two SWI numbers with parameters to be passed to them. One of the SWIs returns parameters describing a floppy's physical format (sectors per track, sector skew, GAP1, GAP3 etc etc), the other SWI lays down a structure corresponding to an empty disc suitable for the image handler.

The Internal Workings

So, how is the system expected to work in practice? Let's take an example of the user clicking on the floppy disc icon with a DOS disc in the drive.

i) User clicks on floppy disc icon.

ii) ADFSFiler (the module running the floppy disc icon) sends the Filer (the module running directory viewers) a Filer_Opendir message for directory adfs::0.$

iii) The Filer first checks to see whether it has already got adfs::0.$ open, and, if it hasn't, it creates an internal structure for it and then does an OS_GBPB 10 (read directory entries and information).

iv) FileSwitch receives the OS_GBPB 10 with the name 'adfs::0.$' and does an fsentry_file 5 on ':0.$' to adfs:

v) adfs: uses the FileCore module to process requests from FileSwitch. FileCore, which knows about which discs are in which drives, does not yet know what sort of disc is in drive :0 and makes a request to the ADFS module to mount the disc.

vi) ADFS identifies what hard format the disc has (SD/DD/HD/ED, sectors per track, sector numbering etc) and returns to FileCore.

vii) FileCore, having had the hard format identified by ADFS, makes a Service_IdentifyDisc quoting the disc record as filled in by ADFS.

viii) DOSFS receives the Service_IdentifyDisc, updates the disc record and makes various reads and tries to match the answers with valid DOS disc formats. If a valid format is found it claims the service, if no valid format is found it passes the service on. In this example the service will be claimed and DOSFS will pass back with the claimed service the disc name and a file type to associate with this disc's contents.

ix) FileCore receives the claimed service and records in its own internal drive record that the disc in that drive has the given name and file type. FileCore then returns back to FileSwitch that :0.$ is a file of the type returned to FileCore by DOSFS.

x) FileSwitch notices that :0.$ is a file of a given type and looks up that type in its table of registered MultiFSs. If the file type isn't found FileSwitch will return a 'adfs::0.$' is a file error, otherwise it will open adfs::0.$ as a file and notify DOSFS (or the corresponding MultiFS) that
DOSFS has a new image to handle.

xi) DOSFS receives the notification of an image it has to handle, records internally the FileSwitch handle it was quoted and returns its own handle back at FileSwitch.

xii) FileSwitch records against adfs::0.$ the DOSFS handle DOSFS gave it.

xiii) FileSwitch does an ImageEntry_func 15 (read directory entries and information) to DOSFS quoting the DOSFS handle for adfs::0.$ and the name of the directory of ''.

xix) DOSFS enumerates '' (the root directory of the image) and returns to FileSwitch.

xx) FileSwitch filters out any unwanted entries and eturns to Filer.

xxi) Filer displays the directory viewer.

What points should be noted from this?

i) Each MultiFS has one (or more) filetype allocated to it which identifies how the contents of a file of that type should be interpreted as a directory tree with files as leaves.

ii) Each module involved in the MultiFS system only needs to know how to handle a small part of the whole MultiFS system. For example, DOSFS structure handler doesn't need to know how to identify or format a disc for itself, nor does it need to know how to drive the ADFS disc driver - all it needs to know is how to access a file. Similarly, FileSwitch need make no distinction between discs and files which are MultiFS files - they are both presented to FileSwitch as files of a given type.

iii) Once the MultiFS system is in place any number of other filing systems may be used, soft loaded.

FileSwitch is Responsible For:

Noticing when a MultiFS image file needs to be opened, openning it and redirecting the user's request to the relevant MultiFS.

FileCore is Responsible For:

Organising the identification of a disc whose logical structure is, as yet, unidentified and, if a MultiFS recognises it, faking the entire contents of that disc to be a file of the required type and storing the name of that disc against it. FileCore is also responsible for identifying its own discs and managing the logical structure of them.

ADFS is Responsible For:

Identifying the physical format of a disc; laying down a physical format on a disc; reading and writing to a disc; verifying a disc; organising the formatting and verifying of a disc from the command line.

A MultiFS (eg DOSFS) is Responsible for:

Managing the logical structure of a MultiFS image given its file handle; Identifying a particular disc as being one of its own when requested to do so; specifying lists of its own formats for the ADFSFiler menu; identifying a command line format identifier as one of its own; constructing a physical format description record for one of its own formats; laying down a logical structure into a file for one of its own formats.

ADFSFiler is Responsible for:

Organising the menu selection of a disc format and organising a format to that specification. Organising the verification of a disc to a given specification.