Discuss Dominic's Optimizations

[hoglet67]

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:

• 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.

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 necessary

>*.
MENU (0)
Drive 0             Option 3 (EXEC)
Dir. :0.$           Lib. :0.$

    !BOOT               ACIAIRQ    
    ASPTEST             BLIT       
    BOING               CDUMP1     
    CHCODE   L          CHE00    L 
    CPOF                CPOFBAS    
    CPONBAS             CURSOR     
    DUMP                FBTEST1    
    FBTEST2             FBTEST3    
    FBTEST4             HIPOKE     
    INTTST1             INTTST2    
    INTTST4             IRQDEL     
    ISRTST              KEYTEST    
    MEMPTR1             MENU     L 
    PEKPOK1             R3         
    R3DUMP     

>*INFO *T*ST*
$.ISRTST      FF0E00 FF802B 000088 0B0
$.FBTEST4     FF0E00 FF802B 000106 0AD
$.FBTEST3     FF0E00 FF802B 000187 0AB
$.FBTEST2     FF0E00 FF802B 000184 0A9
$.FBTEST1     FF0E00 FF802B 0000C5 05E
$.INTTST4     FF1900 FF8023 000336 01B
$.INTTST2     FF1900 FF8023 000207 014
$.INTTST1     FF1900 FF8023 0001A7 012
$.KEYTEST     FF2100 FF8023 0000F4 00F
$.ASPTEST     FF2100 FF8023 00022D 00C

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:

1. 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.

2. 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:

1. It uses recursion (or whatever) to allow multiple * matches [ i.e. it gives the same results as the Acorn code ]
2. 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).
3. 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!