It seems that OR does not work I have this program
0->A
1->B

If A=0 or B=0
Output(0,0,"HI
End
And when i compile and run, nothing is displayed.

Ah i see.  Thanks for the info

Ok i found another weird bug.  When compiling one of my programs, the compiler stops while compiling and a blinking cursor appears beneath the Compiling message.  No matter what button i press, the cursor just keeps blinking.  So i am forced to pull my batteries, but although i quit back to homescreen, there is no RAM clear

I'll try to get the program uploaded in a sec...

I would clear your ram just to be safe builderboy.

Thanks for the report.

When apps exit, they need special exit code so that what you're describing doesn't happen.  It sounds like there was a memory leak somewhere causing the app to exit early.  That's why it didn't reset the ram, because it wasn't actually frozen.  I'll let you know when I find the leak.  Thanks again.

EDIT: Okay found it.  Wow, that was a stupid mistake on my part.  To get around the error temporarily until the next version, don't use parenthesis in any place where they are not needed; if the order of operations is naturally going left to right anyway.  The compiler is supposed to ignore the parenthesis when you do this, but instead it exits early...

:If (K=4) and (B≠0
Change to this:
:If K=4 and (B≠0
Since K=4 is evaluated first anyway.

If you ever get this error again, just turn off your calculator and turn it back on and the problem will go away.  Nothing in memory should be affected.  Oh actually, maybe ram clear anyway since the "LOL" file will be corrupt.

I'll work on that.  Both of those are fixable, but I'm not sure if there's any built-in OS calls for that.  I can write my own routine, but I'm trying to make sure these programs don't use too much memory.  Luckily, the subroutine support can really cut down on size of the overall program.  Even the most basic things like this save memory:


:If 2sub(1)
:'code here'
:End
:If 3sub(1)
:'code here'
:End
:Lbl 1:<A:Return


The routine above saves 5 more bytes than if you were to use the strait forward way below.


:If 2<A
:'code here'
:End
:If 3<A
:'code here'
:End

You are correct, the variables start uninitialized.  Assume random garbage, not 0 or something predictable.  They will be preserved between consecutive runs of the program, but running pretty much any other assembly program or app will scramble most or all of the values.  So if you embed 2 different Axe programs into a Basic program, they can pass arguments to each other via preserved variables.  But you cannot use the variables as any sort of long term storage.

In you example, the first time it runs, K was probably something random but upon exiting the program, it became 9.  So when you run the program a second time, K is already 9 so the while loop is skipped.