Ok, yes, what you are saying is true. The problem is that when you are working with 16 bit numbers, you are treating them as two sets of 8 bit numbers rather than a set of 16 bit numbers. To demonstrate, I have to go back in math a long time:

Let's say that you need to add two numbers together. Lets say 23 and 69.
     2 3
    +6 9
--------
Adding the ones, you get this:
     2 3
    +6 9
--------
      12

But that won't do, so we have to carry the one:
     1
     2 3
    +6 9
--------
       2

And we finally end up with:
     1
     2 3
    +6 9
--------
     9 2

Now, to put this into bytes: Let's say that you need to add two 16 bit numbers, $5678 and $BCDF. $5678 is two bytes of $56 and $78. So if we convert that to two decimal bytes, we get $5678 = 86 120 and $BCDF = 188 233.
    86 120
  +188 233
----------

We add the first bytes together, just like you do:
    86 120
  +188 233
----------
       353

353 is not going to fit into one byte. So we have to convert that to 97 and carry a 1 to the next byte:
     1
    86 120
  +188 233
----------
        97
So now we add the second bytes:
     1
    86 120
  +188 233
----------
   275  97
But what's that, another overflow:
     1
    86 120
  +188 233
----------
 1  19  97

So we can see here that the final result is actually 3 bytes. What you have to remember is that the bytes are dependent of each other when you are doing math operations on them. The exact same thing I showed here happens in subtraction. And when you multiply or divide two bytes, the results are really wrong because when multiplying two bytes, it looks like this:

$5678 * $BCDF = ($5600 + $78) * ($BC00 + $DF) = ($5600 * $BC00) + ($5600 * $DF) + ($78 * $BC00) + ($78 * $DF)

And then don't forget, when you add these separate operations together, there will probably be some carrying going on.


For signed numbers: first of all, you don't need to worry about them in addition and subtraction because the z80 actually handles it all for you:
;HL + DE

add hl, de

;HL - DE

or a ;clear carry flag
sbc hl, de

Then for multiplication, before the routine runs, you need to figure out what the sign will be at the end. So 1 * 1 = 1, -1 * 1 = -1, and -1 * -1 = 1. Then convert both of the operands to positive, do the operation, and give the result the proper sign.

Changing the sign is not as simple as just XOR'ing the whole thing with %1111111 11111111. If that was true, -00 would equal FF. So the best way is to make a routine like this:
negHL:
push de
ex de, hl
ld hl, 0
or a
sbc hl, de
pop de
ret
I use that quite a bit in my math routines.

I don't know how to do it in Axe, but what you want to do is exactly what Micheal_Lee said, make all your appvars start the same way.

So for example, make all of your appVars start with Yunhua98 or something. In memory it would look like this:

Y, u, n, h, u, a, 9, 8, <level data>.

Then, using some unknown Axe command, you would search through all the appVars and look for appVars that start in that way. Those would be your levels and you would display those names.

Yes, bcall(_delMem) exists. I believe you should download this. I pull it out about every 1 out of 4 programming sessions.

And two byte subtract? sbc hl, rr. Where rr is bc or de. Just remember though that since this is sbc and not sub, you will have to make sure the carry flag is not set. So typically, you will see it used like this.
or a
sbc hl, de


The header for real search would be:
;############################################
;input: a = field length
; bc = field offset from start of data
; de = start of appvar
; hl = ptr to field to match

So you can call it if you want. There are two ret's out of realSearch, the first one is the good one, where DE = the start of the data section, and the second is just an error ret.

When you write an app, you have to do some different things to make it run on the calculator.
1. Your code will be running from the $4000-$7FFF page, which means you need to do .org $4000 instead of .org $9D95
2. You need a header, (which you can get from here)
3. You will have to use bcall(_jForceCMDNoChar) or similar to return as the OS jp's to the app, it doesn't call it
4. Most bcall's that take ptr's for inputs won't work if you give them an address in the $4000-$7FFF area. What this means is that you either need to reimplement bcall(_putS) with bcall(_putC), or copy all your strings to ram before displaying them
5. Obviously, don't change port 06 unless you have copied your routine to ram


6. And most importantly, you must compile your program for hex and then sign it, I would highly suggest that you just use spasm and make the output .8xk rather than .8xp. This will save you a lot of trouble.

Oh, yes. I forgot to change it when I was retyping it. But at least you understand it enough to realize that it was wrong

Ummm... Maybe. I thought I tried that and it didn't work. But if it works for you, then good. There must be a flag or something we don't know about.

Here you go. This is a sample implementation of what you want to do.
ld hl, tokenHook
ld de, smallEditRam ;nothing touches this, ever
ld bc, tokenHookEnd-tokenHook
ldir ;copy it to a place where it won't get destroyed

ld a, 1 ;1 means ram
ld hl, smallEditRam
bcall(_enableTokenHook)
ret




tokenHook:
.db $83 ;necessary for hooks, indicates that it hasn't been overwritten
push hl
ld hl, $C8*2
or a
sbc hl, de
add hl, de ;essentially, cp DE
pop hl
ret nz
ld hl, cscText-tokenHook+smallEditRam-1 ;give it a ptr 1 behind where it should be
ret ;I do not know why

cscText:
.db 4, "csc(" ;length, then string

tokenHookEnd:

If you are writing an App, then obviously you do not need to relocate this to smallEditRam. If you get some compiler errors, (you will), check this to get the equates you need. (Ctrl + F to find what you need)

Also, don't forget that just because you changed the words, it doesn't mean that you actually changed the function. For that, you are going to have to go into the scary world of parser hooks.

Lastly, I just remembered that I actually wrote a guide on this.