Here's a pretty nasty bug. The length() routine isn't being inserted properly; the code for checking if the ON key is pressed is being inserted in its place. And that code doesn't have a return, which can cause very bad stuff to happen... If there's some table you can easily look at that simply has an incorrect value for the length routine, perhaps you should check all the other routines while you're at it.

Encountered in 0.5.3
GetCalc(Str1,W+Length(P)) threw a Bad Symbol at me upon encountering Length(). Changing it to Length(P)+W fixed it.

I have lots of those bugs. Sometimes, I unarchive the source, re-compile (ERR: Out of mem) then re-archive it and re-compile and everything works

That's not a bug.  Axe needs lots of RAM to compile, even when compiling for an app.  If you don't have enough on your calculator, it will throw an out of memory error.  Archiving the source will often free up enough memory to compile for large sources.

zTrumpet tells me that Axe makes trial apps. If that's the case, there's a really easy way to make them valid.

Here is a little section I wrote on the topic, and here is some code that you can put in Axe to make an app valid.

;###############################
;validate an app
;input: b = page
; flash = unlocked

validateApp:
in a, (02)
rlca
ld de, $1F18
ld a, $15
jr nc, havePageAndAddress
ld de, $1E50
in a, ($21) ;I know
rrca
ld a, $29
jr nc, havePageAndAddress
ld a, $69
havePageAndAddress:
push af

sub b

add a, a

ld h, 0
ld l, a
add hl, de
push hl
bcall(_getCertificateStart)
pop de
add hl, de

pop bc
in a, (02)
rlca
jr c, not83PBE
ld b, $1E-$15
not83PBE:
ld a, b
add a, $15

ld b, a
bcall(_loadCIndPaged)
ld a, c
ld c, b
and $80
ld b, a
ld a, c
ex de, hl
push af
bcall(_writeAByte)
pop af
ld b, 00
bcall(_writeAByte)

ret

It even has a check to make sure it won't crash if the app trials table is zeroed. Of course the proper thing to do would be to remake the entire certificate, but you probably don't want to be doing that. Plus, if you do end up writing 00 00 to the certificate, that kind of app will still run fine, so that's really not a problem.

@thepenguin77 Thanks!  I was avoiding that initially because some people were uncomfortable with modifying the certificate page.  But if you're sure that code works, I'll try it out.

@Runer112, I would have to modify a bunch of code in order to make data recursively definable.  Either that, or just allow a single non-zero byte to be filled instead of only zeros.

It looks like you were in the middle of changing the multiplication routine when you released Axe 1.0.3. If I had to guess, I'd say you were going to make a separate routine for simple multiplication that doesn't worry about the high 16 bits of the result, while using the old routine for *^ and **. This sounds like a great idea to me. It would save about 300 cycles for most multiplications and save 5 bytes if neither *^ nor ** is used in the program, which probably fits many programs. If you wanted to go even further with this optimization, you could split off yet another routine that doesn't worry about the high 8 bits of the result for fixed point multiplication. I would personally do this because I love speed, but it's up to you.

But enough of that, back to the actual bug. Right now the two separate multiplication routines are lumped into one, resulting in an unnecessarily big multiplication routine, as the second copy is useless. *^ and ** will not work properly either, since the first routine and thus the routine that is called for multiplications is the simplified routine that disregards the high 16 bits of the result.

Shoot!  I totally forgot I was experimenting with modifying multiplication and didn't revert it before releasing... But yeah that's why I was doing it, I figured since *^ and ** are used so rarely, it would be nice to have a 32bit multiplication routine for those and use the faster 16bit multiplication for *.  It would always be faster and still be smaller for most programs.

I think after these bug fixes I will upload 1.0.4 as an official stable version.