Yeah, I've got that working already now, except there's a really weird bug I'm trying to fix.  The actual sort routine is very small and fast, its only 21 bytes and sorts a 256 element list in about 1/4 of a second in 6MHz mode.  I'll probably make it larger though to handle sizes greater than 256.  I'm using insertion sort.

By the way, the main focus of the next version will be on variables.  I already have Ans saving and loading working, I expect to have strings, real variables, Picture files, and other things like that all readable and writable.  And I'm also going to add the ability to create programs.  It's possible some existing syntax might change but that seems unlikely at the moment.

Awesome!  I'm going to like these new commands.

calcdude: Excellent visual.

Keep in mind App compiling will take over 10 minutes on-calc, though.

Interrupts would be nice for automated stuff, such as moving enemies, but I wonder if it wouldn't be a bit hard to work with and easy to mess things up?

Yeah, interrupts will be very easy to use.  You simply enable them with fnOn, disable them with fnOff, and set them up with fnInt(label) and that subroutine will execute every interrupt.  Simple! There will probably be an optional second argument for interrupt frequency too.

The HARD part is how I am going to code them.  I need to make a vector jump table somewhere in ram which will reduce the size of one of the free ram locations by at least 256 bytes (more becasue it will have to start at a particular address).  I'm not sure which one, but it has to be very stable because if it gets modified at all during execution, it causes the program to sometimes randomly jump to some random code in the ram and its very difficult to debug.  That leaves me with the L1 pointer only which sucks becasue that is the largest continuous region for data storage that you can always use.  L2 loses MOS compatibility with interrupts and L3 means you can't use grayscale or the backbuffer.

well...i guess i could give up part of L1 for interupts...ill just have to learn how to compress my data.

A custom interrupt sounds nice. That's obviously in im 2. Will the choices for interrupts in a program be either im 1 or im 2, or will you be able to disable them entirely or chain the standard interrupt to the end of the custom one?
Or, to put it more simply, how many choices do you get?

Yeah, interrupts will be very easy to use.  You simply enable them with fnOn, disable them with fnOff, and set them up with fnInt(label) and that subroutine will execute every interrupt.  Simple! There will probably be an optional second argument for interrupt frequency too.

The HARD part is how I am going to code them.  I need to make a vector jump table somewhere in ram which will reduce the size of one of the free ram locations by at least 256 bytes (more becasue it will have to start at a particular address).  I'm not sure which one, but it has to be very stable because if it gets modified at all during execution, it causes the program to sometimes randomly jump to some random code in the ram and its very difficult to debug.  That leaves me with the L1 pointer only which sucks becasue that is the largest continuous region for data storage that you can always use.  L2 loses MOS compatibility with interrupts and L3 means you can't use grayscale or the backbuffer.

That sounds really cool actually! =D That'll be fun to play with once you get around to implementing it.

That sounds neat!  Could you just append 256 bytes to the end of the program and use those as the vector table?  I like how it sounds so far.

Not that easy because the vector table has to be aligned in memory like every byte between $9900 and $99FF. And I think it is 257 bytes for some strange reason.