Date   : Sun, 05 Oct 2008 03:19:22 +0200
From   : kortink@... (John Kortink)
Subject: Save location for temp variables.

On Sat, 04 Oct 2008 21:38:53 +0100, Phill Harvey-Smith wrote:

>[...]
>
>Ok, so next question is this, the ROM code I'm working on will need to 
>store a couple of temp variables, I could request a page of private 
>storage, but as at the moment I only need a few bytes, this seems like a 
>  complete waste of 200+ bytes.
>
>Next thought was to store them on the stack, but again with the 6502's 
>limited stack I don't really want to put too much on there and also 
>accessing them will get messy.
>
>So is there a convenient place I can save a few bytes whilst in my ROM 
>code ? This is mainly for parsing the command line passed to my 
>commands, and the binary parameters for my code, e.g. I'm working on a 
>command thus
>
>*SRZAP <id> (<id>)
>
>The command will blank the specified ram banks, but I need a place to 
>store the bank numbers whilst reading them in and actually executing the 
>command.

The stack is by far the best and most suitable place
for temporary variables, as long as they don't consume
too much of the stack (up to 100 bytes or so is perfectly
safe in most situations). It's worth the effort if you
want your code to be completely neutral (including when
called from your own routines). I.e. push your temporaries,
access them with TSX and load/store from/to &100+offset,X,
and pull them all when you're done.

If you're lazy, and you're not calling /any/ OS routines,
&A8-&BF can be used as scratch space, and are documented
as such. Especially calling OSWRCH is a pitfall here,
since it can cause a cascade of calls to other OS and
filing system routines, depending on enabled streams,
an open spool file, etc..

There is practically no other scratch space available
unless you're prepared to create some by saving and
restoring the contents of (semi-)statically allocated
locations. Which must not be used from interrupt
routines (practically everything from &800 to &DFF
could be !), since that implies making assumptions
about what the user is (not) doing at the time, which
is always a bad idea.

Again, the stack is the best. You can still do anything
you like, including OS calls and, not unimportantly,
calling your own routines (which might otherwise be
using the same scratch space as the calling routine,
necessitating a delicate balancing act in memory use).


John Kortink

-- 

Email    : kortink@...         
Homepage : http://www.inter.nl.net/users/J.Kortink

GoMMC, the ultimate BBC B/Master/Electron storage system :
http://web.inter.nl.net/users/J.Kortink/home/hardware/gommc