What DFS is being used

There are various alternative DFSs to Acorn's DFS and some of them implement certain things slightly differently, or provide extra functions calls. All DFSs return their filing system number as 4, so this cannot be used to tell them apart.

Watford DFS

Watford DFSs implement OSARGS &FE,0 to return the last accessed drive number. Acorn DFS does not implement OSARGS &FE,0 and returns zero page unchanged. This can be used to see if Watford DFS is being used, once you have already found that DFS is being used:

   watford%=FNargs(&FE,-1)<>-1
   
   LDA #&FE:STA zp:LDX #zp:LDY #0
   JSR OSARGS
   LDA zp:BPL Watford:BMI Acorn

(You may not need to ever know if you are running Watford DFS. Just issue the call you wish to use and note that the returned values are not what Watford DFS would return.)

Hierarchical DFS

HDFS uses a different range of file handles from other DFSs. Acorn DFS uses handles &11 to &15, HDFS uses &12 to &17. This can be used to see if HDFS is being used, once you have already found that DFS is being used:

   A%=7:A%=USR !&21E
   hdfs%=(A% AND &FF00)=&12
   
   LDA #7:JSR CallFSCV
   CPX #&12:BEQ HDFS:BNE Acorn
   .CallFSCV
   JMP (&021E)

Note that FSCV can only be called from the I/O processor.

It can be important to know if HDFS is being used as:

• The File access byte is returned according to incorrect documentation
• OSFILE 7 to 10 use nonstandard parameters.
• OSARGS 3 reads a file's allocation instead of writing a file's extent.

EDOS

Opus EDOS reserves 8 pages of absolute workspace and one private page, so PAGE = &1700 on hard reset, in the absence of other filing systems.

The original EDOS preserves A during OSGBPB and OSARGS (except to return the filing system number.) So calls such as OSARGS A=1, Y=0 (read command line tail) or OSGBPB 6 (read CSD) return results in memory, proving they are implemented, but do not change A. For instance:

.testOriginalEDOS
    LDX #workspace MOD 256:LDY #workspace DIV 256
    LDA #0:STA workspace
    LDA #6:JSR osGBPB
    LDY workspace:BEQ notImplemented
    CMP #6:BEQ originalEDOS
.patchedEDOSOrOtherDFS \fall through and exit C=0
.notImplemented
    CLC:RTS
.originalEDOS
    SEC:RTS

In that release OSFSC 7 also returns an incorrect range of valid file handles, &11..&16 instead of &11..&15.

EDOS patched by EDOSPAT 4.20 and above always returns a two-character drive identifier from OSGBPB 6 and 7. The second character is a volume letter from capital A to H. While the FS number is 4 this indicates the presence of either EDOS or DDOS.

From EDOSPAT 4.22, EDOS becomes hard to detect definitely without risking errors or disc activity. Like the original EDOS it supports *OPTions 0, 1 and 5 to 9 and the command *CATGEN. It now (as of version 4.90) accepts OSARGS with A=0..5, Y=0; OSARGS with A=0..6 or &FF, Y<>0; OSGBPB with A=1..8; and OSFILE with A=0..24.

The presence of EDOS may be useful to know as:

• OSFILE could not load or save files larger than 63.75 KB correctly (fixed in EDOSPAT 4.82). This causes problems with larger coprocessors.
• Setting PTR# ≥ EXT# does not extend the file until the next BPUT# or PRINT#.
• When a sequential file is extended, only the sector containing the PTR# is initialised to zero.
• The unpatched EDOS returns from OSGBPB with the carry flag undefined. When reading past end-of-file, it causes an EOF error instead of returning.
• The file access byte is returned according to incorrect documentation (fixed in EDOSPAT 4.50).

If you find a machine containing EDOS please let the BBC Micro Mailing List, the StarDot forums or the BeebWiki know as soon as possible.

OPUS

WikiSysop (talk) 13:22, 8 March 2015 (UTC)