L₁ points to the start of 712 bytes of RAM you can use for whatever you please. The variables take up space in memory just before L₁, so just make sure that all the data you store is at position L₁ or greater.

Edit: ninja'd

Oh, I forgot to mention: I hadn't been using L₁ in my program, and replacing all references to L₄ with L₁ seemed to fix the problem. It seems like it's not my doing that's causing the problem, which unfortunately means I can't fix it. I really don't think I'm missing anything, but if nobody can think of anything I may just have to do more extreme debugging.


EDIT: I was just browsing around randomly, and found this regarding tempSwapArea:

If you are using this area for data storage, avoid archiving any variables or using routines such as Regraph.

Maybe something besides archive and unarchive is messing with my data after all? It says "routines such as Regraph," suggesting that there are multiple routines that could corrupt data in tempSwapArea. Any ideas, anyone?


EDIT 2: I don't want to use L₁ because I plan to use it later, I might use interrupts so I don't want to use L₂, and L₃, L₅, and L₆ are needed for their usual functions. Perhaps I could just use a different area of RAM? Could either appData (8000h) or ramCode (8100h) be a safe alternative?


EDIT 3: After a bit of talking with Iambian, it seems that appData should be safe to use, and the 256 bytes present there should be enough for my purposes. So I guess this issue has been avoided, but it would still be nice to solve it and determine what was corrupting tempSwapArea.

Any chance of grayscale routines that play nicely with interrupts? I don't really mind if they're slower. Slower but more regular is better as far as I'm concerned.

Edit: Perhaps this could be implemented with a toggle in the Axe options menu? There must be grayscale routines out there that don't kill interrupts, right? Maybe just grab one that looks decent, tweak it a little bit for Axe, and (hopefully) not have to work too much on it.

Lol

L₁-55 is a constant that is evaluated at compile time, and accessing a byte at a constant address only takes 3 bytes. Getting the value of A alone takes 3 bytes as well, let alone operating on it. They are essentially the same, except in one case you specify the constant address and in another Axe specifies the constant address. Accessing one byte and two bytes at a constant address both take 3 bytes. And without the math that needs to be applied, you'll save bytes and speed by just accessing the individual bytes of a variable.

I was just asking Iambian how he gets grayscale to work in his project Escheron: Shadow over Ragnoth because I was wondering why it seems that every ASM game does grayscale in interrupts. Why exactly do the grayscale routines for Axe have problems with interrupts?

You're right, meishe. I forgot what he wanted the statement to do.

If he wants to be able to just do Disp D, the zero ending byte needs to be in the appvar. That's why I suggested the modification to the storing method.