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 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.)
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.
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
It now (as of version 4.90) accepts OSARGS with A=0..5 or &FF, 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 caused problems with larger coprocessors.
EXT#does not extend the file until the next
- 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
EOFerror instead of returning.
- The file access byte is returned according to incorrect documentation (fixed in EDOSPAT 4.50)
- EDOS implements default filenames (see Opus DDOS).