Yes, calls can be conditional. They can also use all the conditions not just z nz c nc. Like m for negative or p for positive.

To compare two 16 bit numbers, use:
or a
sbc hl, de
add hl, de
This affects the flags the exact same way that cp hl, de would if it were a real command.

Also, you only need one inc hl after you write a variable to memory. That's because A is one byte, ld (hl), a stores one byte, so you only need to increase one byte. If you have a bigger number to store, you have to split it into bytes. So DE is stored E then D.

I have found one source of the problem. When the OS makes the group, it stores the start page and address in a temporary memory location. It then loads them in the OS specified page and address spot. The only problem is that the routine it calls to setup the group header, happens to also use the temporary memory location. So what happens is that the page gets first put by the main program, then increased by the header program, and finally the main program grabs it and raises it again! These ERR:VERSION groups actually start at the beginning of one page, and restart at the beginning of the next.

What worries me is that the best way to fix the problem was actually to NOP 15 bytes. Not only that, TI went through and optimized this section for 2.53. That means they looked at it, saw nothing wrong, and continued on.

But that's only half the problem! After I patched it up to make the groups, it can't read them. The group was definitely created successfully because GrpTool can read it. Plus it was readable after it got relocated on a garbage collect. TI just doesn't want us to use groups.

So, wait.
How did you trigger this error?

I GC'd to erase all memory. Then I filled the first flash page up until it only had 3 bytes left. (Flash isn't truly erased until GC it is just marked dirty). Then I made a group.

What makes groups different than programs and the other variable types though?  Because I'm pretty sure those can have headers on the page boundary.

What makes them different is that they have very specific code that creates and reads them! The ERR:VERSION groups function normally anywhere else, unless they corrupted the next page.

Now I'm off to find part two of this horrible group handling.

Edit:
   Found the second one, it only occurs if the group starts <4 bytes from the end of a page. TI almost did it right, they checked for page crosses, it's just that they assumed that it wouldn't change pages.

Edit 2:
   For those that want to jump the gun, I finished the patch for 2.53. Tomorrow I'll have to make one for 2.43, maybe the 83+ and SE too if I can find some roms. It won't run on anything but, 2.53. Don't run it if you know your batteries are low and especially don't pull a battery. I was even nice enough to make it so that it won't say ROM failed in the self test.

Sorry about that, _memClear is in my mind as _clearMem, I don't know why I always mix them up. As long as you give it an HL that is not in front of your program, and a bc that is >=2 it won't crash.

As for accessing them, I'll draw a picture.

Here is ram before.
prgmA | prgmB | MirageOS appvar | prgmDESTROY | etc....

When you call make appVar, the OS makes a hole in the programs for yours to go, so:
prgmA | prgmB |   500 + 2 byte hole   | MirageOS appvar | prgmDESTROY | etc....
                    ^
Then when you call chkFindSym on it, it will tell you that yes, your appVar exists, and that you can find it's start in DE. DE is now pointing to that line in front of the hole. The first thing you have to do is skip two byte, these two byte are how big of a hole was created. Now you have 500 bytes to do whatever you want with.

To access it, you have to do it through hl or de. ld (appVar), hl won't work because at assembly time, the assembler doesn't know where the appVar is going to be. It's location can even change within your program if you make another appVar. You then have two options:

If you have just a little bit of data to store, you can do this:
ld hl, name
rst 20h
bcall(_chkFindSym)

inc de
inc de

ex de, hl

ld (hl), a
inc hl
ld (hl), b
inc hl
ld (hl), c
inc hl
ld de, (score)
ld (hl), e
inc hl
ld (hl), d
You can see how this would get ugly if say you needed to store 500 bytes. The other option is to set up your memory usage to accommodate the final saving. Here is how you could do that:
dataStart equ appBackUpScreen

enemyBuf equ dataStart ;256
bulletBuf equ enemyBuf+256 ;256
score equ bulletBuf+256 ;2
lives equ score+2 ;1
reload equ lives+1 ;1

dataEnd equ reload+1 ;1


ld hl, name
rst 20h
bcall(_chkFindSym)

inc de
inc de

ld hl, dataStart
ld bc, dataEnd-dataStart
ldir
This method is good if you need to store buffers and such. Then to access them, just do it in reverse. For the first example, just switch (hl) with the other register and it will pull data out instead. For the last one, ex de, hl and you will be copying to your data area from the appVar.

_player that is all correct except the type is 15h.

@Jerros, here is a nice routine to get you to the start of the appVar. It will create it if it doesn't exist, and it will unarchive it if it's archived.
getAppVar:
ld hl, appVarName
rst 20h ;move9ToOp1
bcall(_chkFindSym)
jr nc, found

ld hl, size
push hl
bcall(_createAppVar)

inc de ;skip size bytes
inc de
ex de, hl
pop bc
bcall(_clearMem) ;fills hl with bc 0's
jr getAppVar
found:
ld a, b
or a
jr z, inRam
bcall(_arc_unarc)
jr getAppVar
inRam:
inc de
inc de
ret

appVarName:
.db appVarObj, "appVar", 0, 0
;  15h

Just be sure to archive it when you program quits.

Edit:
   The appVar is just like regular ram, you can use it however you see fit. Just be sure that you use it the same way consistently. Like, don't save the first byte as highscore, and then read the first byte as achievements.

I've never modded games per se. But I have used cheat engine to screw with them. On the old Destination Saturn for DOS, I think I gave myself unlimited lives and ammo and such.

I also have this demo program that only runs for 20 minutes and then it closes. So every time I run it, I go into memory and change the dec to inc. That way my time counts upwards.

If rst 20h is move9ToOp1, then there's not problem there, it's just copying memory.

I'm more worried about executing the name. Just because you write .db data, doesn't mean that the calculator knows that it's data. Most of the letter ($40) commands are safe, just ld a, b type stuff. But the numbers would be dangerous. 0 ($30) and 8 ($38) are jr's, 1 and 3 modify sp, 2 i modify's a random byte, and 4, 5, and 6 modify (hl).

But as long as there are no numbers in the name, that will work perfectly.

DJ, you are saying have the assembly program run the exact same code that the basic one does and come up with the same result?

It might be remotely possible, but it would take a ridiculous amount of time. Plus the assembly is usually longer. Mine is really two separate programs in one. Only the first 4 bytes are used by both.