Author Topic: Axe Parser (Read 494249 times)

Runer112 · « **Reply #2130 on:** January 12, 2012, 06:29:05 pm »

Sorry for the double post again!

Well, I found a solution to the issue! The easy way to fix it would've been to simply add 5 or 10 bytes of code to the existing method. But I wanted to minimize as much code bloat as possible in fixing this bug, and I would say I certainly did. Not only did I fix the bug, but the hook is now a byte smaller!

Code: [Select]

.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
 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
 ld de,AxiomTokens
 call TokenHook_AxiomSearch_Start
 pop hl
 ld (editTop),hl
 B_CALL(_BufToTop)
 pop hl
 ld (editTop),hl
 pop de
TokenHook_SkipAxiomSearch:
 inc e
 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)
 inc 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
TokenHook_AxiomSearch_Loop___:
 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
 push hl
 ld bc,(TokenHook_Temp)
 add hl,bc
 ld bc,-AxiomTokens_End
 add hl,bc
 jr c,TokenHook_AxiomSearch_Loop___
 ld hl,(TokenHook_Temp)
 ex de,hl
 pop bc
 call p_CopyArc+5
 res statsValid,(iy+statFlags)
 pop bc
 pop hl
TokenHook_AxiomSearch_Start:
 ld (TokenHook_Temp),de
 ld a,$FF
 ld (de),a
 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,"var"
 .db $5A,$02,4,"appv"
 .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 $FF

EDIT: This code was changed at 11:15PM EST on 1/12 to fix a critical bug that made all key programming tokens in the PRGM menu inaccessible. Please do not use any copies of the code made before this time!

EDIT 2: [10:00PM EST 1/13] Changed the "var" and "appv" token replacements to use the standard lowercase "v" instead of the recursive one. None of the OS tokens, including the recursive equation tokens themselves, actually use the recursive equation characters 02h-04h, so there's no reason why Axe should either.

Freyaday · « **Reply #2131 on:** January 12, 2012, 11:05:36 pm »

* Freyaday falls over

Quigibo · « **Reply #2132 on:** January 13, 2012, 02:10:22 am »

Cool! Don't worry, I'm incorporating this feature later after a queue of other features that I need to finish, so you have some time to modify or improve it if you think it needs that

.

Runer112 · « **Reply #2133 on:** January 17, 2012, 05:19:29 pm »

Quote from: Quigibo on January 10, 2012, 03:24:22 am

Some things I'm particularly curious about:
- The token numbers are difficult for developers to type in manually, any ideas of how I could generate a list of equates?

After searching around and not having found any existing list of token hook equates, I figured I should compile one myself, and I did. Feel free to include it in the next release of Axe.

http://www.ticalc.org/archives/files/fileinfo/445/44517.html

Quigibo · « **Reply #2134 on:** January 17, 2012, 06:18:51 pm »

Wow, that is incredibly helpful! That will make it much simpler for Axiom developers to include their own token replacements (and myself too). I will definitely find a place for this in the package

Quigibo · « **Reply #2135 on:** January 30, 2012, 02:57:48 am »

I'm currently in the process of merging the token replacements. However, one problem I see is that subprograms would not be able to use the replacements because they would each be unaware of which program is the parent (and there could be more than one with different axioms).

To solve this, the #Axiom() command will now be ignored if it's been imported already. Currently, #Axiom(A):#Axiom(A) either throws an error or puts the axiom on the stack twice (which will quickly fill up the 5 Axiom limit). This way, you can redefine the relevant Axioms again in each sub-program to see the token replacements in the editor, and the code will compile as expected without error.

Runer, I'm also changing your new suggested syntax of the SDK. Its basically the same except it doesn't have $C0DE again nor the size. It knows the size of the Axiom ahead of time and can use that to determine how many token replacements to import. So it's still reverse compatible and simpler to write because you simply list them after the $0000.

Runer112 · « **Reply #2136 on:** January 30, 2012, 03:10:03 am »

Those all sound like good ideas. I'm surprised I didn't think of just using the size of the appvar to determine if token replacement data exists, and if so, how much data there is. Smart thinking, and it simplifies things.

Quigibo · « **Reply #2137 on:** February 02, 2012, 11:24:04 pm »

So the main thing I wanted to talk about in the new release is the new "Axe Fusion" compile option. I was previously calling this "Axe Framework" but fusion is more literal to what is going on, implies that it requires Axe, and sounds cooler.

To reiterate, what this option does is not add ANY built-in Axe routine to your program. These include things like All DispGraphs, all Sprite commands, all drawing, advanced math, etc. Instead there is a tiny routine routine added to the start of the program that finds the Axe app and steals the routines from there (like a shell). The header in Fusion files is literally identical to the Ion header and it should still work in all major shells. In the end, this reduces code size a lot, usually over 10% sometimes higher than 20%.

Keep in mind that this is a beta feature, meaning it is very unstable right now. First of all, I would not recommend publishing Axe Fusion programs on sites targeted to end users because those programs may not work with future versions of Axe. Second of all, I'm not sure if it is working with Axioms right now, I didn't have time to check.

So basically, I added this feature prematurely so that you can all test it out and tell me what you think. How much is it reducing your code sizes?

Juju · « **Reply #2138 on:** February 02, 2012, 11:32:13 pm »

That sounds pretty interesting. So with this Axe Fusion thing, the Axe app would act like Ion/MirageOS/DoorsCS?

Freyaday · « **Reply #2139 on:** February 02, 2012, 11:35:12 pm »

How would Fusion work with the program compiled to an app?

thydowulays · « **Reply #2140 on:** February 03, 2012, 12:17:24 am »

Fusion isn't an Option in the options menu, it's an actual compiling option, so instead of compiling it as an app, you compile it as "Axe Fusion"

Freyaday · « **Reply #2141 on:** February 03, 2012, 07:54:16 pm »

Oh. That makes sense.

Eiyeron · « **Reply #2142 on:** February 12, 2012, 12:54:42 pm »

Just axe fusion + zoom compilation gives us real FAST debug build! :p

DJ Omnimaga · « **Reply #2143 on:** February 12, 2012, 03:02:29 pm »

Quote from: Quigibo on February 02, 2012, 11:24:04 pm

So the main thing I wanted to talk about in the new release is the new "Axe Fusion" compile option. I was previously calling this "Axe Framework" but fusion is more literal to what is going on, implies that it requires Axe, and sounds cooler.

To reiterate, what this option does is not add ANY built-in Axe routine to your program. These include things like All DispGraphs, all Sprite commands, all drawing, advanced math, etc. Instead there is a tiny routine routine added to the start of the program that finds the Axe app and steals the routines from there (like a shell). The header in Fusion files is literally identical to the Ion header and it should still work in all major shells. In the end, this reduces code size a lot, usually over 10% sometimes higher than 20%.

Keep in mind that this is a beta feature, meaning it is very unstable right now. First of all, I would not recommend publishing Axe Fusion programs on sites targeted to end users because those programs may not work with future versions of Axe. Second of all, I'm not sure if it is working with Axioms right now, I didn't have time to check.

So basically, I added this feature prematurely so that you can all test it out and tell me what you think. How much is it reducing your code sizes?

This seems interesting, does it means those programs would be dependent on Axe Parser presence on the calc? If so, then I guess a good idea would be for the programmer to publish both versions of his games, so those who have many Axe games can simply keep Axe on their calc and save a lot of space, kinda like how small some Doors CS programs are.

Hayleia · « **Reply #2144 on:** March 02, 2012, 07:31:40 am »

Now the stupid question:
Could Axe possibly be ported/cloned to the Nspire series, using Ndless ?
Maybe even if it is not on calc ?

Author Topic: Axe Parser (Read 494249 times)

Runer112

Re: Axe Parser

Freyaday

Re: Axe Parser

Quigibo

Re: Axe Parser

Runer112

Re: Axe Parser

Quigibo

Re: Axe Parser

Quigibo

Re: Axe Parser

Runer112

Re: Axe Parser

Quigibo

Re: Axe Parser

Juju

Re: Axe Parser

Freyaday

Re: Axe Parser

thydowulays

Re: Axe Parser

Freyaday

Re: Axe Parser

Eiyeron

Re: Axe Parser

DJ Omnimaga

Re: Axe Parser

Hayleia

Re: Axe Parser