If I understand what you are saying, you are trying to make a basic program that compiles another program to assembly. Are you using some kind of library/shell or how are you reading files in basic? Do you plan on having some small hex libraries? Also, I would imagine that the time needed to type in a whole compiler in by hand would be huge and the likelihood of the user making a mistake would be high. Debugging an assembly/compiled program can be tricky enough to a new user without having to worry if they had a small typo somewhere in the 10k+ bytes of the compiler program. While I won't dissuade you from the project, there seems to be some pretty huge difficulties involved. Additionally, you probably have a pretty small audience. How many people do you think would be interested enough in the language to spend hours copying it over by hand (assuming they don't have a cable)?

As for the optimized routine, what language do you want it in? Since you say strings I assume you mean basic.

Alright, here are a couple guesses.

For(K,1,L) is starting at 1 and not 0. Is that what you want?

Z+1≠N doesn't change any value and so the loop in CheckRight is pointless unless you use the value of N at some point outside the function. Did you mean Return!If Z+1≠N ? If I remember correctly, the For loop will increment at the end and return that value. That means that CheckRight should always return L no matter what data it is given. (I could be wrong but either way there is no way your code is doing what you want it to)

You are also spilling into CheckRight like you did at the end of your main loop. It shouldn't be a problem but does waste time.

Wow, that's really neat. I don't have a use for that at the moment but I bet I can find one in some old, slow code.

How did you go about making the routine generator? I assume there are some simple rules it follows.

I, for one, welcome our new overlords as long as there will be a blue skin. I don't really care for Cemetech's shade of red. Since it is an acquisition, that means money is changing hands right? I won't sell my support for less than a brand new 4-function calculator!

If you can reduce every shape down to a series of lines (or can get away with approximating them as such) then you could just take the lines that outline the shape you want to test and check it against every line that makes up the environment. There are pretty simple formulas that you can use to check if 2 line segments intersect. If the calc you are using has a built in multiplication instruction it would likely be faster than drawing lines and use less memory depending on how it is implemented. But if you use really complex shapes or need precision with curved surfaces drawing to a buffer is your best bet. Drawing to a buffer also lets you save the buffer if the area doesn't change which makes it really fast.

If you are having trouble drawing to the larger area, you could use the built in sprite routines to draw the whole thing to the 240x128 area, copy that much to the 256x256 buffer, shift everything over, draw again, copy that much to the larger buffer and repeat until all the area is filled. If you are redrawing that every frame, it could get pretty slow.

Additionally, if you only have one object you are testing for collision, you can simply shift the environment around that one object. Since the things it will collide with will be inside the size of the default sprite drawing box, you don't need to worry about using a larger buffer. This does assume that you redraw the clipping buffer each frame/update.

Since you said you are making an rpg, I assume the environment is pretty static and using my second suggestion of a collision buffer, drawing everything to the screen just copying it chunk by chunk to the buffer is probably the best since it is the simplest.

Here is an axiom that I wrote a while ago to deal with 4 byte numbers and timekeeping. It uses the system clock so it is accurate to the second. If you need fractions of a second, you will have to use interrupts.

Commands:
All commands are located under Vars->Window->T/Theta or U/V/W

Time:
ClkOn //Starts the system clock if it isn't running already.
ClkOff //Stops the system clock and sets it to 0. If you want to zero the clock, just turn it off and back on. Note that this resets the user's on-calc clock as well. Not that anyone really cares...
GetTime(^oPtr) //Sets the 4 bytes pointed to to the current time in seconds. If you are expecting time to be less than 16 hours, you can just read the first two bytes of that. For example you can do GetTime(^oA) and then just read A to get the time passed in seconds. (Although doing so will modify B as well)

4 byte math:
Although you didn't ask for this, Ill document it anyway since there is a lot of 4 byte math commands in the axiom.
All commands return their first argument.

Add(^oPtr1, ^oPtr2) //Adds the number pointed to by ^oPtr2 to ^oPtr1. ^oPtr2 is unchanged. Like all 4 byte commands, this returns the first argument, ^oPtr1.
Add(^oPtr1) //Increments the 4 byte value pointed to.
Sub(^oPtr1, ^oPtr2) //The same as Add( but subtracts the numbers instead. ^oPtr2 is unchanged.
Sub(^oPtr1, ^oPtr2)^r //Returns the sign of the subtraction operation. Basically it returns 1 if the value pointed to by ^oPtr1 is greater than ^oPtr2, 0 if they are equal and -1 (65536) if ^oPtr2 is greater. The contents of ^oPtr1 and ^oPtr2 are unchanged
Sub(^oPtr1) //Decrements the value pointed to.
Ld(^oPtr1, ^oPtr2) //Sets the value pointed to by ^oPtr1 to the value pointed to by^o Ptr2. Basically {^oPtr2}^r->{^oPtr1}^r:{^oPtr2+2}^r->{^oPtr1+2}^r
Ld(^oPtr1, low, high) //Loads the value of low, high into ^oPtr1. Basically low->{^oPtr1}^r:high->{^oPtr1+2}^r
Ld(low, high)^r //Loads the value of low, high into a temporary spot and returns the pointer to it. Useful if you want to do a constant operation (like adding 285 to a number) but don't want to have a dedicated scrap area of memory for it. There can only be one at a time so make sure you aren't using the value of the last one before using another.
Ld(^oPtr1)^r //Sets the 4 byte value pointed to by Ptr1 to 0
Mul2(^oPtr1) //Multiplies the value pointed to by ^oPtr1 by 2. Like all 4 byte commands, it returns a pointer to its first argument, ^oPtr1. This means that doing Mul2(Mul2(^oPtr1)) is a good way of multiplying by 4
Div2(^oPtr1) //Works the same way as Mul2 but divides by 2 instead.
Mul(^oPtr1, ^oPtr2) //Multiplies ^oPtr1 by ^oPtr2. Unlike other commands, this modifies ^oPtr2. You have been warned.
Div(^oPtr1, ^oPtr2) //Divides ^oPtr1 by ^oPtr2. Unlike other commands, this modifies ^oPtr2.
Div()^r //Returns the pointer to the remainder of the last Div(^oPtr1, ^oPtr2) operation.
_min(^oPtr1, ^oPtr2) //Returns the pointer to the smaller of ^oPtr1 and ^oPtr2. This leaves both ^oPtr1 and ^oPtr2 unchanged. (but the result returned will be either ^oPtr1 or ^oPtr2)
_max(^oPtr1, ^oPtr2) //Returns the pointer to the larger of ^oPtr1 and ^oPtr2.


If you need a routine to display 4 byte values, I can share my text axiom.

Here is a subroutine I have thrown together really quickly. I haven't tested it but it should be able to run any program or appvar whose name is passed to it. It needs to be compiled as an app!

:Lbl Execute .Call it like :Execute("prgmNAME")
:Return!If GetCalc(r₁,Y₁) .Get the variable and return if we can't find it.
:New(_E9D95,0,{Y1-2}^r-2->r₁) .Create space for it to be copied to. Since we don't need the program's name anymore, we can store its size to r₁. The -2 is for the program header
:r₁:Asm(E5) .Push the value of the program's size. E5 *should* be the code for 'push hl' We need to push it because we don't know if the program we are running will destroy the variable we save it to. You could probably save it to _E9D93, but it is safer this way
:Copy(Y₁+2,_E9D95,r₁) .Copy the program to the area of memory we just created. The +2 is to skip over the program header BBh, 6Dh
: (_E9D95)() .Run the program
:Asm(E1)->r₁ .Get the saved value of size of the program.
:Delete(_E9D95,0,r₁) .Restore memory to how it was before we copied the program in.
:Return .Done!

Edit: Forgot about the 2 bytes for the program header