You need the brackets after RND (unless you only want a floating number between 0 and 0.999 but you might be able to tweak that). SGNPOS looks promising but it yields 0 and 1 not 0 and -1 and so there's need to be further tweakage. I'll have a think about that in the departure lounge!
@@lsbyte now I wonder about B=BEORSGNPOS with 128* elsewhere. Or maybe B=128ANDB-SGNPOS with B=0 initially - so I think B would then swap between 0 and 128?
@@lsbyte I think VDU 15,31 can be combined in decimal to save a byte. Now the thing I've been meaning to think about is that you don't need to go up to 128 to change the background colour - you can just go negative instead. Leaving B as-is, you should be able to change COLOUR130-B to COLOUR-2-B without affecting the output. And, maybe that pesky leading "-" can be removed if we also invert the other COLOUR statement, e.g. COLOUR2-B:COLOURZ*2+B-5 or something like that. Or does that change the output? I'm not sure. And, with this negative trick, perhaps we no longer need B to toggle up and down 128 at a time - can we make it toggle just enough to switch from negative to positive? e.g. 8 ought to be enough? It might require more changes to the calculations to get that to work, there are so many things layered in there now it's hard to keep track of!
Neat code. Are you aware BBC BASIC has an inline assembly keyword I bet you would save ram and speed it up using that.
SGNPOS ought to work instead of (POS>0) saving 3 characters. Are the brackets after RND optional as well? They usually are for single argument things.
You need the brackets after RND (unless you only want a floating number between 0 and 0.999 but you might be able to tweak that). SGNPOS looks promising but it yields 0 and 1 not 0 and -1 and so there's need to be further tweakage. I'll have a think about that in the departure lounge!
Yep, good move - that saves three bytes:
B=B*(1-2*SGNPOS)
@@lsbyte now I wonder about B=BEORSGNPOS with 128* elsewhere. Or maybe B=128ANDB-SGNPOS with B=0 initially - so I think B would then swap between 0 and 128?
B=128ANDB-SGNPOS and then COLOUR130-B:COLOURZ*2+B-1 saves three more bytes.
@@lsbyte I think VDU 15,31 can be combined in decimal to save a byte. Now the thing I've been meaning to think about is that you don't need to go up to 128 to change the background colour - you can just go negative instead. Leaving B as-is, you should be able to change COLOUR130-B to COLOUR-2-B without affecting the output. And, maybe that pesky leading "-" can be removed if we also invert the other COLOUR statement, e.g. COLOUR2-B:COLOURZ*2+B-5 or something like that. Or does that change the output? I'm not sure.
And, with this negative trick, perhaps we no longer need B to toggle up and down 128 at a time - can we make it toggle just enough to switch from negative to positive? e.g. 8 ought to be enough? It might require more changes to the calculations to get that to work, there are so many things layered in there now it's hard to keep track of!
Change mode with a VDU?
Single digit line number?
All stored as two bytes regardless of value!