0 Members and 1 Guest are viewing this topic.
p_GE0: .db 3 ld hl,1p_GT65535: .db 3 ld hl,0p_LE65535: .db 3 ld hl,1p_LT0: .db 3 ld hl,0p_GE1 =p_NE0p_GT0 =p_NE0p_LE0 =p_EQ0p_LT1 =p_EQ0p_GE32768 =p_Div32768p_GT32767 =p_Div32768p_LE32767 =p_SGE0p_LT32768 =p_SGE0p_GE65535 =p_EQN1p_GT65534 =p_EQN1p_LE65534 =p_NEN1p_LT65535 =p_NEN1p_GEconstMod256EQ0: .db 6 ld a,h sub const>>8 sbc hl,hl inc hlp_GTconstMod256EQ255: .db 6 ld a,h sub const+1>>8 sbc hl,hl inc hlp_LEconstMod256EQ255: .db 6 ld a,h add a,-(const+1>>8) sbc hl,hl inc hlp_LTconstMod256EQ0: .db 6 ld a,h add a,-(const>>8) sbc hl,hl inc hlp_GEconst: .db 8 xor a ld de,-const add hl,de ld h,a rla ld l,ap_GTconst: .db 8 xor a ld de,-(const+1) add hl,de ld h,a rla ld l,ap_LEconst: .db 7 ld de,-const add hl,de sbc hl,hl inc hlp_LTconst: .db 7 ld de,-(const+1) add hl,de sbc hl,hl inc hl
#define FULLSPEED in a,2 \ rla \ sbc a,a \ out (20h),a
Stolen borrowed from WikiTI:Code: [Select]#define FULLSPEED in a,2 \ rla \ sbc a,a \ out (20h),aAnd this gives you the added bonus of the CPU operating approximately 25KHz faster at full speed mode!
Quote from: Runer112 on April 25, 2011, 02:50:35 pmStolen borrowed from WikiTI:Code: [Select]#define FULLSPEED in a,2 \ rla \ sbc a,a \ out (20h),aAnd this gives you the added bonus of the CPU operating approximately 25KHz faster at full speed mode!Note: This has the side effect of out (0),0 on the TI-83+. Is that okay?
#define FULLSPEED in a,(2) \ and 80h \ rlca \ out (20h),a
The only side effect of this is that on the TI-83+ Basic this will cause both linkport lines to go high - which shouldn't matter too much if you're not using the linkport at that time, especially since both lines are high normally...
p_GetArc: .db __GetArcEnd-1-$ push de MOV9TOOP1() B_CALL(_ChkFindSym) jr c,__GetArcFail push de ex de,hl ld hl,(progPtr) sbc hl,de pop de ld hl,9 jr c,__GetArcName__GetArcStatic: ld l,12 and %00011111 jr z,__GetArcDone cp l jr z,__GetArcDone ld l,14 jr __GetArcDone__GetArcName: add hl,de B_CALL(_LoadDEIndPaged) ld d,0 inc e inc e__GetArcDone: add hl,de ex de,hl pop hl ld (hl),e inc hl ld (hl),d inc hl ld (hl),b ex de,hl ret__GetArcFail: ld hl,0 pop de ret__GetArcEnd:
p_GetArc: .db __GetArcEnd-1-$ push de MOV9TOOP1() B_CALL(_ChkFindSym) jr c,__GetArcFail B_CALL(_IsFixedName) ;$4363 ld hl,9 jr z,__GetArcName__GetArcStatic: ld l,12 and %00011111 jr z,__GetArcDone cp l jr z,__GetArcDone ld l,14 jr __GetArcDone__GetArcName: add hl,de B_CALL(_LoadDEIndPaged) ld d,0 inc e inc e__GetArcDone: add hl,de ex de,hl pop hl ld (hl),e inc hl ld (hl),d inc hl ld (hl),b ex de,hl ret__GetArcFail: ld hl,0 pop de ret__GetArcEnd:
Oops, necropost, oh well I don't know if this approach was purposely left out, as it's 15 bytes larger than the current routine and sometimes slower. I'm referring to the square root routine. Whereas the current routine (14 bytes) takes 37n+38 T-states (linear time), where n is the result+1 (1-256), the following routine (29 bytes) takes 5n+800 T-states (near constant time), where n is the number of set bits in the result (0-8). The existing routine is faster for values that would yield results of 0-19, but this routine would be faster for values that would yield results of 20-255, which is a much broader range of the 8-bit spectrum. Also, it would be much more reliable to run at a near constant speed in programs which rely on that to run smoothly themselves. The existing routine would take only a few hundred T-states for low inputs, but would take up to OVER NINE THOUSAND T-states to calculate the square roots for the highest inputs. So it's up to you if this is something you want to use.Code: [Select]p_Sqrt: .db __SqrtEnd-1-$ ld a,l ld l,h ld de,$0040 ld h,d ld b,8 or a__SqrtLoop: sbc hl,de jr nc,__SqrtSkip add hl,de__SqrtSkip: ccf rl d rla adc hl,hl rla adc hl,hl djnz __SqrtLoop ld h,0 ld l,d ret__SqrtEnd:
p_Sqrt: .db __SqrtEnd-1-$ ld a,l ld l,h ld de,$0040 ld h,d ld b,8 or a__SqrtLoop: sbc hl,de jr nc,__SqrtSkip add hl,de__SqrtSkip: ccf rl d rla adc hl,hl rla adc hl,hl djnz __SqrtLoop ld h,0 ld l,d ret__SqrtEnd: