Quigibo, perhaps that could be changed? You could change the arbitrary address calling routine to this:

p_CallHL:
.db 6
pop ix
ex (sp),ix
jp (ix)

At the cost of 3 bytes for the entire program and only 12 cycles per use, you could pass arguments directly to arbitrary functions. I pass arguments in hl to functions all the time, so this would actually save bytes. That, combined with the fact that it would result in more uniform code effects, makes me believe that this would be a nice change.

Hmm I guess I see the dilemma. But you get around it by having commands like DrawInv (BUF). Can this style of argument addition be used for Axioms as well? You'd probably need an extra bit or two of metadata per command, which could be piled into the command type byte.

I think I just performed the most ridiculous, impressive optimization I've ever performed on an Axe command. 27 bytes optimized down to 60% of its size: 17 bytes!

Code: (Old code: 27 bytes, ~220.5 cycles) [Select] p_DKeyVar: .db __DKeyVarEnd-1-$ dec l ld a,l rra rra rra and %00000111 inc a ld b,a ld a,%01111111 rlca djnz $-1 ld h,a ld a,l and %00000111 inc a ld b,a ld a,%10000000 rlca djnz $-1 ld l,a ret __DKeyVarEnd:

Code: (New code: 17 bytes, ~225 cycles) [Select] p_DKeyVar: .db __DKeyVarEnd-1-$ ld a,l ld hl,%0111111111110111 rlc h adc a,l jr c,$-3 ld l,%0000001 rrc l inc a jr nz,$-3 ret __DKeyVarEnd:

These are pretty rare finds, but I discovered a bug with the app and not the language. Axe doesn't unset G-T mode upon opening, only Horiz mode. There's a simple fix for this, and it's actually an optimization! Changing res grfSplit,(iy+sGrFlags) to B_CALL(_ForceFullScreen) should do the trick.

Also, when I was inspecting the first few instructions of the app to see what code should be changed to fix this, I saw 2 copies of set textWrite,(iy+sGrFlags). Any reason for this?



EDIT: Regarding screen modes, B_CALL(_ClrScrnFull) in the ClrHome command should probably be B_CALL(_ClrScrn). It's exactly the same as B_CALL(_ClrScrnFull) when the calculator is in full screen display mode, which is 99% of the time anyway, but it will correctly clear the homescreen if it's not in full screen mode as well.

EDIT 2: Also, perhaps there should be an Axe command for B_CALL(_ForceFullScreen)? Axe programmers could run into this problem of not being in full screen mode and then their program displaying very strangely, especially if they're printing text to the homescreen. Perhaps another Fix command would work, but you'd need to branch into 2-digit numbers. This would also require changing how multiple options can be chained together with Fix, but I didn't really like the old way anyways. And on a similar note of OS settings that can mess stuff up, how about adding the ability to enable/disable APD as well?

The first problem is the !If L-C-1 line. The fact that you typoed and actually meant !If L-C+1 is a problem, but not the main problem. The main problem is that you don't want the ! in front of the If.

The second problem is that, if a bullet is removed, the last bullet in the list is then moved into its place. But because the for loop just finished with that position in the bullet array, it moves to the next element, skipping the updating and drawing of the bullet that took the deleted bullet's place. To remedy this, tag on an L-- to go along with the C-- in the bullet removal code.


EDIT: Also, these aren't actually problems, but some of this code is unnecessary and could be simply be omitted. Want me to point out what pieces of code could be removed?

Being able to fill a block with one number (possibly words as well as bytes) is all I ever really wanted. I think the more complicated data insertion should be handled at a later date when you add macro support.

I'm not sure why everyone has been using Zeros(pointer,size) in their code. This is not valid syntax. Zeros() only takes a single argument, and that is size. You want to use Zeros(size)→pointer instead.

Assuming you're experiencing this problem with Axe 1.0.0 or above, see: http://ourl.ca/4072/236963