all the particle-based stuff that people have been tossing around was based on cellular automata, which is the same sort of idea behind conway's game of life. basically you just have to determine the rules that you think will give the effect you want(if you wanted fire, for example, you could run through all the pixels that are on, make that 'particle' move up one and, via randomiser, make it move left, right, straight up, or go out).
when you said animations, though, i was thinking something completely different initially. i'd rather like to see a method that uses vector graphics and scripting for dynamic animations

Actually, cellular automata can get a lot more complex than that. I had a really nice program that I could show demonstrating that but some stupid loops managed to RAM clear my calc 8 times last night... 

At least I finally noticed the "backup" feature of Axe 

Here's a dream I had several years that eventually became a game that I'm currently developing:

<open narrative>

You wake up in a dry, dusty desert. Tumbleweeds grow in scattered patches across the desert as far as you can see. You're surrounded by four thick, strong gates ringed with razor wire, the gate to the southeast slowly swinging in the small buffets of wind. Overhead, several black vultures circle, occasionally diving to ravage one of the numerous dead animals lying near the gates. You start across the desert beyond the gate, wanting to the reach the deep desert before the desert claims you for itself. It's rumored that surviving exiles live there in an area called Black Canyon. All you know for certain is that you can't return to the nation that exiled you on pain of death.

The sun glares down ever harder as you stumble across the desert, the day lengthening. Occasional howls from the distant mountains to the northwest drift across the endless sands. Coupled with the intense dehydration, they provoke wild hallucinations of the horrible creatures The Project is rumored to have summoned in those godforsaken hills.

...

You've been traveling for what seems like years. The sounds of the desert have driven you to near insanity.  However, it occurs to you that the landscape has subtly changed from the endless plains where you were exiled. Small shrubs have have replaced the prickly tumbleweeds and sandy plateaus gradually descend towards a narrow chasm splitting the landscape. As you approach the dark chasm, the wind howls around you, shrieking and deafening. You note the dark stone composing its sheer walls, which descend into a misty abyss whose depths cannot be seen. This is Black Canyon.

I was looking up system routines and I noticed how many of them use the OP registers. However, hex equates in the TI83plus.inc file (which I presume are the addresses) don't match up with the addresses on WikiTI. Is this because of the change from 83 to 83+ and if so, are the addresses in the 84+ and SE's different as well?

C/ASM files can be a maximum of 1 MB of code and data, excluding the .g3a header.

I'm using a Win 7 64 bit comp with USB 2.0 as well...

As for the driver, I'm fairly sure I'm using Casio's own drivers, because the Prizm installed them when I got it.

Here are some of the errors that can be generated by the AUX_DisplayErrorMessage() syscall. It takes an integer argument and generates these messages for each value. Execution of the program continues normally after EXIT is pressed.

1: "Break
Press:[EXIT]"

2: "Syntax ERROR
Press:[EXIT]"

3: "Ma ERROR
Press:[EXIT]"

4: "Memory ERROR
Press:[EXIT]"

5: "Go ERROR
Press:[EXIT]"

6: "Nesting ERROR
Press:[EXIT]"

7: "Stack ERROR
Press:[EXIT]"

8: "Argument ERROR
Press:[EXIT]"

9: "Dimension ERROR
Press:[EXIT]"

10: "Com ERROR
Press:[EXIT]"

11: "Transmit ERROR
Press:[EXIT]"

12: "Receive ERROR
Press:[EXIT]"

13: "Memory Full
Press:[EXIT]"

14: "Undefined
Press:[EXIT]"

15: "Overflow ERROR
Press:[EXIT]"

16: "Out of Domain
Press:[EXIT]"

17: "Non-Real ERROR
Press:[EXIT]"

18: "No Solution
Press:[EXIT]"

19: "Mismatch
Press:[EXIT]"

20: "No Variable
Press:[EXIT]"

21: "Not Found
Press:[EXIT]"

22: "Application ERROR
Press:[EXIT]"

23: "System ERROR
Press:[EXIT]"

24: "Already Exists
Press:[EXIT]"

25: "Complex Number
In List
Press:[EXIT]"

26: "Complex Number
In Matrix
Press:[EXIT]"

27: "Can't Solve!
Adjust initial
value or bounds.
Then Try again.
Press:[EXIT]"

28: "Range ERROR
Press:[EXIT]"

29: "Time Out
Press:[EXIT]"

30: "Condition ERROR
Press:[EXIT]"

31: "Syntax ERROR
Press:[EXIT]"

32: "Range ERROR
Press:[EXIT]"

33: "Circulat ERROR
Press:[EXIT]"

34: "No Real Roots
Press:[EXIT]"

35: ----

36: "No Real Roots
Press:[EXIT]"

37: "Version ERROR
Press:[EXIT]"

38: "Card ERROR
Press:[EXIT]"

39: "Card is protected
Press:[EXIT]"

40: "Invalid Card
Press:[EXIT]"

41: "No Card
Press:[EXIT]"

42: "SD Card Full
Press:[EXIT]"

43: "Storage Memory
Full
Press:[EXIT]"

44: "Data ERROR
Press:[EXIT]"

45: "Invalid file name
or folder name
Press:[EXIT]"

46: "Data is protected
Press:[EXIT]"

TI's FP number format is kind of...

Well you can read about it for yourself here. I'm not very good at explaining it.


If you want to match the number range, you'll need to use the IEEE 754 Double FP format. That can handle numbers up to around 10^308, compared to the 10^128 handled by TI's routines. It's only 8 bytes large, so you sacrifice some precision for that, but you'll still get excellent accuracy within normal ranges.