Author Topic: Axe Parser (Read 552421 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 552421 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