Sorry for the double post, but technically, this is a project update!


I fixed everything that I knew was bad about the previous version of the token hook that I posted. The updated hook is now:

• DoorsCS compatible!
• zStart compatible!
• Compatible with any Axiom name length!
• Faster!
• Smaller!
• And stronger, too!

.nolist
#include "ti83plus.inc"
.list

#define cxPrevApp cxPrev+cxCurApp-cxMain

#define p_GetArc $55E7
#define p_ReadArcApp $5658
#define p_CopyArc $568D

#define TokenHook_Temp appRawKeyHandle
#define AxiomTokens statVars
#define AxiomTokens_End curGStyle

.org $71E0


TokenHook:
.db $83
ld a,(cxCurApp)
cp kPrgmEd
ret nz
ld bc,(EditTop)
ld a,(bc)
cp tDecPt
ret nz
inc bc
ld a,(bc)
cp tDecPt
jr z,TokenHook_IsAxe
sub tA
cp tTheta-tA+1
ret nc
TokenHook_IsAxe:
push hl
ld hl,cxPrevApp
ld a,kPrgmEd
cp (hl)
jr z,TokenHook_SkipAxiomSearch
TokenHook_AxiomSearch:
ld (hl),a
push de
ld hl,AxiomTokens
ld (iy+statFlags),h
B_CALL(_BufClr)
ld hl,AxiomTokens-AxiomTokens_End
ld (TokenHook_Temp),hl
B_CALL(_IsAtTop)
push de
push hl
B_CALL(_BufToBtm)
B_CALL(_IsAtTop)
sbc hl,de
ld b,h
ld c,l
ex de,hl
call TokenHook_AxiomSearch_Loop
pop hl
ld (editTop),hl
B_CALL(_BufToTop)
pop hl
ld (editTop),hl
pop de
TokenHook_SkipAxiomSearch:
ld hl,AxeTokens
ld b,0
jr TokenHook_CompareLoop_Start
TokenHook_CompareLoop:
cp e
inc hl
jr z,TokenHook_LowByteMatch
TokenHook_NoMatch:
inc hl
ld c,(hl)
inc c
add hl,bc
TokenHook_CompareLoop_Start:
ld a,(hl)
or a
jr nz,TokenHook_CompareLoop
TokenHook_DoneNoMatch:
add hl,hl
ld hl,AxiomTokens
jr nc,TokenHook_CompareLoop_Start
pop hl
ret
TokenHook_LowByteMatch:
ld a,(hl)
cp d
jr nz,TokenHook_NoMatch
TokenHook_Match:
ld de,localTokStr
push de
ld c,17
ldir
pop hl
pop bc
ret


TokenHook_AxiomSearch_CheckHeader:
call ReadArc
inc de
add a,c
ld bc,$C0DE
sbc hl,bc
ld c,a
ret z
pop bc
TokenHook_AxiomSearch_Loop__:
pop bc
TokenHook_AxiomSearch_Loop_:
pop hl
TokenHook_AxiomSearch_Loop:
ld a,tAsmComp
cpir
ret po
push hl
dec hl
dec hl
ld a,(hl)
cp t2ByteTok
jr nz,TokenHook_AxiomSearch_Loop_
TokenHook_AxiomSearch_Backtrack:
dec hl
ld a,(hl)
cp tSpace
jr z,TokenHook_AxiomSearch_Backtrack
sub tColon
cp tEnter-tColon+1
jr nc,TokenHook_AxiomSearch_Loop_
TokenHook_AxiomSearch_FindAxiom:
pop hl
push hl
push bc
dec hl
rst 20h
ld hl,OP1
ld (hl),AppVarObj
ld a,tRParen
ld bc,10
cpir
dec hl
ld (hl),b
ld l,OP1&$FF
call p_GetArc+1
jr c,TokenHook_AxiomSearch_Loop__
TokenHook_AxiomSearch_FoundAxiom:
ex de,hl
ld c,b
call TokenHook_AxiomSearch_CheckHeader
ld b,32+1
TokenHook_AxiomSearch_ScanAxiom:
call ReadArc
inc de
ld a,h
or l
jr z,TokenHook_AxiomSearch_EndOfAxiom
add hl,de
ld de,5
add hl,de
ex de,hl
djnz TokenHook_AxiomSearch_ScanAxiom
TokenHook_AxiomSearch_EndOfAxiom:
call TokenHook_AxiomSearch_CheckHeader
call ReadArc
inc de
ld a,c
ld b,h
ld c,l
ld hl,(TokenHook_Temp)
add hl,bc
jr c,TokenHook_AxiomSearch_Loop__
ld (TokenHook_Temp),hl
sbc hl,bc
push bc
ld bc,curGStyle
add hl,bc
pop bc
ex de,hl
call p_CopyArc+5
jr TokenHook_AxiomSearch_Loop__


ReadArc:
ex de,hl
xor a
cp c
jr z,ReadArc_RAM
push bc
push hl
call p_ReadArcApp+11
pop de
inc de
pop bc
ret
ReadArc_RAM:
ld e,(hl)
inc hl
ld d,(hl)
ex de,hl
ret


AxeTokens:
.db $F4,$03,5,"Copy("
.db $FE,$03,5,"Exch("
.db $0E,$04,5,"Freq("
.db $66,$01,5,"Buff("
.db $62,$01,5,"sign{"
.db $06,$00,5,Lconvert,"Char"
.db $08,$04,4,Lconvert,"Hex"
.db $02,$04,5,"Data("
.db $4E,$01,7,"Bitmap("
.db $02,$00,4,Lconvert,"Tok"
.db $80,$04,7,"#Axiom("
.db $04,$04,5,"Rect("
.db $06,$04,6,"RectI("
.db $58,$02,3,LrecurV,"ar"
.db $5A,$02,4,"app",LrecurV
.db $5C,$02,3,"grp"
.db $F6,$01,4,"port"
.db $52,$01,5,"Text "
.db $D8,$01,8,"Pt-Mask("
.db $DA,$01,7,"pt-Get("
.db $D0,$01,3,"Get"
.db $14,$04,5,"rotC("
.db $16,$04,6,"rotCC("
.db $18,$04,6,"flipV("
.db $1A,$04,6,"flipH("
.db $C8,$03,7,"inData("
.db $B8,$01,5,"input"
.db $74,$01,6,"float{"
.db $72,$01,4,"nib{"
.db $F6,$03,9,"#Realloc("
.db $68,$01,6,"#Icon("
.db $80,$01,2,Llambda,"("
.db $38,$03,5,"Load("
.db $3A,$03,5,"Next("
.db $14,$03,7,"Render("
.db $3C,$03,6,"DrawL("
.db $3E,$03,6,"DrawR("
.db $16,$03,6,"DrawS("
.db $82,$03,6,"Print("
.db $44,$03,3,"Up("
.db $46,$03,5,"Down("
.db $5C,$03,5,"Left("
.db $40,$03,6,"Right("
.db $42,$03,4,"New("
.db $5E,$03,7,"Delete("
.db 0


Why add a whole new command for it? Just make Data() not barf when you put static data inside of it, and making speedy data LUTs with anonymous entries would be a piece of cake.

Data("Hello"^r,"there!"^r,"I"^r,"am"^r,"a"^r,"LUT"^r,"of"^r,"strings."^r)→Str0

Axe doesn't have this functionality yet, which is why I spent the time to make a prototype version that does. I haven't released it anywhere, since I think Quigibo would rather I give it to him and let him possibly tinker with it a bit and then release it officially. And existing Axioms don't have any token replacement data, so even with this new system, they will act just like they do currently. Only Axioms designed with this new system in mind will have token replacements. However, it is possible to tack on token replacement data to old Axioms if you properly resize the appvar and add in token replacement data.

Currently, I'm putting cached Axiom token replacements in appBackUpScreen, because I know that the OS will not touch this. Except for when you run an app, as the name suggests, but at that point you've exited the program editor. I still need to ask thepenguin77 if zStart wants this area of RAM when editing programs, in which case I should probably find another spot.

Pretty much, I detect whenever the source code open in the program editor has changed to become an Axe program (this mainly applies to the action of opening an Axe program). I then scan the entire program for any AsmComp( tokens (that's #Axiom( in Axe). For each one found, I check that it's in a valid position (e.g. not in the middle of a line, in a string, etc.) and then attempt to locate the appvar. If found, I skip to the end of the Axiom and check for a second header after the standard Axiom footer that signals that the Axiom includes token replacements, and if so, these token replacements are cached in RAM. Then, it's just the simple matter of running the token hook as usual, but checking this area of RAM in addition to Axe's built-in token replacements.

Although to be fair, the whole process wasn't a simple matter. Every time I wanted to test a change, I had to hex-edit my hook into the Axe application. And I tried to do the whole thing in a very optimized manner, which means trying multiple code possibilities every step of the way. I must've spent over a dozen hours on this thing.


One thing that this upgraded hook does not do is dynamically check for Axioms while the program is being edited. Adding such a feature would be a bit of a pain and probably add at least 50 bytes and slow down the hook, so I figured it's just best to leave it out. If you want to reload Axioms, it's easy enough to do so by closing and reopening the program.

That is a great approach, FloppusMaximus! The best part is that your solution perfectly fits my more general goal, though I didn't even tell you what it was:

• While the program editor is open, save the edit buffer's state
• Move all the edit buffer data to one end
• Parse the (now gapless) data
• Restore the program editor to its original state like nothing ever happened

The B_CALL(_BufToBtm) at the start of your routine perfectly takes care of step two. And since the position I'm jumping to is just a saved (editCursor), calculating and validating the jump point can be completely cut out! So for my purposes, everything I need to do boils down to just this:

ld hl,(editTop)
push hl
ld hl,(editCursor)
push hl
B_CALL(_BufToBtm)
call ParseProgram
pop hl
ld (editTop),hl
B_CALL(_BufToTop)
pop hl
ld (editTop),hl


Excellent thinking, FloppusMaximus. I may end up just trying to parse the data without removing the edit gap if if the code to do so is smaller overall, but for the question I asked, you've given what must surely be the best answer.

That works, but I feel that there's some OS routine that will do it for me and save me 10 or 20 bytes.

I've been fantasizing about such a system as this for a long time, as it can be used both to conserve executable size and to allow for the use of larger but faster routines. However, your post wasn't very clear to me regarding one important matter: Will the old compilation style remain?

One thing that always turned me off about some programs is their dependency on a shell, especially when they hardly needed any of the routines in it. Although I always have Axe on my calculator, others may not, and they may not want it. And if you're compiling your code as an app and not right up against the size limit, you can afford to have the routines included in your app.

I think it would be best for Axe users to be able to control exactly how Axe compiles their program: with size-optimized included routines, with speed-optimized included routines, or with speed-optimized external routines. I would then advise programmers to follow logic somewhat like this as a guideline to compile and release their work:

• If you are compiling your code to a program
  
  • If you use one or no large routines (e.g. DispGraph, Pt-On())
    
    • Compile with included routines; optimization style is up to you
  • If you use large routines
    
    • Compile for both included routines (optimization style is up to you) and external routines; include a readme explaining how the two are different and let the user choose
• If you are compiling your code to an application
  
  • Compile with speed-optimized included routines
  • If the application is too large
    
    • If speed is important
      
      • Compile with external routines
    • Compile with size-optimized included routines
    • If the application is too large
      
      • Compile with external routines