I would need to do it and show the code in action to explain what I mean. I could maybe attempt a TI-BASIC demo, though, or if someone post an Axe made circle routine I could use it to show you.

I know the circle can be used for cool effects, but what I'm thinking is that its far more useful for a circle to disappear with a small radii than it is for a random effect to occur.  The first would be used far more often, and using the min() command each time would be a hassle and increase the code size.

Unknown Error: 3224869
I get this after I get a bad symbol error, and try to scroll to it.
This code is causing the error:
For(P,0,7)
For(O,0,15)
Output(O,P,{Str1+{O*4+(P*64)+(theta)+3}+({Str1+{O*4+(P*64)+(theta)+2}*2)+({Str1+{O*4+(P*64)+(theta)+1}*4)+({Str1+{O*4+(P*64)+(theta)}*8)}>Frac
End
End
Repeat getKey:End


That happens

Not again ahhhh...  

This is like the 5th time I've had to redo the negative numbers.  Is probably one of the most complicated parts about the parser since I not only have to parse it correctly, but also automatically optimize things like making a subtraction of a negative number an addition or ignoring double negatives for example.  Its extremely difficult for 2 reasons.  First of all, they don't behave like normal functions because they have no end parenthesis.  It would be a breeze to implement Neg() as a function or even X% where % is some kind of postscript symbol like the "squared" button.  But NO! I have to figure out where to put the closing parenthesis and its a lot harder than it sounds.  In builderboy's problem it was putting the parenthesis like this: -({R)} so making R negative instead of {R}.  The second reason negatives are annoying and confusing is that when the parser reaches a negative sign, it has no idea if the expression is a constant or variable because the 2 are handled very differently.  I have to use some look ahead parsing for that which just complicates things further.

Anyway, I've fixed the problem.  Hopefully I will find a better system for this soon.

Sorry this is so late (I hate being in a different time zone (BST) from anyone else ), but I if Axe were to add code that automatically checks whether the radius is negative, wouldn't it inflate the code? This would be a bigger problem than having the user do a min( as it would affect everyone's code, even if the radius never would go negative. Besides, the only plausible instance I can think of right now of a circle radius being negative (unless the author purposely hard-coded it that way for some reason) is where user input affects it (as in your example), so IMHO, it might not be worth it to add the extra code.

Actually that problem has already resolved itself differently than I though.  First of all the reason it was so strange was the way it handles pixels because it makes a call to the built in pixel drawing command to save space.  That routine is modular with base 256 so pixels way off the screen in any direction loop back.  So it wasn't a problem with the circle radii at all.  You can just draw the circle far off the screen and get the same problem.  So I decided I just wouldn't add any more checks and just keep it the way it is.

And no, a check in assembly is 2 or 3 bytes for the entire code since I can use flags and its only a single byte number whereas the min and max commands are probably more like 9 bytes EVERY time you call the routine.  Huge difference.

Yeah, I fixed that too.  I couldn't believe how dangerous it was before.  It required the high byte of both arguments to be zero but it never bothered setting them to zero because it assumed the input was already valid.  That really wasn't safe I completely forgot it was like that until I started the circle routine and noticed that.  Sometimes my optimizations compromise too much hehe.