Date   : Fri, 26 Dec 2008 22:26:54 -0000
From   : mfirth@... (Michael Firth)
Subject: Using stack page for temp vars

----- Original Message ----- 
From: "Phill Harvey-Smith" <afra@...>
To: <bbc-micro@...>
Sent: Friday, December 26, 2008 12:45 PM
Subject: [BBC-Micro] Using stack page for temp vars


> Hi there,
>
> Still developing my sram utils to be romable and replace the Acorn ones,
> without taking up extra ram. I have been using the area from &A8-&AF for
> tempory storage during execution of the commands, however I find that I
> need some more storage, perhaps another 5-10 bytes just for tempory byte
> counts end addresses etc.
>
> I have thought of using the bottom of the stack page starting at &100,
> for such a purpose, as tracing my code in the mess debugger the stack
> pointer always seems to be pretty near the top in the &1Ex area, so as
> long as I don't use too much stack they should never get overwritten.
>
> Does this seem reasonable, I do note however that the Acorn SRAM utils
> seem to use the space &C0-&CF for some of it's storage, however since it
> is part of the 1770 DFS rom, this may be considdered the currently
> active filesystem, which is whast the Advanced user guide lists them as.
>
> Final point, is there anywhere I could make the source available, as
> these utils are getting to the point where they may actually be usefull
> to someone other than me :)
>
One relatively easy compromise is to ensure that you only use the stack for 
commands you don't process, and use the &70 - &8F range for your actual 
command processing.

This means that any machine code / language that doesn't use your commands 
won't get corrupted, but will potentially cause problems for using your 
commands from some other code.

Given that 95%+ of the time, any SRAM commands will either being run from 
*EXEC scripts, or from BASIC programs, using the BASIC reserved range for 
their processing is probably not a problem.

Worst case, document and caveat the use of that memory.

There are obviously other areas of memory you can borrow if you can afford 
some restrictions on the use of your utils - e.g. &900-&AFF is generally 
spare unless you are using BPUT/BGET on the tape FS, though, because of 
this, several other things tend to use it - again, if you document its use 
then people can probably work around it.

To me, there is a big difference between SRAM handling commands, which are 
generally only needed during a 'session setup' operation - i.e. loading the 
SWRs with the contents you need for a particular application of the system 
after power on, and other * commands which are more generally used - if an 
implementation of *LOAD didn't do things legally you would have real 
problems.

In terms of hosting, I too am happy to host your source and binaries if you 
don't get a better offer.

Regards

Michael