Add SRAM Utilities to MMFS

[hoglet67]

Would only be space for this in the non-SRAM version for the Model B (and Electron?)

[SteveFosdick]

And, of course, the sideways RAM version is the one you'd be most likely to want SRAM utilities with. I wonder how many could be added to the bootstrap ROM? These could run from that ROM rather than being part of the code being copied across.

I did experiment with adding the ROMS command back in and there was space. That was before it was integrated into MMFS and certainly before the electron version but I don't think these utilities should be that big. I did find I was having to copy some subroutines from the main part of MMFS.

[hoglet67]

That's a very good idea Steve.

Do you think it's just SRLOAD that's really needed?

[SteveFosdick]

We don't really know everyone's use case but on the assumption that someone has removed the DFS ROM and fitted the MMFS bootstrap ROM in order to be able to use MMFS with page back to E00, and have therefore lost the use of the SRAM command in the DFS but have not fitted a separate ROM manager/utilities ROM to plug the gap then SRLOAD would be the minimum to be able to load either a utilities ROM or a DFS ROM into sideways RAM for the times the other SRAM utilities are needed.

My limited recent experience is that the SRAM command I use most often is SRLOAD and the second most common is ROMS. I have used SRWIPE very occasionally and have not yet found the need for SRSAVE.

I also wonder how many people find the complexity of the MASTER implementation useful. I am thinking things like the ability to load a ROM to an address other than 8000, the ability to save a partial ROM, the two different addressing schemes and the extra commands for managing sideways RAM as data.

I know in the case of SRLOAD I find the need to specify the address is a nuisance and certainly the complexity of the master syntax would be reflected in the implementation. The only advantage I can see in implementing the master syntax is that it can be used in boot discs - the Music 5000 is a case in point but then the author of that assumed a master and assumed which sideways RAM banks were available.

The ROMs command that exists in the non-SWRAM version of MMFS has the ability to specify a particular ROM to give information on - another feature I have not found useful. Normally such a feature gives a more detailed report on the item you have chosen but in this case that doesn't seem to happen. Another feature it would notbe necessary to copy.

So, I think I'd start with a simple SRLOAD command and then, if there is still space, consider ROMS, SRWIPE etc.

I could have a go at this if you don't beat me to it.

Another, thought, returning to the question of !BOOT files it would be useful to have a command to check if a particular ROM is installed so the !BOOT file could automate the loading of it if it not already installed. JGH's SRAM ROM includes a SRLOAD command that will load a ROM into the first available slot.

[hoglet67]

Steve,

By all means have a go at this, it's been on the TODO list for quite a while now.

Could you add it as a separate file, so that it could be included in the main MMFS ROM where space permits? If there is any common code, such as parameter processing that you want to pull out into a shared utilities file, please go ahead and do that.

Dave

[SteveFosdick]

Dave, I examined the Acorn implementation and didn't find anything that looked like a functional difference between 1.03 and 1.05. The command table lookup is different and unwinding the stack is also different, and one routine saves the flags where it didn't previously. Looks like bug fixes and optimisation to me. I can post a diff if you're interested.

Along with my previous comment about complexity, the Acorn implementation is also too big for the space left in the bootstrap ROM, makes assumptions about which slots the RAM will be in and assumes it can use some DFS workspace, so I thought I'd start with something simpler.

So far I have an implementation of SRLOAD and SRSAVE that always work with whole ROMS and always use the "quick" loading method of using OSFILE and using the space between OSHWM and HIMEM as the buffer. This should work with any filing system. I also have a ROMS command which identifies which slots have RAM in.

There is some space left so I could add some other enhancements but I'd like to get the current version checked in. Do you want me to fork MMFS and create a pull request or just create a branch?

So far there is one new file and a couple of hooks into bootstrap.asm though maybe that could be improved.

How would you integrate into non-bootstrap versions? Use the MMFS command table and HELP processing or just daisy chain service calls 4 and 9?

Enhancement ideas include the OSWORD SWRAM calls and more of the Acorn flexibility, extra commands modelled after JGH's version: SRWIPE, INSERT, UNPLUG, LANG etc. or write protect manipulation.

[hoglet67]

If you could fork MMFS and commit the changes to a branch, then I can merge that back upstream. The pull request is optional (I prefer to do the merge manually!)

To integrate this into non-bootstrap versions of MMFS (where space permits) I was hoping to just include the commands in the command and help tables, as that would be most space efficient. This might involved some refactoring.

[SteveFosdick]

Latest version at https://github.com/SteveFosdick/MMFS/tree/sf/sram includes skipping an 8000 if specified on the command line for compatibility with Acorn B+/Master syntax and accepts letter named bank IDs. For the latter Z is the highest numbered slot which does not contain MMFS and other letters work backwards from there.