If native registers were supported, it would only be the most basic use of the registers: loading, adding, subtracting, and shifting, plus maybe a few simple things I'm not thinking about.  It would only allow things that are legal in asm so you wouldn't be able to add b and c and store the result in d.  Don't forget that part of implementing the 8 bit mode is moving the variables close enough to relative reference with IY so there are more optimizations possible.

By the way, I'm taking an assembly class using MIPS architecture (very similar to ARM) which feels like such a higher level language compared to z80.  Those instructions are specifically designed to translate from C compilers and only now do I realize why there haven't been many good assemblers for z80 so far .

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.

What about an alternative half byte referencing command?  I imagine that's what it would generally be used for anyway, so just take out the middle man.

Say I call this command nib{} which uses angle brackets like int{} since it's a referencing command.

[C0FFEE123456]->Str1
nib{Str1*2}   .returns C (12 in decimal)
nib{Str1*2+1} .returns 0
nib{Str1*2+2} .returns F (15 in decimal)
nib{Str1*2+N} .returns the Nth nibble in memory

The only strange thing you might notice about this is that the pointer has to be multiplied by 2.  That's because wherever it points to is in bytes so if the pointer is at the 100th byte, it is actually at the 200th nibble.  That's done during compile time in this case so its not going to increase program size or anything.  But now there are 131,072 (2^17) possible addresses, and so that means you can only use this command for half of the memory.  Ram is in $8000-$FFFF which is exactly the range needed.  However that would suck for apps because they need the other half from $0000-$7FFF.  To remedy this, there would be 2 commands, one for programs/ram/archive and one for apps.  So nib{} and nib{}^r would work.

Would this be suitable?

EDIT: Oh, there could also be a store-to version for ram, like 5->nib{Str1*2+2} for instance.

Well, I'm not sure about the name checking, but to combine 2 ram appvars A and B into C, you can do this:

Return!If GetCalc("appvA")->A
Return!If GetCalc("appvB")->B
{A-2}r->X   .Size of A
{B-2}r->Y   .Size of B
Return!If GetCalc("appvC",X+Y)->C
Copy(A,C,X)
Copy(B,C+X,Y)
Delvar "appvA"
Delvar "appvB"


You can't have more than one interrupt running at once independently meaning an interrupt that interrupts the main code and the other interrupt.  But you can have multiple interrupt routines at once for different frequencies. Lets say you want one interrupt at 110Hz and one at 22Hz.  What you can do is setup a single interrupt at 110Hz (number 6) that increments a timer and when the counter gets to 5, then you call the 22Hz routine which also resets the timer.

Yeah, the OS interrupt needs to be on in order to use the BASIC getkey because it has to detect when keys are pressed in the background.  You could tack on your own getkey routine for a few keys to the end of your interrupt if you really need a feature like that.

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.

That's fine if your program disables the OS interrupt and doesn't use a single bcall.  But if it does, it's going to be reading and writing over your program memory where it expects all the OS variables to be causing the bcall to not work properly either so it will surely cause a ram clear.