Ok, thanks
I'm guessing reading from the archive takes longer, but is it a large slowdown?

A helpful optimization hint: always put constants last!

{P+A}: 11 bytes, 61 cycles
{L₁+A}: 11 bytes, 55 cycles
{A+L₁}: 10 bytes, 51 cycles

Ok, thanks
I'm guessing reading from the archive takes longer, but is it a large slowdown?

Reading a single byte or word from the archive is about 30 times slower; it takes about 1600 cycles. If your program regularly reads from a relatively small amount of archived data at any one time, like the tilemap for a level, the best thing to do is Copy() the data from archive into RAM somewhere and read it from there. You can then access this data from RAM much more quickly during gameplay, and copy new level data from archive as necessary.

Yeah it is slower, but unfortunately it seems Runners documentation is lacking in that regards

You are right, I have not documented the speed of the archive reading commands. Reading from the archive uses OS routines so it is a bit harder to calculate the speed of, as I can't look at the code and simply calculate speed based on the instructions that make it up.

Added a quick FAQ/random answers section to the first post for things that I see many users having problems with

Axe doesn't support decimals, so you can't unless you wrote your own routine to display a 9-byte floating point number. It's possible but gets a bit complicated because of the way a float is structured: the first byte determines if it's real or complex and if it's positive or negative, the second byte subtracted by $80 (128) gives you the exponent (floating points are always in scientific notation), and the other seven bytes are the digits.

Each nibble in the last seven bytes is a digit. The first nibble in particular is the digit to the left of the decimal when written in scientific notation (the first non-zero digit from the left). Each digit is stored as a decimal digit, so the full 9-byte floating point for "1337" is

00 83 13 37 00 00 00 00 00

(all in hex).

Okay, thanks.
Another question: How can you use the Parser hook in an Axe program (In other words, what is the hex opcode?)

First of all, the hook needs to be stored in the form of hex. Just grab the opcodes for your parser hook and stick it in your program as data (stored in []→GDB1 or something similar). Make sure it starts with the byte $83, because that's what the OS uses as a signal for the start of a hook.

Then you need to copy the code somewhere in RAM where it won't be destroyed easily. A good choice is smallEditRAM, so to use it do Copy(GDB1,E90D3,LEN) where LEN is the length of your parser code.

To actually start the hook, use this code:

:E90D3
:Asm(EF2650)

That's all you need to do. To disable the hook, it's simply

:Asm(EF2950)

You'll have to write the hook code yourself in ASM, of course. See http://wikiti.brandonw.net/index.php?title=83Plus:Hooks:9BAC for information on how to use this hook.

EDIT:
I used memkit to get the name of a program in L1. How do I now do a GetCalc( for that program? I can't get a "prgm" before the name :S

Just store a 5 in before the program name and it should work.

is there a way to turn an "input" string of tokens into a normal string? in this particular situation, I want the user to be able to input a file name (for use with getcalc()

so i can treat it as a string? is there any way to store the output of "input" directly to a string?