1) Do not use the variables A-Z or Theta or rand and use L1-56 as a third buffer.

I thought those vars were moved elsewhere to allow the usage of both the 768 bytes there and the variables?

Ah ok. I thought Quigibo said he might move them before.

I have an interesting request.  I request that the user variables are moved into L2 so that L1 can be opened up into a 3rd full screen buffer, or a larger span of memory.  L2 *is* the location for some interrupt data for MirageOS and Axe alike, but MirageOS does not seem to use the last 56 bytes of L2 and i believe Axe could be restructured in itself.  What do you think?  Is this possible?

I second this.

I don't really care where the vars are located. I was using their locations to edit them in some old code, but I replaced that code with new code, so for me this is not a problem at all. I could become very handy in cases when you need to store the current screen to an extra buffer, though you could use an Appvar for that. But when L1 would become 768 bytes, then it will be faster to use that, but the difference in duration would be unnoticably small, I think.

I'm not sure how _InsertMem and _DeleteMem work, but couldn't they mess up data pointers in the VAT? I thought they were used only in edit buffers.

Oh, I see.

And yes, I second (or whatever this is) the request to move the vars to L₂.

Builderboy mentioned earlier that Mirage doesn't use at least the last 56 bytes of L₂, so it should work. I don't think DCS has any built-in interrupts at all, so you can toy with L₂ all you want.