The problem resides in this line:
Copy(P,A,1) ;Get specified length of first progname

It seems that what you want to do is read {P} and put it into A. However, what this is actually doing is reading {P} and putting it into {A}. The reason your debug text always displays 0 is because A retains whatever value it had before your program started, which was probably 0. At the next Copy(), you may think the copy would at least do nothing because A equals 0, but this is not the case. Because of how copying works, it will copy a whopping 65536 bytes from P+1 to L₁, horribly corrupting the contents of RAM and causing a certain crash. You want to use this instead:
{P}→A


Also, although this isn't causing any fatal errors, the P+4 in line 4 should be P+5.

ERR: ARGUMENT means that you called a command with too few or too many arguments. However, it should be impossible to call Text() with too many or too few arguments, which would suggest that something else is causing the problem. Try compiling the program with the source code in RAM, and when you get the error, press PRGM. Where does the program editor scroll to?

You can only have a certain number of nested conditionals before the parser no longer has enough RAM to keep track of them and is forced to throw an ERR: BLOCK. You can manually make ElseIf analogs that don't use nested conditionals by doing something like the following. They will result in the same compiled code too, so you don't have to worry about the fix bloating your code.

Code: (Uses nested conditionals) [Select] If -1    .Stuff   ElseIf -1    .Stuff   ElseIf -1    .Stuff   ElseIf -1    .Stuff   End

Code: (Doesn't use nested conditionals) [Select] If -1  .Stuff  Goto END End If -1  .Stuff  Goto END End If -1  .Stuff  Goto END End If -1  .Stuff  Goto END End Lbl END

Alternatively, if you're using 3 or more ElseIfs in a row, it's optimal to turn the whole chain into a subroutine, like this:

sub(IF)

Lbl IF
 If -1
  .Stuff
  Return
 End
 If -1
  .Stuff
  Return
 End
 If -1
  .Stuff
  Return
 End
 If -1
  .Stuff
  Return
 End
Return


Quigibo, if you add constant definitions to Axe programming, could you perhaps add it to Axiom programming as well? That's something I always thought would be quite useful. Perhaps add a new command type, AXM_CONST, that has a 2-byte value instead of a routine? And something that would be even more awesome is a type like AXM_VAR, that allows you to define custom variables that are fully compatible with variable auto-optimizations and dereferencing. Again, you'd probably want the routine data to be replaced by a 2-byte value, in this case a pointer to the variable.

EDIT: And while I'm talking about Axiom feature requests, I want to bump my request for support for offset calls.

Someone correct me if I am wrong, but I believe that RAM usage has nothing to do with battery life. If you're worried about battery life, you should be looking at things like CPU usage, GPU usage, screen brightness, bluetooth/wireless, and external devices.

Ah yes, it looks like that does it. It didn't occur to me that changing the token equate would have any affect on how the command is parsed, which I think is fair to say isn't that strange. But may I ask what exactly the purpose of AXM_DATA is then? Because I'm not sure how having a command that just adds data to the program would be useful. It doesn't return a pointer or anything, so it doesn't allow the data to be used by the programmer. And if the data was needed by another Axiom command, accessing it with something like REP_NET() \ ld hl,sub_Axiom# would add it to the program automatically.

This sounds pretty awesome, although I am a little worried that this will make programming in Axe less "authentic," if you know what I mean. Although I do see the merits as well. But is it even necessary to change the b prefix for binary to something else? When parsing, if the b is followed by a 1 or 0, treat it as an indicator of binary data. Otherwise, treat it as the b register.

JosJuice, assembly programs will run at 6MHz by default on every calculator model. They are fully capable of running at either 6MHz or 15MHz on the 83+SE and newer, as chosen by the programmer.