The filing system number for hostfs is 8 and the Tube claim ID is &C6 - for use when hostfs is being accessed from Panos.
 - see 

 for confirmation.


      The code in 

      and
      

      are the BBC Terminal side of the code plus the filing system rom (eg commands like *rename etc).
      (Possibly 

      is a later version.)
      
The Vax/Unix code appears to be 

There's an introduction for new users in 

I made a proposal to build a terminal product with a derivation of this software: 

      
I had another terminal program without the file system support in 

and 

 (the two versions differ only in the removal of 'protected fields' which were required by one client but not by users at Acorn)
- this one was invoked by *TERMINAL

-----------
This document defines the set of BBC MicroComputer I/O processor
operations which must be implemented in order to conform as a
valid PANOS filing system under the new generic filing-system interface.

The calls which are listed here MUST be implemented, and calls NOT
listed here will never be called by PANOS itself.  Other calls
may be issued by users, but they need not be supported.

This document is NOT a complete guide to writing Acorn filing systems;
it merely intends to point out the differences between standard Acorn
filing systems and the subset necessary to run under PANOS.

Subset filing systems implemented according to this document
will work on PANOS only. They are NOT intended for use on the
BBC MicroComputer I/O processor.  If a filing system is wanted
which WILL work under that environment, its precise nature is
described in a collection of other documents not known to the author.
Full filing systems must totally implement the subset calls
described herein.


All unimplemented commands should execute a BRK and offer a
descriptive text message, or be totally ignored.  The list
of commands which should be ignored rather than BRKed is not yet
available, but commonsense should prevail for the moment.
Obvious ones are sideways calls 3,6,7,8,9,B,C,D etc. If a BRK
was executed for any of these, the results would be very unpleasant.

The set of valid characters in file-names which a filing system
must support is undefined, but a recommended set is available
from the Econet steering group (or from Kim Spence-Jones - but ask nicely...)
___________________________________________________________________________

Side-ways ROM service calls:
   Call no. 12 : Start up filing system.
                  - at this point you intercept all the filing system
                    vectors as described later
            01 : Reserve fixed workspace  (at start-up)
            02 : Reserve private workspace     ""
            0A : Fixed workspace is being claimed
            0F : Vectors are being claimed (You may not need this one)
                 (un-plug yourself if possible ???)
and of course:
            00 : ignore.
All others should be totally ignored.

   Subset filing systems must not respond to auto-select, or boot calls,
as it is assumed that added filing systems will be for secondary storage only.
Primary storage systems, off which PANOS can boot, are necessarily full
implementations of Acorn filing systems as described elsewhere.
   Call 04: Oscli should be ignored. Especially, do not offer a command
to start up the filing system - as this would make it open to abuse
from outside Panos.
Implementation note: If this oscli entry is not supported, the only
entry to oscli type commands is via the filing system vector (below)
and therefore the OsCli parser may use filing system workspace for its
variables. This may simplify the writing of the parser. (Otherwise only
utility-area space may be used - which is very small)
___________________________________________________________________________

Filing-system vector:
   6 : Filing system vectors being removed - temporarily close down cleanly
   3 : unrecognised *Command - see OSCLI below
                

OSCLI:
   "*rename  "   : The files will not contain spaces,
                            : nor will the parameters have quotation marks
                            : The path if present is dot-seperated directories

   "*dir "  :  may be repeated dir.dir.dir.dir
   "*dir ^"      :  may be repeated ^.^.^.^
   "*dir "       :  select user-root directory (login directory)
   "*dir $"      :  select login disk root directory
   "*dir :0.$"   :  select super-root directory
   "*cdir " : create a directory in the current directory

All commands will be in full, preceded by a *, and in lower case.

OSFILE:
   0 : Save file
   1 : Set load/exec/attributes  (may currently be of an open file!)
   5 : Read load/exec addresses + attributes (file permissions)
   6 : Delete file/dir
  FF : Load file

OSGBPB:
   2 : group of bytes using last known pointer (implicit, or from OsArgs)
   4 : group of bytes using last known pointer
   8 : Read files in catalogue - Supply only one per call.
        seq. ptr will be 0 for first call, no of files to transfer will be 1.
        seq. ptr will be the number (non-0) returned by this call for
        subsequent calls. Therefore 0 means 'go and read directory'.
        This GbPb entry will be called repeatedly until the filing system
        returns 1 in the 'number of bytes not written' slot.  For successful
        returns it should be set to 0.  The channel slot will always be 0.

OSARGS:
   (Y=0 A=0 : Identify filing system by number will NOT be called)
   Y=file handle, 
    A=0 : Read pointer
      1 : Write pointer
      2 : Read file length (pointer to last byte in file)
     FF : Force buffers onto media (used for databases, restartable jobs etc.)

OSFIND:
   00 : Close file (always given a non-0 handle)
   40 : openin
   80 : openout
   C0 : openinout
___________________________________________________________________________

Filing systems must obey the tube protocols for reading/writing to
second-processor memory, as defined in document ###.

Filing systems are advised to frame their error messages in a form
such that they read well when the text " : filename" is appended to
them. Examples are:

   "File not found"
   => "DELETE: File not found : Fred"

   "This file is a directory"
   => "TYPE: This file is a directory : FredDir"

   "Element Fred is not a directory"
   => "COPY: Element Fred is not a directory : $.NS32016.Release.Fred.txt"

   "File Fred already exists when renaming"
   => "RENAME: File Fred already exists when renaming : Jim"

___________________________________________________________________________


Comments about the filing systems themselves:

When in doubt, tend to ADFS rather than net/disk.

Filenames should be case insensitive.

Filing systems have the option of not renaming across levels if this
is physically impossible. In which case Panos should explicitly copy
and delete.

long operations (which may never return) should explicitly poll for 
and issue a  (or a relevant return code) when detected.

See the examples above for *DIR - filing systems have to handle :0.$
even if it does not make sense to them - see 'memo to self' below.
_____________________________________________________________________________

Comments for KDR/DRL:

Note: *DIR $ ALWAYS takes you to the same place, regardless of what disk
you were on at the time.   <<<<**** KEITH - Is this correct? ****>>>>
(i.e. $ of the & disk.)

  remove the individual calls to set load addr/set exec addr/set attributes.
replace with Get all three/change one (if necessary)/Set all three.

  never attempt to set load/exec etc. on a file before it has been closed.

  Have two calls: A) Set exact load/exec addresses
                  B) Set time-stamp
   - the filing system must be able to infer which was issued by looking
at the parameters to the osfile.

  when *SAVEng files, ignore the reload/exec fields, and set them
explicitly after having saved.

  transform *DIRs of the form ^.^.^.^.^ to repeated calls on ^
likewise, fred.jim.sheila.bloggs to calls on fred etc.

  INHIBIT user PANOSxxx calls to sub-set filing systems, as these filing
systems are the prototypes of clean filing systems running on the 32K.
If such calls are necessary, it merely shows up a limitation in the
system library interface.

  It would be nice if RENAME always set the directory, and did a simple
leaf TO leaf rename IF both files were in the same directory.  My particular
filing system could then implement this case and say NO to renames across
levels (which in fact may be across disks) - in which case the intelligent
RENAME command can do an explicit LOAD/SAVE/DELETE.
_____________________________________________________________________________

Memo to self:

   do we implement :mnt.$.graham.fred as /mnt/graham/fred ???
i.e. :xxx.$ => /xxx

   So what about :mnt.graham.fred ??? Is this illegal?
   Or $.mnt.graham ???

   and :0.$.mnt.graham into /mnt/graham because :0.$ is / ???

   and transform $.graham into /mnt/graham because mnt is the user
root disk? Presumably this is the preferred form?

IS THIS A GOOD TIME TO GET THE 32K GROUP TO ADOPT $DISK.dir.dir
as a synonym for :DISK.$.dir.dir ? (Probably not - but it would
make my transformations easier - just replace $ and . by /)

Do I use anything with a "/" in as literal - for portability of
Unix programs - or do I translate to a suitable character for
portability of BBC programs? Does PANOS consider / as different?
______________________________________________________________________________