question lists
1: How does it work?
2:How do I use it?
3: Can I see the example(code) of it?

question lists
1: How does it work?
2:How do I use it?
3: Can I see the example(code) of it?

1) Code that modifies itself while it's running is called "Self-modifying code."

2) You modify the code, then you change PC to point to the modified code. However, there are very few situations in which SMC is the only way to write a program. I would highly recommend avoiding it if at all possible, especially if you're working with Axe rather than ASM.

3) Cue calc84...

Just to clear things up. SMC is purely changing your code on the fly to do things more efficiently. You would typically want to do this in very time sensitive sections that get executed thousands of times per second. (i.e. bullet/enemy collision checks) The general idea is to setup the code with some "fairly constants", like the x/y of the enemy you are going to check against all 50 bullets, so that rather than pulling the x/y coordinates out of memory for all 50 bullets, they are hard coded into the routine.

What does this mean for axe? Unless you know asm very well, and understand Axe to the level that you could compile programs yourself, you should not touch SMC.


Now, what you are trying to do with copying your routines into appvars and using them later will not work in Axe. There are two reasons for this: 1) You can't execute the appVar where it lies because it is probably in the $C000 range and will insta-crash your calculator. 2) Axe code meant to be run at a certain memory address in the calculator and from a certain program. When compiling, Axe has to hard code in locations for it's internal routines (like ClrDraw) so that it can call them without crashing. And not only that, but the actual code itself has to call itself which means it has to be run from a very specific address in memory. If you just copy the back end off an axe program off and store it in an appvar. The only way to make it function would be to copy it back to the exact same spot in the exact same program.

If you copy it back to any other address (any of the other 32,767 addresses) or in any other program (even a recompiled version might not work) the routine is going to crash.


What can you do? Really, your only option for something like this is just to make your minigames into separate axe programs and have your main program call them. Or, you could always just put all the minigames into the same file

wouldn't it be possible to create the program, then use something to copy it over to an appvar and then, during runtime, create a new one full of 0's and copy it over? it seems a bit impractical, but i guess it prevents the user from accidentally running just the subroutine program...

It would be hard to do because some of the z80's commands use absolute addressing.  The appvar has a dynamic address, allowing for multiple appvars.  Simply put, Axe code from an appvar would jump to weird places in memory.

In all practicality, it is near impossible in Axe, and probably will always be. 

What can you do? Really, your only option for something like this is just to make your minigames into separate axe programs and have your main program call them. Or, you could always just put all the minigames into the same file

I couldn't word it better. 

If the program that is turning the appvar into a program is an application, this gets incredibly easier, and in fact might just be a BCALL or two away.  I do not remember the specifics, but you should be able to run programs from an application no problem.

Oh, that's true.  I didn't realize that.  All you have to do is copy the appvar into $9d95 and change the page in $4000 to the system bcall page.  Then again, if you have an app's worth of memory, you might as well put all of the minigames into that app.

Self modifying code for the purpose of speed optimization is not practical in Axe because by definition, you are modifying at the instruction level.  Since Axe does not deal with assembly instructions directly in its syntax, you would have no idea what instructions to change.  Instead what you want is self modifying code at the language level.

Suppose you have some long complicated routines:
:A+(B*C)-D->E

Lets say sometimes, you need to use * between B and C and other times you need a + and other times you need a - and occasionally you need a /.  So instead of writing 4 routines with an if statement to pick between them, you would like to self modify the code so you avoid if statements all together for "faster" code. (May or may not actually be faster in Axe) But from a high level programming point of view, you can imagine that modifying the code directly avoids having to make an extra check against one or more if statements.

The good news is that you actually CAN do this.  This is what lambdas were meant for and why they're so powerful.  The code can be written like this instead:
:A+(Z)(B,C)-D->E

:λ(r1*r2)->Z
:λ(r1+r2)->Z
:λ(r1-r2)->Z
:λ(r1/r2)->Z

Using any of the lambdas once modifies the code so that all future calls to the big routine will use the new operation until you set it something else.  You can use the same method for even more complicated things:

:(Z)(5,6,Pic1)

:LOr->Z
:LXor->Z
:LOff->Z

:Lbl Or
:Pt-On(r1,r2,r3)
:Return
:Lbl LXor
:Pt-Change(r1,r2,r3)
:Return
:Lbl LOff
:Pt-Off(r1,r2,r3)
:Return

So yes there is a way to sort of do self modifying code in Axe, but other than making it easier to code, it doesn't really optimize anything since SMC optimizations can really only come from the instruction level.