First, a little terminology, the plug that plugs into the link port is composed of 3 parts, the sleeve, the ring, and the tip. The sleeve, (the part closest to the wire) is electronic ground (0V). The other two (the ring and the tip) are both data lines. By default these sit at 3V.

Ok, so when you open up calcsys and look at port (00h), you'll notice that it reads 03. It's reading 3 because both the tip and the ring are at 3 volts (the tip is bit 0 and the ring is bit 1).

Now, a pair of headphones is basically a short circuit from both the tip and ring to the sleeve. In normal operation the tip goes to the left earphone and then to ground and the ring goes to the right earphone and then to ground. But, the main point I'm trying to get across here is that the headphones lower both the tip and the ring to 0V. So now, to see what I'm talking about, you can plug a pair of headphones into your calculator and you'll notice that port (00h) now reads 00 (and your calculator is relatively frozen).

The basic idea here is that when disconnected, both the tip and the ring will gives 1's over port (00h). But when you connect them to ground (the sleeve), they will read 0.


Now that that's out of the way, you can start messing around with your accelerometer. The basic idea here is that when your accelerometer is tilted to the left, it will connect the ring to ground and when it is tilted to the right, it will connect the tip to ground (you can swap left/right ring/tip). The way to do this is up to you, but the simplest way would simply be a marble in a tube that connects the circuit when it reaches either end.

Edit:
   In axe, you can read the value of port (00h) by using the "Port" command (ClrTable).

I think you might win the award for most dedicated to a calculator project. I remember this being an ongoing project over at UTI back in 2008 when I first started. And I thought it was dead back then! But here you are 4 years later, (after my complete trip through high school), still working on it.

I congratulate you.

^{*Yes, assembly programmers can come up with dozens of ways to get around that. None of them will integrate cleanly with Axe.}

That honestly stopped me from writing like 5 different examples he could use. But I agree with DrDnar, you'll have to call external programs.



But the real reason I'm posting is to clarify his question. I'm fairly certain he wants to use an appVar like a .dll. Basically, he wants so be able to use runtime libraries to that he can simply call them at will from his program.

So, to answer that question, no, you can't easily do that, and here's why:

• Where the appvars are stored, they are not executable
• The appvar would have to be pulled out of flash and stuck in ram (this is similar to what simply running it does)
• To be able to call the right routine in the appvar would absolutely require asm (and a lot of code counting)

While a runtime library axiom could in theory be created, you're best just to use libraries that go into the compiler (or just copy/paste the code). Also, you'll notice that in the past, all runtime libraries on the 84+ have been apps (xLib, Mirage, Doors, Celtic3) because apps can execute in place.

This sounds like a job for OFFSCRPT.

OFFSCRPT.8xv (appVar) gets copied to $8001 every time the calculator turns off. This catches both 2ND + ON as well as APD. So instead of going to APD, it can just display your screen saver.

Here's what your OFFSCRPT would look like:
.org $8001
bit 4, (iy + 8)
ret z ;this was a purposeful turn off


;do whatever you want, here's an example if you want to run an axe program

ld hl, axeName
rst 20h
bcall(_executePrgm)



;when you are done, you have two options

ret ;this will turn the calculator off

bcall(_jForceCMDNoChar) ;this will turn the calculator on

axeName:
.db protProgObj, "AXEPROG", 0


I realize this isn't exactly an axe answer, but, this is what must be done.

Ok, so there's no good way to do what you're trying to do.

Firstly, two functions you should know about:
nDeriv(expression, variable, value)
solve(expression, variable, guess)

Now, the way these work, is the first one will take the derivative for you, so nDeriv(x^2,x,2) will give you 4, and nDeriv(x^3,x,y) will behave like 3y^2 (though it will be far slower).

solve( is just the functional way to use solver. expression is what is set equal to zero, so if we want x^2 = 0, we would do solve(x^2,x,1) = 0. The trouble with this is that it will only find one of the zeros, and an example of this is x^2 = 4. If we rearrange that we get x^2 - 4 = 0. So solve(x^2,x,1) = 2 and solve(x^2,x,-1) = -2. But the key is you have to guess correctly for both.

Now, the actual code that does your work is going to look like this: solve(nDeriv(expression,variable,Y), Y, guess). Again, to find the critical point of x^2, you would do solve(nDeriv(x^2,x,y),y,1) and this will spit out 0.


Here's the trouble, that worked great for that equation because it only had one critical point. But if it has two, you need to run it twice with different guesses. I don't know how to detect the number of critical points nor decide where to guess, so that one will be up to you.

The best thing I can say for this would be to quickly graph the derivative and then decide how many critical points you think there are. Something like this might do the trick.

nDeriv(equation,x,x) -> Y1
ZoomFit
2->XRes
Trace
Prompt for number of zeros
Prompt for each guess

For(A,1, number of zeros)
solve(Y1, x, guess[A])
End


Edit:
   Sorry, missed your code example, so my post is a little less relevant, but still works.

There's a chance it's not all gone. Try running rebuild.8xp on a fresh ON + CLEAR.

If the garbage collect hung, it may not have finished.

Edit:
   And then, after that, get everything off your calculator (or nothing depending on circumstances) and clear all memory to make sure whatever froze it is gone.

Agreed. Nothing out there can mess up your calculator.

Here are ways to fix any problems that occur (the numbers assume you've done each previous step):
1. Press ON [Fixes 75% of crashes]
2. Remove battery and then reinsert it [Fixes 98% of crashes]
3. Remove battery and then hold DEL while inserting it [Fixes 99% of crashes]
4. Remove battery and reinsert it. Hold CLEAR while pressing ON and then clear all mem. [Fixes 99.9% of crashes]
5. Remove battery and then hold DEL while inserting it, at this point, attach it to your computer and send a new OS over [Fixes 100% of crashes]


Though, to be fair, if you get to step 4, you should talk to us.