i dont think space should be wasted by unnecessary features. It would suck if when finished this app became 4 pages large instead of maybe 3 just because an easter egg was added

Also I think he's planning Ion/Mirage support in later versions. I would prefer Mirage, though, because with Ion you are limited in terms of RAM. Remember when installing it you lose like 2 KB of RAM, which doesn't happen in MirageOs

I am definitely adding 90 degree sprite rotation as well as horizontal and vertical flipping.  I'm still looking for some intuitive commands for this though.  To use it, you will want to copy a sprite to free ram and then flip it and draw it from there, otherwise, you might loose track of what direction it has been flipped so far.

Can Ion programs run fine in Mirage if Ion is not installed? If so, I guess that could work, too, altough I think I recall certain Ion programs crashed in MirageOs or vice-versa

The Core Of Light is one

Also there are Ion games that will crash in Ion and works fine in Mirage, for some reasons. Final Fantasy v1.198 is one. ARPGCS also tend to crash a lot in Ion, especially any Ion version other than 1.4.

I second the new List handling, as it could make the source a lot more readable, like Basic.  Although I understand that it is still in development and things like readability are in the works right now as features are being added

I cannot use the BASIC format for list handling.  L1(X) is ambiguous in BASIC since you can't tell if you are multiplying by X or finding the Xth element.  This always bugged me.  Similarly, in Axe, it can't tell if you are starting a new expression or finding the element of a list.

Don't forget, axe interprets a command written like this:

:Disp {A*2+L1}

As this:


:A
:*2
:+L1
:{}
:Disp


Both of these compile exactly the same way byte for byte in the executable.  So you can see why the parenthesis notation would be too ambiguous.

But YES, I am definitely going to add a byte data structure so you can define values in base 10 integers instead of just hex and strings.  It will be the same syntax as BASIC lists, but I think I will need to use something other than the curly brackets.

I'm thinking maybe ΔList() right now unless I find something better.

mhmm I see now why, I guess we might haev to leave things as they are now. However, I would really like to not have to store my list stuff in hex, because it can be annoying to modify the data or to convert it in the first place.

And I understand about trying to find tokens for non-existing TI-BASIC functions . Multi-Platform Language for Calculators team in 2004-05 got around this by having commands typed in the BASIC editor using individual ALPHA letters, for example, like this:

#CLRS            - Clears the screen
#TEXT <x> <y> <text> <color>      - Displays text
#LINE <x> <y> <x> <y> <color>   - Draws a line
#PIXL <x> <y> <color>      - Draws a pixel
#PIXT <x> <y> <var>         - Stores in <var> the color at (x,y)
#DRAW            - Updates screen
#SHFT <x> <y> <type>         - Used for scrolling, <type> specifies looping state (-1 = Loop, 1-3 standard colors)
#STOP            - abbr. for Store Picture (saves all color layers)
#RCLP            - abbr. for Recall Picture, shows the last pict saved with #STOP
#RECT <x1> <y1> <x2> <y2> <border> <fill> - Draws a rectangle in either a filled un unfilled state (.5 for no fill)
#DBMP <name> <x> <y>         - Displays a bitmap a (x,y)
#DISP <name>            - Displays a sprite at its stored position

That's quoted from MLC readme for the Casio AFX version (the code was the exact same syntax accross the TI-86, 68K, Casio AFX and 9860G calculators, and was gonna be the same on teh 83+Silver too). But as you can see, EVERY MLC command took 5 bytes! This is why I kinda prefer tokens to type commands, not to mention they're easy to access in prgm menu and CATALOG. Most tokens take one byte, others, two.

I also recall MLC for both the 83+ and the 86 being plaggued with the 8.8 (or was it 8.1?) KB code execution limit thing.