ERR: UNKNOWN ERR

Code: [Select]

:.TANGENT
:Lbl T
:  sin(→A)*256//cos(A)

Thank you very much.  That was a very easy error to fix.  I forgot to add signed division to the list of commands to perform as a stack operator (operates on parenthesis).  I hope more people will provide snippets of code that fail so I can see what it is that's a problem.  So far, I haven't been able to replicate any of the other errors, and I'm using it a lot on real hardware too.  If you just archive your program before compiling, it will save even after a ram clear, so you'll be able to post the error.  You can always email me if the code needs to be private.

EDIT: calc84, I'm looking into that too.

EDIT2: Yup, forgot about that.  Now a close parenthesis, enter, colon, or eof will assume it.

If you're using xor logic in Pt-Change() the blocks won't get erased.  That's the beauty of using xor.  It does however cause the pixels of the intersection to get inverted while the sprite passes through it.  Another way to avoid redrawing the screen is to just use a backbuffer.  Its just as fast recalling the backbuffer as it is to do a ClrDraw.

Next release will be around Wednesday June 16 if all goes as planned.  Yes, I am extremely busy with finals.  I probably won't log on here much until Monday.

You can start a new thread if you want.  It doesn't have to be in the Axe subforum either.

By the way, I looked at the code and there are a lot of optimizations possible.  I'll mention a few:

You should NEVER find yourself having to make big lists of non-data.  I noticed this in the Help routine.  I know its doted out, but if you want to do it efficiently, try this:

:.HELP
:If K=53
:  Fix 0
:  -1→A
:  Repeat sub(15)
:    sub(DT)
:    sub(GK)
:    If Ksub(1)→T and (A+1<number_you_will_need_to_determine)
:      While {A+1→A+Str00}:End
:    End
:    If K=4 and (A≠-1)
:      While {A-1→A+Str00}:End
:    End
:  End
:  sub(L)
:End


:.Draw Text
:Lbl DT
:  A→B
:  ClrDraw
:  For(J,0,9)
:    While {B+1→B+Str00}
:      Text(0,J*6+3,{B+Str00}►Frac)
:    End
:  End
:  DispGraph
:Return

You can then get rid of all those extra text subroutines.  I don't know if this routine works its untested, but you can probably see how it works.  Also, add a det(1) before Str00.

:      3→K
:      3-Xsub(M4)→W

Can be:

:      3→K-Xsub(M4)→W

:      0→D
:      2→K

Can be:

:      0→D+2→K


I'll add more stuff later.

i accidentally press enter while at home screen. ( last prog run before failed compile was the successful compiled prog )

Whoa, whoa hold up!  Something already sounds really wrong with that.  When Axe fails to compile a program and there were errors, the original program is supposed to be deleted even if it existed before.  Is it not getting deleted then?  That could be a clue as to what the problem might be, let me know.  Also, could you tell me the type of calculator you're using and maybe some other info like archive free, OS, other apps, etc.

Hmm, remember when I suggested you could use IX as a pointer to the variables for easier access when doing 8-bit operations? That would be too much of a hassle, we agreed. But what if you moved the variables to the END of savesscreen? Then they would be within the range of the IY register (which points 4 bytes after the end of savesscreen). Just something to consider

Hmm... interesting proposition.  Although it would optimize some operations like addition and subtraction, there is still one key advantage to using the existing variable slots.  By using only the least significant bytes of those variables, you never need to do "conversions" when you switch from word to byte mode.  You have to get input and output somehow otherwise there's not much advantage to the new mode.  By being able to skip the conversions, I think that will save more memory in the long run than by using the iy or ix registers.

By the way, I've further optimized that grayscale command and its basically the same size as my original now except way faster which is excellent.

@ztrumpet: I'm not sure if it actually works, I'm going to assume calc83manic tested it on his hardware and got it to work since he proposed it, but the main issue here is compatibility.  This isn't the only sacrifice I've had to make.  There are a few other places where undocumented commands could make routines more efficient, but that wouldn't please the Nspire users.  I could add waste instructions to the super fast routine, but it really adds a lot to the size since I have to add 3 times as many.

No, just the opposite.  Graphic intensive programs are going to be doing a lot of sprite drawing, especially when they have to draw to 2 layers, so those are going to be sped up and the screen is only updated at the end of all that.  On the other hand, if you only draw a few sprites, but still update the screen constantly, you won't get much of a speed increase using Full since most of the cycles are being spent refreshing the screen which takes a fixed amount of time regardless of speed.