This could probably be done just as easily in Axe. All it would entail is reading entries from a list of strings for each key.

I rarely use the colon as an inline separator, and when I do, it's usually just to chain basic things like Fix 1:Fix 5. And I always make sure to close my parentheses. So this change would be fine with me.

Yes:

DelVar "prgmNAME"


This should be working menu code. The code on the left should make sense. The code on the right should do the same thing as the code on the left while being about two-thirds of the compiled size, but probably won't make sense. They both rely on the appvars being in RAM, but you could probably modify this to successfully detect them if they are in archive as well.

I've also attached 8xp files for both of these so you don't have to retype all this code. The code blocks are just so you can see what the code looks like.

Code: (Sane Axe code) [Select] ..MENU ClrDraw Fix 1:Fix 5 Text(1,0→Y,"blut") If sub(GET,1)  Text(8,Y+10→Y,"Chap 1") End If sub(GET,2)  Text(8,Y+10→Y,"Chap 2") End If sub(GET,3)  Text(8,Y+10→Y,"Chap 3") End Text(8,Y+10→Y,"Help") Text(8,Y+10→Y,"Quit") Fix 0:Fix 4 DispGraph FnOn Repeat getKey(15)  Stop  .Conserve batteries! End FnOff .Input: Arg1 = File number to look up Lbl GET  Copy("appvBLUTCH1",L₁,9)  .Copy the name to L₁  r₁+'0'→{L₁+7}  .Overwrite the last character Return GetCalc(L₁)  .Find the appvar

Code: (Insane (optimized) Axe code) [Select] ..MENU ClrDraw Fix 1:Fix 5 Text(0*256+1) Text "blut" 10*256+8sub(SMP) ⁻3 While 1  +1→I  If +3sub(GET)   Copy("Chap "[],L₁+2,5)   L₁+2sub(PMI)  End End!If I "Help"sub(PMI) "Quit"sub(PMI) Fix 0:Fix 4 DispGraph FnOn While 1  Stop  .Conserve batteries! EndIf getKey(15) FnOff .Input: File number to look up Lbl GET  +'0'→{L₁+7}ʳ  .Write the number and terminator  Copy("appvBLUTCH"[],L₁,7)  .Copy the name to L₁ Return GetCalc(L₁)  .Find the appvar .Print Menu Item Lbl PMI  Text  P+2560 .Set Menu Position Lbl SMP  Text(→P) Return

I'm not really sure why you would want to purposely misrepresent tokens. If that's what tiDE uses, I might even ask if that's a bug.

Found some optimizations for p_IntSetup:

Code: (Original code: 45 bytes, a lot of cycles) [Select] p_IntSetup: .db __IntEnd-p_IntSetup-1 di ld de,$8B01 ld a,d ld i,a ld a,l ld hl,$8B00 ld b,e ld c,l ld (hl),$8A ldir and %00000110 out (4),a ld a,%00001000 out (3),a ld a,%00001010 out (3),a ld de,$8A8A ld bc,__IntDataEnd-__IntData ld hl,$0000 ldir in a,(6) ld ($8A8A+__IntDataSMC-__IntData+1),a __IntEnd: .db rp_Ans,9

Code: (Optimized code: 42 bytes, a lot minus 5 cycles) [Select] p_IntSetup: .db __IntEnd-p_IntSetup-1 di ld de,$8B01 ld a,d ld i,a ld a,l ld hl,$8B00 ld b,e ld c,l ld (hl),$8A ldir and %00000110 out (4),a ld a,%00001000 out (3),a ld a,(hl) out (3),a ld d,a ld e,a ld c,__IntDataEnd-__IntData ld hl,$0000 ldir in a,(6) ld ($8A8A+__IntDataSMC-__IntData+1),a __IntEnd: .db rp_Ans,9

Also don't forget the two interrupt optimizations that have been suggested earlier! (removing di and removing port 6 SMC in programs)

---

Also, a bug report. After talking with thepenguin77 on IRC, I think I have confirmed my old belief that MemKit's Next() command has a bug regarding reaching the end of the VAT:

Next(): 2 bytes and a few cycles saved. Also, isn't the end-of-VAT check in the wrong place? I could be wrong because my VAT experience isn't too great, but because this routine checks for the end of the VAT at the start, wouldn't this command advance the VAT pointer to the end of the VAT and not recognize it as the end until the next Next()? This would cause problems with programs reading garbage VAT data for the last "entry." If I'm right about this (which may not be the case), the third block of code I posted should hopefully recognize the end of the VAT as soon as it hits it and never advance the VAT pointer to point to the end.

Code: (Original code: 26 bytes, 152/66 cycles) [Select]  ld    hl,(axv_X1t)  ld    de,($982E)  or    a  sbc   hl,de  ret   z  add   hl,de  ld    de,-6  add   hl,de  ld    e,(hl)  inc   e  xor   a  ld    d,a  sbc   hl,de  ld    (axv_X1t),hl  ret

Code: (Optimized code: 24 bytes, 144/66 cycles) [Select]  ld    hl,(axv_X1t)  ld    de,($982E)  or    a  sbc   hl,de  ret   z  add   hl,de  ld    de,-6  add   hl,de  ld    a,(hl)  cpl  ld    e,a  add   hl,de  ld    (axv_X1t),hl  ret

Code: (Optimized (and fixed?) code: 24 bytes, 144/113 cycles) [Select]  ld    hl,(axv_X1t)  ld    de,-6  add   hl,de  ld    a,(hl)  cpl  ld    e,a  add   hl,de  ld    de,($982E)  or    a  sbc   hl,de  ret   z  add   hl,de  ld    (axv_X1t),hl  ret

Aww, I was writing a big long post about inline if statements but you ninja'd me.

But the way you suggested it as a command would be nice. I figure the IS<( token would be perfect for this, as it's currently an unused token easily accessible in the programming menu. It even sort of makes sense without a token replacement if you read it as "is." It would be nice if it had 4 forms, like:

.If condition, true, false
iif(A=B,C,D)

.If not(condition), true, false
!iif(A=B,D,C)

.If condition, true
iif(A=B,C)

.If not(condition), true
!iif(A=B,D)

The latter two forms are a bit unconventional, but I could see them being used for optimization purposes. For instance, here is some code I wrote a long time ago. It moves a sprite around the screen according to user key input and draws it, and applies boundaries to the sprite so it does not move offscreen.

As small as I could get it, 345 bytes of executable code.

Code: [Select]

:.SMILE
:[004466000000817E]->Pic1
:DiagnosticOff
:0->X->Y
:Repeat getkey(15)
:ClrDraw
:getKey(3)-getKey(2)+X
:!If +1
:+1
:End
:-1
:Pt-On(min(,88)→X,getKey(1)-getKey(4)+Y+(=⁻1)min(,56)→Y,Pic1)
:DispGraph
:End


The fancy If stuff you see there is an optimized way of making sure the position does not become -1. However, I could only use it for the x coordinate.

---

EDIT: Ashbad, that would work, yes. But it would be unnecessarily bloated and slow. That would be about 1.5x larger than an inline if statement, and an incredible ~15x slower. It would also require the multiplication routine being added to the program, which may not have previously existed in the program and making the code even larger.