Sorry to hear you have not been well. Please don't feel any pressure to do anything as a result of this thread. I really just wanted to write some stuff down to get my thoughts straight.
There are a couple of your optimizations that I'm not completely comfortable about:
the simplified wildcard matching
the use of &11xx as general workspace
But I think there is an opportunity to save a bt more code space with an appropriately reworked wildcard matching code.
The original Acorn wildcard matching is very flexible. It allows multiple wildcards (e.g. *T*ST*) and the implementation uses recursion to so that each wildcard grabs a few charcters as necessary
I'm loathed to lose this capability, because I suspect it's used by quite a few people.
I attempted to re-instate the original Acorn code yesterday, but hit some issues because of the buffer changes (more below). The problem is, the Acorn code relies on the "pattern" being padded with several space characters. One of the later buffer changes eliminates this padding, so it's not possible to just re-instate the original code. I tried a few quick fixes yesterday but none were entiely satisfactory.
Buffering Changes
Whilst I'm generally comfortable with the idea of eliminating unnecessary copying between the various buffers / workspaces, there are a couple of caveats:
We need to be cogniscent that only &10C0-&11BF is persisted to the private workspace page. Any state that needs to be preserved across "ilesystem boundaries needs to be placed there. I didn't spot anything that violated this, but I just wanted to make sure you were aware of how this works.
What I'm thinking in terms of the wildcard stuff to try to re-instate a version of the Acorn algorithm with the following characteristics:
It uses recursion (or whatever) to allow multiple * matches [ i.e. it gives the same results as the Acorn code ]
It doesn't rely on the pattern being padded with multple spaces, so it can be used in the case where the pattern is just the 7 character channel data filename "in place". So most likely, the pattern has an associated length (or possibly end index).
It can be used to match 7 character filenames and 12 character disk titles. So the string being matched is accessed using (ZP),Y and has an associated length.
The reason for (3) is to allow it to be used in the *DCAT <pattern> which currenly uses seperate "simplified" wildcard matching that is using quite a lot of code. See DMatchInit and DMatch.
I think by using one wild card matching algorithm for both, we'll end up with the best of both worlds, and save quite a bit of code space.
Anyway, interested to hear your thoughts on this, but honestly only if you feel up to it!
Hi Dominic,
Sorry to hear you have not been well. Please don't feel any pressure to do anything as a result of this thread. I really just wanted to write some stuff down to get my thoughts straight.
There are a couple of your optimizations that I'm not completely comfortable about:
But I think there is an opportunity to save a bt more code space with an appropriately reworked wildcard matching code.
Simplified Wildcard Matching
This change: mmfs100.asm : use much simple filename matching
The original Acorn wildcard matching is very flexible. It allows multiple wildcards (e.g.
*T*ST*) and the implementation uses recursion to so that each wildcard grabs a few charcters as necessaryI'm loathed to lose this capability, because I suspect it's used by quite a few people.
I attempted to re-instate the original Acorn code yesterday, but hit some issues because of the buffer changes (more below). The problem is, the Acorn code relies on the "pattern" being padded with several space characters. One of the later buffer changes eliminates this padding, so it's not possible to just re-instate the original code. I tried a few quick fixes yesterday but none were entiely satisfactory.
Buffering Changes
Whilst I'm generally comfortable with the idea of eliminating unnecessary copying between the various buffers / workspaces, there are a couple of caveats:
We need to be cogniscent that only &10C0-&11BF is persisted to the private workspace page. Any state that needs to be preserved across "ilesystem boundaries needs to be placed there. I didn't spot anything that violated this, but I just wanted to make sure you were aware of how this works.
Quite a few games set PAGE to &1100 and expect to be able to LOAD/SAVE files. So as a general rule, only random access file operations should use &1100-&11FF. If it's used as general workspace then that will break those games. The specific change that I think will cause problems is: mmfs100.asm : move filename buffer into same page a chanelldata, then there is no need to copy the filename
Where next....
What I'm thinking in terms of the wildcard stuff to try to re-instate a version of the Acorn algorithm with the following characteristics:
The reason for (3) is to allow it to be used in the
*DCAT <pattern>which currenly uses seperate "simplified" wildcard matching that is using quite a lot of code. See DMatchInit and DMatch.I think by using one wild card matching algorithm for both, we'll end up with the best of both worlds, and save quite a bit of code space.
Anyway, interested to hear your thoughts on this, but honestly only if you feel up to it!