Since OSFILE was mentioned - FileSwitch does actually need to handle OSFILE too, because you might do "*LOAD -ADFS-FILE", similar *SAVE, or whatever, and it'll need to handle that. It needs to step in any time there's an FS call that involves a file name or file handle, to ensure the appropriate FS is activated for the operation of interest then restore the previous one.I was wondering on that, and why FILEV would be different. Of course, the difference is that operations on whole files will just use the currently selected filing system. It is operations on open files where the FileSwitch needs to look up which filing system owns that channel number and make sure it is selected.The conventional check is to check XFILEV. Checking XFSCV would not work on the Master as it will be pointing to FileSwitch in the MOS.
But, reading Tom's post and checking it out myself, it seems, the way the other filing system calls end up in the FileSwitch rather than going straight to the current filing system isn't by having the normal (non-extended) vector point to the FileSwitch code but my having the entry point in high ROM point to the FileSwitch code. It seems filing systems initialise the normal, and if necessary extended, vectors in the usual way.
Having the ordinary FS entry points jump to fixed routines rather than via vectors lets it do this pretty easily. Step 1, determine appropriate FS; step 2, switch to FS of interest (possibly a no-op; otherwise, let it initialise itself as normal, then leave the vectors/extended vectors it installed in place); step 3, call the relevant vector (possibly ending up using the standard extended vector behaviour - somebody else's problem, the vector address does the work...); step 4, restore previous FS, again possibly a no-op.
But FSCV is always vectored, with no absolute entry point, so the MOS always has to overwrite FSCV with its own routine, saving off the original address somewhere (it's stored towards the top of HAZEL) - but aside from that, the behaviour is the same, in terms of leaving the extended vector part intact and letting the extended vector mechanism handle it as required.
(this is all somewhat from memory, but I can dig out code references from my MOS disassembly if required. The FileSwitch code was something I was interested in when I first started looking at it. Some of the commentary comes from JGH's original disassembly that I started from, and I have since added a bit more to it)
--Tom
Statistics: Posted by tom_seddon — Thu Oct 30, 2025 12:49 am