Make VDFS compatible with Panos on the 32016 Co-processor

[egrath]

Problem
VDFS is (partially) not usable when running the Panos operating system on the 32016 2nd processor. Panos only supports calls to DFS, ADFS and NFS filing systems.

Workaround (partially)
To use VDFS in Panos, you have to disable DFS (as ADFS is used for the operating system itself) with *FSCLAIM +d before starting Panos. Then you are at least able to work with VDFS, but the following problems occur:

• Files are not visible, even if they are there and are read- and writeable
• DFS restrictions apply
• Unable to create new directories from within Panos

Possible solution

• Allow VDFS to also claim NFS, this should remove the DFS restrictions issue
• Implement the necessary calls Panos uses to retrieve the directory catalogue and create directories

[egrath]

Did more research:

Even in Pandora, VDFS can't be used to load files. Copying a Panos installation to VDFS with TreeCopy and claiming all filesystems results in not even able to load BAS32 from the Library directory.

b-em prints out a lot of "Writing outside of RAM @" messages and finally hangs.

[SteveFosdick]

I am away from a PC until at least the weekend so I won't be able to test what the VDFS code is doing until then.

In the meantime, some thoughts.

I assume you are using a Master as the host for the 32016? In the master, the 1Mbit ROM occupies all the higher priority slots so the built-in filing systems always take priority over user ROMS unless unplugged. This is not true of the BBC B. B-Em's B models have VDFS in 14, with BASIC in 15, so with FSCLAIM VDFS can claim other filing systems without the need to unplug them.

I think the VDFS concept originated with one of the ARM OSes, and a 6502 emulator there, so probably came after Panos. Panos seems to have some of its own complex filing system behaviour which means it needs an adaptation layer for the underlying BBC micro filing system. I assume they did not write one for VDFS but the layer for ADFS or NFS may be suitable.

When reading and writing files from a tube processor VDFS "cheats" by reading/writing directly to/from the tube processor memory rather than read/write to the tube ULA. For files that fail to load, is there anything odd about the load address? For example, is some other information stored in the upper bits, relying on partial address decoding or specific behaviour of the 32016 tube client ROM to have the file written to the right place?