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?

There is only one unfixable bug right now which is that after DispGraph commands, you need to turn interrupts back on again because they sometimes get turned off after a while.  Other than that, there is no problem with using interrupts for grayscale.  You have to use them the correct way though like the assembly programmers do.  That means your interrupt just increments a counter and your main program draws the grayscale once the counter gets to a certain point.  You can't have the 4 level routine inside of the interrupt routine itself because it uses the shadow registers for a speed optimization. But like I said, you should never be putting huge routines like that in interrupts anyway so its not a problem.

Personally though, I don't recommend them because they make the code larger and slower.  You should only use them when you are actually using them for their timing.  Games generally update the display pretty regularly anyway.  Even when there is a big variation in the amount of objects in a room, its not too hard to make the grayscale automatically adapt for that by doubling frames.

To answer the other question, this:
{L1-54}^r->B

Parses identically to this:
A->B

There is no difference in the executable since this is an auto optimization.  The subtraction is during compile time.

(1)  {L1-54}
(2)  A^256
(3)  {L1-53}
(4)  A/256

In these examples, (1) and (2) do the same thing and both take 5 bytes.  No optimization there.  (3) and (4) also do the same thing, but in this case, (3) takes 5 bytes and (4) takes 6 bytes so there actually is a slight optimization.  Just for reference, r1-r6 as well as the Y0-Y9 files can also be accessed this way, but you would need the exact hex address becasue they aren't simple offsets with any of the L1-L6 buffers.

just out of curiousity: why do you use the 'space': 0x20 in the name of the parser itself, but in the compiled versions the 'zero': 0x00 after the name?

thanks...

time to go on a coding spree in the last 16 hours before school starts

Axe does not use short circuit logic.  It's not on purpose, its just that its more difficult to parse and requires it to read it as a bunch of nested blocks instead of a single statement.  I certainly would want to add it, but at this point it would break too much compatibility with previous versions.  Its something I plan to change in Axe++ which would have a slightly different syntax since it doesn't need to be completely compatible with 1.0.

Would Axe++ be some sort of new Axe language or more like an add-on?

I think it's a completely new version of the parser.

That'd be a great idea Quigibo, by the way, since there wouldn't be compatibility issues between two versions of the same program.

Runer112, I don't know how tempSwapArea is actually used.  The TI Developer's guide claims its only used when archiving, but they have been wrong before.  My gut tells me its probably a bug in your program, but its certainly possible that some other bcall or interrupt could be screwing it up.  Maybe ask another asm programmer exactly what its used for if you're still not convinced.