699. You've written a basic program to calculate pi to 999 digits.

(true. Never ran it since it would take 24 hrs though)

$8000 has at least until $8100 of nothing. And then the area from $8100 to about $8180 is also rarely used.

It's basically just used as a temporary do something area. That's what the OS uses it for.

Ok, bcall(_jForceCMDNoChar) tells the OS, "Go." But when you do this, the OS does not know that there is a program currently sitting in ram that needs to be deallocated, which results in a memory leak the size of your program. So here's how to get around that:

First, put a label "theStart" at the very beginning of your program (but after .db $BB $6D). Then put a label "theEnd" at the very end of your program. Now, instead of quitting with RET, quit with this.
quit:
ld hl, runner
ld de, $8000
ld bc, runnerEnd-runner
ldir

jp $8000
runner:
ld hl, $9D95
ld de, theEnd-theStart
bcall(_delMem)
bcall(_jForceCMDNoChar)
runnerEnd:

This manually deallocates your program (which obviously must be done from outside of it) and then does a jForceCMDNoChar. This might cause a one byte memory leak or something, so if it does, just increase DE by one there at the end.

Oh, and using RET instead of jForceCMDNoChar won't make the OS look at the recall queue. But then pressing [2nd] [mode] might make it happen.

Wow, unexpected development.

You would have 4,000 t-states per byte. I would use between 10 and 12 t-states as your unit. And then use those spare 1,140 to decode MP3.

Edit:
    No. You have so much ram that that's not even necessary. Decode the MP3 beforehand and then play it as a wav.

Those are wav files. I mean 8-bit wav files. Not midi's. I have no idea how those work.

The instructions are for what you do once you have read the header and are going to play music for real.

That sounds possible. As for hooks, you basically look through that list to see where the closest hook is to what you will be doing. For your purposes, I would say you want the raw key hook. That hook is called any time the OS receives a key press. So lets say that you decide that VARS is going to be your goto button. You would have to find a ram area that you don't think is going to be killed in the near future. My favorite is smallEditRAM, no one knows about it so it is never used; it will persist through almost all games.

Then at smallEditRam you will make the code for your hook, your first line must be a .db $83, this is so the OS knows that it is calling a hook and not jumping to an outdated address. Since this ram area is pretty small ~170 bytes, I like to make the code at this area find the real program in the archive, and stream the real code into appBackUpScreen. Then for your hook, the first thing you want to do is figure out which button was pressed, and if it wasn't vars, quit. Then if it was vars, you probably want to have some other qualifier so that the vars button is not useless, like the ON button which doesn't trigger the hook.

So now you are ready to do your calculations. Remember that since you are editing a program, the edit buffer is open and there is 0 free ram available. And when your calculation is done, I'm not exactly sure how you would put the screen back to normal you'll have to ask someone else for that. A bcall(_jForceCMDNoChar) might do it, but I think that will go to the homescreen. Also, don't forget to enable the hook with it's corresponding enable bcall.

Edit:
   Now that I think about it, don't stream the info in on every single key press, you're calculator will be sooo slow. Instead, do the checks in smallEditRAM and then stream in your calculator GUI code when you get a match.

I don't know how you do your enemy movements, but going in circles can be done with a look up table. The size of your circle will will affect how many entries you need to make it smooth, but here's how you would do it.

Make a table of the cosine's and sine's of the angles from 0 to 330 counting by 30's multiplied by the radius. If your circle is massive, you might have to go by 15's. Then, just treat those new numbers as the x and y velocities and just go to the next one every frame. And behold, a circle!

Here's a simple basic prog of what I mean:
:Radius -> R
:For(A,0,330,30
:Disp RCos(A),RSin(A
:End

Since those will be decimals, treat them as two by numbers where the upper byte is the whole part and the lower byte is the decimal times 256.