Bug Reports

[Quigibo]

I thought I'd start this in case anyone is finding any bugs.  Its important I find them now before I start hard coding everything.  There is only so much I can do with testing, so I need your help!

Verified
* Custom interrupt label names are not processed correctly . [Fixed]
* Interrupts get disabled randomly with DispGraph commands when enabled previously [Solution Unknown]
* Error scrolling corrupts program data when programs are extremely large [Problem Unknown]

Unconfirmed
* Compiler freezes regularly when compiling applications on some calculators
* The AXEGUESS example program is always winning with the number "4"

Please confirm any unreproducible errors so I can make more sense of them with your calculator model, factory letter, operating system version, and other hook based programs on your calculator if applicable.  Thank you!

[Builderboy]

It seems that OR does not work I have this program

Code: Select All | Copy To Clipboard

1 2 3 4 5 6

0->A 1->B If A=0 or B=0 Output(0,0,"HI End

And when i compile and run, nothing is displayed.

[Quigibo]

That's because I haven't implemented order of operations yet    It just goes left to right.

These are equivalent:

Code: Select All | Copy To Clipboard

1 2	If A=0 or B=0 If ((A=0) or B)=0

Instead, try this:

Code: Select All | Copy To Clipboard

1	If A=0 or (B=0)

Once I get to order of operations, this shouldn't be a problem anymore.

[Builderboy]

Ah i see.  Thanks for the info

[Iambian]

If anything, I'd suggest creating something of a "test suite" to help you out when you're adding in new functions. Sometimes, the addition or changing of something breaks old code and you'd never really know it.

Makes me wish I spent the time on such when I was going through decking out Celtic III with all them functions. I know it's a bit of work, but it should be well worth it.

[Builderboy]

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...

[DJ Omnimaga]

wow it exited quite abruptly

Usually, the calc gets unstable afterward, tho

[Eeems]

I would clear your ram just to be safe builderboy.

[Builderboy]

Good idea

* Builderboy rushes off to clear Ram and save lives *

And here is that program, I don't think i was doing anything wrong

Code: Select All | Copy To Clipboard

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

:DiagnosticOff : :0→A :0→B :0→K : :While K≠15 :getKey→K : :Output(A,B," :If (K=3) and (A≠15 :A+1→A :End :If (K=2) and (A≠0 :A-1→A :End :If (K=1) and (B≠8 :B+1→B :End :If (K=4) and (B≠0 :B-1→B :End :Output(A,B,"O : :End : :Return

And the 8xp file in a zip for ya

[Quigibo]

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.

[Builderboy]

Alright thanks ^^

I also have some bugs (well not quite bugs) with the output function.  When displaying a character/number on the bottom row, the rest of the screen is shifted up.  This would be nice if it could be turned off for output, as the scrolling migt disrupt other graphics.

My second gripe is that when displaying a single digit number at a certain location, the number doesn't actualy appear where the coordinates you specify are.  For this reason I don't think it's possible to display numbers in the left few colloms?

Just two things with output that I think might need to be changed

[Quigibo]

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

[Eeems]

When this code is run a first time it works fine, the second time doesn't though, it's probably due to the missing declaration on K at the beginning.

Code: Select All | Copy To Clipboard

1 2 3 4 5

While K=/=9 getkey->K Disp K Disp i End

[Quigibo]

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.

[DJ Omnimaga]

in BASIC, what I did with getkey is do 0getkey before the loop kicks in. That way if you pressed a key before the loop started, it was unregistered before loop starts, to prevent stuff such as menu option being selected automatically or cursor/character moving around by itself