I think the bigger problem would be that variables defined inside a macro definition are local to that macro.
I tend to handle zp allocation something like this:
Code: Select all
ORG 0
.scrnptr SKIP 2
.readptr SKIP 2
.colour SKIP 1
.posx SKIP 1
.posy SKIP 1
ORG &1100
.start
; your code here
.end
SAVE "CODE", start, end
Making symbols immutable was very much a conscious design decision with BeebAsm - it's the only way that handling forward references really makes any clear sense. The concept was always supposed to be that, regardless of the order you define things in, it will always give a consistent result. In practice, this didn't really work out, as sometimes forward references aren't allowed, macros have to be defined before they can be used, etc etc.
I have a 90% complete BeebAsm 2.0 nearly ready for release, which realises this concept much better (now forward references work everywhere, even as the IF condition, a limitation which has frequently frustrated me with the original BeebAsm). It also has string and list types, overloadable macros with parameter decorations (like ADD16 addr, #val), named scopes, named overlays, and more cool stuff. But I'm still not sure whether mutable variables will make it into the design. They seem a popular request though, so I might find a way to specify them with a slightly different syntax, which - among other things - would prevent them from being forward referenced.
I was aiming for a first release last month, but then my work got really heavy again and I had to give it a rest