Here's a trace of SRLOAD going wrong with a few comments (##):
(It was captured using Myelin's FX2 adapter board
hanging off the Tube and using my 6502 decoder
MER intercepts OSCLI and tests for its commands first, which includes SRLOAD.
When SRLOAD is executed, the MER uses the current file system and successfully opens the file with OSFIND, then starts reading it with OSGBPB.
It's the first call to OSGBPB that fails. It looks like MER is trying to implement a file switch layer, like the master does. So the call to OSGBPB is intercepted by MER, which tests whether the right file system is selected for the file handle.
To do this it has a table of:
- *COMMAND to initialize file system (padded with spaces)
- lower bound of file handle from this file system
- upper bound of file handle from this file system
- file system number
Here's the actual table:
Code: Select all
000022d0: d0d2 a9ff 8dff 0960 6b63 6f6c 4343 4653 .......`kcolCCFS
000022e0: 2020 2020 2001 0201 5441 5045 2020 2020 ...TAPE
000022f0: 0102 0152 4f4d 2020 2020 2003 0303 4449 ...ROM ...DI
00002300: 5343 2020 2020 1115 0444 4953 4b20 2020 SC ...DISK
00002310: 2011 1504 4e45 5420 2020 2020 202f 0541 ...NET /.A
00002320: 4446 5320 2020 2030 3908 5646 5320 2020 DFS 09.VFS
00002330: 2020 5059 0a00 ade6 098d e709 60a9 8fa2 PY........`...
In its file switch implementation, MER uses the above table to try to identify the current file system, based on the value of the open handle.
If there is a match, it proceeds to compare the file system number in the table with what it thinks is the current file system. If they don't match, it issues a service call A=12 to select what it thinks should be the filesystem.
MMFS currently issues file handles in the range &51-&55, and unfortunately this matches the entry for VFS in the table (&50-&59)
So where it's breaking is that MER tries to select VDFS, which doesn't exist.
I can think of two ways to fix this:
a) Patch the table in MER to add MMFS in place of VDFS
b) Make MMFS use the same range of file handles as DFS (&11-&15)
I've just tried (b) and SRLOAD no longer fails.
Anyone you any thoughts on whether (b) is a bad thing?
MMFS and DFS already share the same file system number (&04) meaning they don't nicely coexist. This is done for compatibility with quite a few games that will only run on DFS (file system number &04). So my feeling is this won't break anything that's not already broken.