GDMike Posted May 31, 2022 Share Posted May 31, 2022 (edited) Getty up computer, Getty up. Edited June 1, 2022 by GDMike Quote Link to comment Share on other sites More sharing options...
Willsy Posted May 31, 2022 Share Posted May 31, 2022 (edited) Well, this was interesting. I don't want to muddy the waters, but this program: 10 A=0 20 A=A+1 30 IF A<3000 THEN 20 Runs as follows (in classic99 on my Win10 I7 office laptop): TI Basic: ~26 seconds Extended Basic: ~32 seconds I chose the above to test the interpreter, and not writing graphics to the screen etc. Edited May 31, 2022 by Willsy typo Quote Link to comment Share on other sites More sharing options...
RXB Posted May 31, 2022 Author Share Posted May 31, 2022 35 minutes ago, Willsy said: Well, this was interesting. I don't want to muddy the waters, but this program: 10 A=0 20 A=A+1 30 IF A<3000 THEN 20 Runs as follows (in classic99 on my Win10 I7 office laptop): TI Basic: ~26 seconds Extended Basic: ~32 seconds I chose the above to test the interpreter, and not writing graphics to the screen etc. Yea less overhead routines to run for TI Basic as it is 1/3rd the size of GPL routines vs XB with no ROMs in TI Basic. Also Floating Point in XB is really the speed problem for XB I can show you the GPL/ROM code to show it is not a small amount. A huge portion of XB is devoted to more accuracy of Floating point then TI Basic which costs speed. (More routines called to do same thing is going to slow down any program.) But TI Basic totally sucks at Graphics compared to XB and RXB has increased speed for routines like CALL HCHAR about 9 times faster. Now I say 9 times in that with demos you see 9 times more put on screen in same time as 1 from TI Basic. Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted May 31, 2022 Share Posted May 31, 2022 1 hour ago, RXB said: Also Floating Point in XB is really the speed problem for XB I can show you the GPL/ROM code to show it is not a small amount. A huge portion of XB is devoted to more accuracy of Floating point then TI Basic which costs speed. (More routines called to do same thing is going to slow down any program.) RND in XB does 5x more computation and therefore takes more time, but you seem to be saying that all floating point numbers are more accurate in XB than in BASIC. You're making a joke, right? 1 Quote Link to comment Share on other sites More sharing options...
RXB Posted May 31, 2022 Author Share Posted May 31, 2022 50 minutes ago, senior_falcon said: RND in XB does 5x more computation and therefore takes more time, but you seem to be saying that all floating point numbers are more accurate in XB than in BASIC. You're making a joke, right? No joke do you see TI Basic routines doing most of the work for Floating Point in XB GPL or ROMs. Now XB uses XML >12 CFI same as TI Basic, but all those that take a number from FP from XB all are XB versions. Really why write new routines for FP for XB if TI Basic routines can work? XB has XML >80 that is CIF in ROM, so why not use TI Basic version? This is Covert Integer to Floating point: AORG >74AA TITL 'CIFS' ************************************************************* * CIF - Convert integer to floating * * Assume that the value in the FAC is an integer * * and converts it into an 8 byte floating point * * value * ************************************************************* CIF LI R4,FAC Will convert into the FAC MOV *R4,R0 Get integer into register MOV R4,R6 Copy pointer to FAC to clear it CLR *R6+ Clear FAC & FAC+1 CLR *R6+ In case had a string in FAC MOV R0,R5 Is integer equal to zero? JEQ CIFRT Yes, zero result and return ABS R0 Get ABS value of ARG LI R3,>40 Get exponent bias CLR *R6+ Clear words in result that CLR *R6 might not get a value CI R0,100 Is integer less than 100? JL CIF02 Yes, just put in 1st fraction * part CI R0,10000 No, is ARG less then 100^2? JL CIF01 Yes, just 1 division necessary * No, 2 divisions are necessary INC R3 Add 1 to exponent for 1st MOV R0,R1 Put # in low order word for the * divide CLR R0 Clear high order word for the * divide DIV @C100,R0 Divide by the radix MOVB @R1LB,@3(R4) ~@ Move the radix digit in CIF01 INC R3 Add 1 to exponent for divide MOV R0,R1 Put in low order for divide CLR R0 Clear high order for divide DIV @C100,R0 Divide by the radix MOVB @R1LB,@2(R4) ~@ Put next radix digit in CIF02 MOVB @R0LB,@1(R4) ~@ Put highest order radix digit in MOVB @R3LB,*R4 Put exponent in INV R5 Is result positive? JLT CIFRT Yes, sign is correct NEG *R4 No, make it negative CIFRT RT You can find all the source code in RXB for ROMs. So I ask again why does XB not use TI Basic version of CIF? (Do you know?) Quote Link to comment Share on other sites More sharing options...
RXB Posted May 31, 2022 Author Share Posted May 31, 2022 Other math routines built into XB ROMs: ******************************************************************************** AORG >748E TITL 'TRINSICS' CBH411 DATA >4101 CBH3F BYTE >3F CBH44 BYTE >44 EVEN * * VROAZ EQU >03C0 VDP roll out area * FPSIGN EQU >03DC * PROAZ EQU PAD0+>10 Processor roll out area * PZ EQU PAD0+>12 * QZ EQU PAD0+>16 * CZ EQU PAD0+>1A * SGNZ EQU PAD0+>75 * EXPZ EQU PAD0+>76 * OEZ EQU PAD0+>14 EXC127 EQU >00 FHALF EQU >08 SQRTEN EQU >10 LOG10E EQU >18 LN10 EQU >20 PI2 EQU >28 RPI2 EQU >30 PI4 EQU >38 TANPI8 EQU >40 TAN3P8 EQU >48 SQRP EQU >50 SQRQ EQU >6A FPOS1 EQU >6A EXPP EQU >7C EXPQ EQU >96 LOGP EQU >B8 LOGQ EQU >E2 SINP EQU >010C ATNP EQU >014E ************************************************************* * INVOLUTION * * FAC - exponent * * Top of stack - Base * * If integer Base and integer exponent do multiplies to * * keep result exact, otherwise, use logarithm to calculate * * value. * ************************************************************* PWRZZ MOV R11,R10 BL @SAVRTN Save return BL @POPSTK Get Base into ARG MOV @FAC,R0 If exponent=0 JEQ PWRG01 Then result = 1 MOV @ARG,R0 If Base=0 JEQ PWRG02 Then return 0 or warning A @C8,@VSPTR Use Base on stack BL @PUSH Check to see if E is floating * integer BL @GRINT Convert 1 copy of exp to int MOVB @C8,@SIGN Assume sign is positive BL @XTFACZ FAC=ARG STACK=INT(ARG) BL @SCOMPB Integer exponent? JNE PWRZZ3 No, try floating code * COMPUTE INTEGER POWER B^E BL @PUSH Put Exp above Base on stack MOVB @C8,@FAC10 Assume no error BL @CFI Try to convert E to integer CCBH7 ABS @FAC Absolute value of exponent MOV @FAC,R12 Save integer exponent BL @POP Return E to FAC; B on stack MOVB @FAC10,R0 If E>32767 JNE PWRZZ1 Return to floating point code BL @XTFACZ Get Base in accumulator BL @PUSH Put E on stack for later sign * check DEC R12 Reduce exponent by one since * accumulator starts with Base JEQ PWRJ40 If 0 then done already PWRJ30 SRL R12,1 Check l.s. bit JNC PWRJ10 If 0, skip the work BL @SMULT Multiply in this power A @C8,@VSPTR Restore stack PWRJ10 MOV R12,R12 Finished? JEQ PWRJ40 Yes BL @XTFACZ No, exchange: B in FAC, * accumulator on stack BL @PUSH Copy B onto stack BL @SMULT Square it for new B BL @XTFACZ Restore order: B on stack * accumulator in FAC JMP PWRJ30 Loop for next bit PWRJ40 S @C16,@VSPTR Done, clean up MOV @VSPTR,R3 Get stack pointer AI R3,8 Test exponent sign now BL @GETV1 Get it JLT PWRJ41 If negative, compute negative PWRRTN B @ROLIN2 Use commone code to return PWRJ41 MOVB @FAC10,R0 If overflow has occured JNE PWRJ45 Go make it zero BL @MOVROM Get a floating point one DATA FPOS1 into ARG * BL @FDIV Compute the inverse JMP PWRRTN And return PWRJ45 CLR @FAC If overflow, the result=0 MOVB @FAC,@FAC10 Indicate no error JMP PWRRTN And return PWRG02 MOVB @FAC,R0 Is Exp negative? JLT PWRG05 Yes, divide by 0 =>put in overflow JMP PWRJ45 No, result is zero and return PWRG01 LI R0,FAC Need to put floating 1 in FAC BL @MOVRM1 Get the floating 1 DATA FPOS1 into FAC * JMP PWRRTN And return PWRZZ3 BL @GETV Check for negative DATA VSPTR On the stack * JGT PWRZZ2 If ok MOVB @ERRNIP,@FAC10 Else error code S @C8,@VSPTR Throw away entry on stack JMP PWRRTN And return * INTEGER EXPONENT OUT OF INTEGER RANGE PWRZZ1 BL @GETV Positive or negative Base? DATA VSPTR * JGT PWRZZ2 Positive Base * NEGATIVE BASE - So see if exponent is even or odd to set * the sign of the result PWRZZ4 CLR R1 For double MOVB @FAC,R1 Get exponent ABS R1 Work with positive CI R1,>4600 Too big to have one's byte? JGT PWRZZ2 Yes, assume number is even SWPB R1 Get in low order byte AI R1,>830B No, get one's radix digit * location in FAC MOVB *R1,R1 Get the digit SLA R1,7 If last bit set, set top bit PWRZZ2 LI R4,FPSIGN Save sign of result BL @PUTV1 in a permanent place BL @XTFACZ Base in FAC; Exponent on stack ABS @FAC Must work with positive BL @LOGZZ Compute LOG(B) in FAC BL @SMULT Compute E*LOG(B) in FAC BL @EXPZZ Let exp give error on warning LI R3,FPSIGN Check sign of result BL @GETV1 JLT PWRZZ5 If E is negative JMP PWRRTN If E is positive ERRNIP EQU $ PWRZZ5 NEG @FAC Make it negative JMP PWRRTN PWRG05 BL @OVEXP Return overflow JMP PWRRTN And return ************************************************************* * EXPONENTIAL FUNCTION * * FAC = EXP(FAC) * * CALL BL @EXPZZ * * WARNING: WRNOV Overflow * * STACK LEVELS USED: * * X : = FAC * LOG10(E) * * So EXP(FAC) = 10^X * * Make sure X is in range LOG100(X) = LOG10(X)/2 * * N : = INT(X) * * R : = X-N, 0 <= R < 1 * * IF R < .5 THEN R : = R * * ELSE S : = R-5 * * A rational function approximation is used for 10^S * * (HART EXPD 1444) * * EXP : = IF R .LT. .5 THEN 10^N * 10^S * * ELSE 10^N * 10^.5 * 10^S * ************************************************************* EXPZZ MOV R11,R10 BL @ROLOUT Get workspace and save return BL @MOVROM Get LOG10(E) DATA LOG10E into ARG * BL @FMULT X : = FAC * LOG10(E) BL @PUSH Save X BL @GRINT Compute N : = INT(X) BL @MOVROM Get floating 127 DATA EXC127 into ARG * BL @FCOMPB Is N > 127? JEQ EXP03 If = 127 JLT EXP01 If > 127 NEG @ARG Check negative range BL @FCOMPB Is N < -127? JLT EXP03 N > -127 JEQ EXP03 N = -127 * N is out of range EXP01 S @C8,@VSPTR Pop X off stack MOV @FAC,@EXP Recall exponent sign MOVB @C8,@SIGN Result is positive BL @OVEXP Take over or underflow action JMP BROLIN Restore CPU RAM and return EXP03 BL @PUSH Save value on stack BL @CFI Convert to integer exponent MOV @FAC,R12 Get it in REG to mpy by 2 SLA R12,1 Compute 2*N BL @POP Restore value BL @SSUB Compute R = X - N BL @MOVROM Get a floating .5 DATA FHALF into ARG * BL @FCOMPB Is .5 > R? JGT EXP04 Yes, S=R NEG @ARG -.5 BL @FADD Compute S : = R - .5 INC R12 Remember R >= .5, (2*N+1) * save a copy of S EXP04 BL @PUSH Save a copy of S BL @POLYW Compute S * P(S^2) DATA EXPP Poly to evaluate * BL @XTFACZ FAC = S, stack = S * P(S^2) BL @POLYX Compute Q(S^2) DATA EXPQ Poly to evaluate * BL @POPSTK S * P(S^2) -> ARG A @C8,@VSPTR BL @PUSH Save comp of Q(S^2) BL @FADD Q(S^2) + S * P(S^2) LI R3,FAC Save FAC in a temp LI R4,CZ MOV *R3+,*R4+ 1st two bytes MOV *R3+,*R4+ 2nd two bytes MOV *R3+,*R4+ 3rd two bytes MOV *R3,*R4 Last two bytes BL @POP FAC = Q(S^S), stack = S*P(S^2) BL @XTFACZ Revese same BL @SSUB Compte Q(S^2)-S*P*(S^2) LI R3,CZ Get fac back from temp LI R4,ARG MOV *R3+,*R4+ 1st two bytes MOV *R3+,*R4+ 2nd two bytes MOV *R3+,*R4+ 3rd two bytes MOV *R3,*R4 Last rwo bytes BL @FDIV Compute Q-P/Q-P EXPSQT SRA R12,1 Check flag that was set above JNC EXPSQ5 If not set BL @MOVROM Get SQR(10) DATA SQRTEN into ARG * BL @FMULT Multipy by SQU(10) if N odd EXPSQ5 BL @MOVROM Need a floating 1 DATA FPOS1 into ARG * SRA R12,1 Check odd power of ten JNC EXPSQ8 If not odd power MOVB @CBHA,@ARG1 Odd power of ten (>0A) EXPSQ8 AB @R12LB,@ARG Add in power of 100 to Exp BL @FMULT BROLIN B @ROLIN ************************************************************* * LOGARITHM FUNCTION * * FAC : = LOG(FAC) * * ERRORS : ERRLOG LOG of negative number or zero * * attempted. * * STACK LEVELS USED: * * IF FAC <= 0 THEN ERRLOG * * LOG(FAC)=LN(FAC)=LOG10(FAC)*LN(10) * * FAC : = A * 10^N, .1 <= A < 1 * * S : = A * SQR(10), 1/SQR(10) <= S < SQR(10) * * LOG10(A) : = LOG10(S/SQR(10)) * * : = LOG10(S) - LOG10(SQR(10)) * * : = LOG10(S) - .5 * * LOG : = (N - .5 + LOG10(S)) * LN(10) * * : = (N - .5 * LN(10) + LN(S) * * A rational function approximation is used for LN(S) * * (HART LOGE 2687) * ************************************************************* LOGZZ MOV R11,R10 BL @ROLOUT Get workspace and save return MOV @FAC,R0 Check for negative or zero JGT LOGZZ3 If positive MOVB @ERRLOG,@FAC10 Load error code JMP BROLIN Restore CPU and return ERRLOG EQU $ LOGZZ3 BL @TENCNS Get base 10 exponent JNE LOGZZ5 BL @MOVROM Get a floating 1 DATA FPOS1 into ARG * Make it a floating 10 MOVB @CBHA,@ARG1 by putting in >0A BL @FMULT Multipy FAC by 10 BL @TENCNS Get new exponent of 10 JMP LOGZ5A Compensate for Mult LOGZZ5 INC @EXP Compenstat for where radix * point is LOGZ5A MOVB @CBH3F,@FAC Put A in proper range * by putting in >3F MOV @EXP,R12 BL @MOVROM Get SQR(10) DATA SQRTEN into ARG * BL @FMULT S : = A * SQR(10) BL @FORMA Z : = (S-1) / (S+1) BL @PUSH Push Z BL @POLYW Compute Z * P(Z^2) DATA LOGP * BL @XTFACZ BL @POLYX Compute Q(Z^2) DATA LOGQ Poly to evaluate * BL @SDIV Compute Z*P(Z^2)/Q(Z^2) BL @PUSH Push it LI R0,ARG Build entry in ARG MOV R12,*R0+ Put in exponent CLR *R0+ and CLR *R0+ clear the CLR *R0 rest * STATUS WAS SET BY THE MOVE ABOVE JEQ LOGZZ7 If zero exponent ABS @ARG Work with ABS value MOV @ARG,R0 in register CI R0,99 Too large? JGT LOGZZ9 Yes MOVB @FLTONE,@ARG Exponent = >40 LOGZZ6 MOVB R12,R12 Exponent positive? JEQ LOGZZ7 Yes NEG @ARG No, make it negative LOGZZ7 BL @MOVRM5 Need a floating .5 DATA FHALF in FAC * BL @FSUB Compute N - .5 BL @MOVROM Need LN(10) DATA LN10 into ARG * BL @FMULT Compute (N - .5) * LN(10) BL @SADD Add to LN(S) JMP BROLIN Restore CPU and return LOGZZ9 S @C100,@ARG Subtract first 100 MOVB @ARG1,@ARG2 MOV @CBH411,@ARG Load exponent and * leading digit of >4101 JMP LOGZZ6 ************************************************************* * EVALUATE X * P(X^^2) * * ON CALL : PZ Pointer to polynomial coefficients * * : FAC Contains X * * BL @POLYW * * : FAC Returns X * P(X^^2) * ************************************************************* POLYW MOV *R11+,@PZ Get the poly to evaluate MOV R11,R10 BL @SAVRTN Save return address BL @PUSH Push the argument BL @POLYX1 Compute P(X^^2) BL @SMULT Compute X*P(X^^2) JMP PWRTN2 And return POLY MOV *R11+,@PZ MOV R11,R10 BL @SAVRTN Save return address JMP POLY01 And merge in below POLYX MOV *R11+,@PZ POLYX1 MOV R11,R10 BL @SAVRTN Save return address BL @PUSH Need to copy FAC * into ARG to square it BL @SMULT Square X (SMULT pops into ARG) POLY01 BL @PUSH Push the argument MOV @PZ,R3 Get the poly to evaluate LI R0,FAC into FAC BL @MOVRM2 JMP POLY03 POLY02 BL @POPSTK Get X back A @C8,@VSPTR Keep it on stack BL @FMULT Multiply previous result by X MOV @PZ,R3 LI R0,ARG Get polynomial to evaluate BL @MOVRM2 into ARG BL @FADD Add in this coefficient POLY03 A @C8,@PZ Point to next coefficient * and get first two bytes * into ARG CB *R13,@CBH80 Read first byte * and test it to see if done JNE POLY02 No, continue computing poly S @C8,@VSPTR Pop X off stack JMP PWRTN2 Return with poly in FAC * FORMA MOV R11,R10 BL @SAVRTN Save return address BL @PUSH Save X on stack BL @FORMA2 BL @FORMA2 BL @XTFACZ Swap (X-1) and X BL @MOVROM Get a floating 1 DATA FPOS1 into ARG * BL @FADD X+1 BL @SDIV (X-1)/(X+1) JMP PWRTN2 And return FORMA2 MOV R11,R10 BL @SAVRTN Save return address BL @MOVROM Get a floating .5 DATA FHALF int ARG * NEG @ARG BL @FADD X - .5 PWRTN2 B @ROLIN2 ************************************************************* * SQUARE ROOT FUNCTION * * Reference for scientific function approximations. * * JOHN F. HART ET AL, Comper approximations, * * JOHN WILEY & SONS, 1968 * * FAC : = SQR(FAC) * * ERRORS : ERRSQR Square root of negative number * * attempted * * STACK LEVELS USED: * * IF FAC = 0 THEN SQR : = 0 * * IF FAC < 0 THEN ERRSQR * * FAC : = A * 100^N, .01 <= A < 1 * * SQR : = 10^N * SQR(A) * * Newton's method with a fixed number of iterations is used * * to approximate SQR(A): * * A rational function approximation is used for Y(0) * * (HART SQRT 0231) * * Y(N+1) = (Y(n))/2 * ************************************************************* SQRZZ MOV R11,R10 BL @ROLOUT Get workspace and save return MOV @FAC,R12 Check exponent JEQ SQR03 FAC is zero, return zero JLT SQR02 FAC is < 0, error MOVB @CBH3F,@FAC Create A in range .01 <= A <1 * by loading >3F AI R12,>C100 Remove bias (-63) SRA R12,8 Sign extend SLA R12,1 Save 2 * N BL @PUSH Save A BL @PUSH Save A again BL @POLY Compute P(A) DATA SQRP Poly to evaluate * BL @XTFACZ Stack : = P(A), FAC : = A BL @POLY Compute Q(A) DATA SQRQ Poly to evaluate * BL @SDIV Compute P(A)/Q(A) MOV @CC3,@PZ Save in permanent SQR01 BL @POPSTK Pop into ARG A @C8,@VSPTR But keep it on stack BL @PUSH Push Y(N) BL @FDIV Compute A/Y(N) BL @SADD Compute A/Y(N) + Y(N) BL @MOVROM Nead a floating .5 DATA FHALF into ARG * BL @FMULT Compute .5 * (A/Y(N) + Y(N)) DEC @PZ Decrement loop counter JNE SQR01 Loop three times S @C8,@VSPTR Pop off stack B @EXPSQT To finish up SQR02 MOVB @ERRSQR,@FAC10 Load error code for return ERRSQR EQU $ SQR03 B @ROLIN Restore CPU RAM and return ************************************************************* * COSINE FUNCTION * * FAC : = COS(FAC) * * COS(FAC) : = SIN(FAC + PI/2) * ************************************************************* COSZZ MOV R11,R12 BL @MOVROM Need to get PI/2 DATA PI2 into ARG * BL @FADD Compute FAC + PI/2 MOV R12,R11 And fall into SIN code ******************************************************************************** TITL 'TRINSICS2' ************************************************************* * SINE FUNCTION * * FAC : = SIN(FAC) * * STACK LEVELS USED: * * IF FAC < 0 THEN SIN(FAC) : = -SIN(-FAC) * * X : = 2/PI*FAC * * K : = INT(X) * * R : = X-K, 0 <= R < 1 * * Q : = K MOD 4 * * SO K : = 4*N+Q * * FAC : = PI/2 * K + PI/2 * R * * : = 2*PI*N + PI/2*Q + PI/2*R * * SIN(FAC) : = SIN(P/2*Q+PI/2*R) * * QUADRANT Q Identity * * I 0 SIN(FAC) : = SIN(PI/2*R) * * II 1 SIN(FAC) : = SIN(PI/2+PI/2*R * * : = SIN(PI-*(PI/2+PI/2R)) * * : = SIN(PI/2*(1-R)) * * III 2 SIN(FAC) : = SIN(PI+PI/2*R) * * : = SIN(PI-(PI+PI/2*R)) * * : = SIN(PI/2 * (R-1)) * * IV 3 SIN(FAC) : = SIN(3*PI/2 + PI/2*R * * : = SIN(3*PI/2 + PI/2*R-2*PI) * * : = SIN(PI/2 * (R-1)) * * QUADRANT Q ARGUMENT TO APPROXIMATION POLYNOMIAL * * I 0 R = R 0 <= R < 1 * * II 1 1-R = 1-R 0 < 1-R <= 1 * * III 2 -R = -R -1 < -R <= 0 * * IV 3 R-1 = -(1-R) -1 <= R-1 < 0 * * * * A polynomial approximation is used for SIN(P/2*R) * * -1 <= R < 1 * * (HART SIN 3344) * ************************************************************* SINZZ MOV R11,R10 BL @ROLOUT Get workspace and save return BL @MOVROM Get 2/PI DATA RPI2 into ARG * BL @FMULT X : = 2/PI*FAC MOVB @FAC,R12 Save sign ABS @FAC Consider positive numbers CB @FAC,@CBH44 Check exponent range * by checking with >44 JGT TRIERR ERR in range of exponent BL @PUSH Save X BL @GRINT K : = INT(K) CLR R1 Assume Q is zero CLR R0 MOVB @FAC,R0 Is FAC zero? JEQ SIN02 Yes, Q is zero AI R0,>BA00 Bias exponent (->46 byte) * is K too big for (K MOD 4) * to have a significance? JGT SIN01 Yes, defualt Q to zero AI R0,>51*256 (FAC+7-PAD0)*256 CBH80 EQU $+1 CONSTANT >80 SRL R0,8 AI R0,PAD0 MOVB *R0,@R1LB No, get 10's and 1's place of K CC3 EQU $+2 SIN01 ANDI R1,3 Q : = (K MOD 4) SIN02 MOV R1,@QZ BL @SSUB R : = X-K MOV @QZ,R1 SRL R1,1 Is Q even? MOV R1,@QZ JNC SIN03 Yes BL @MOVROM Get a floating 1 DATA FPOS1 into ARG * BL @FSUB Compute 1-R SIN03 MOV @QZ,R1 Quadrant III or IV? JEQ SIN04 No INV R12 Yes, change sign or result SIN04 BL @POLYW Evaluate it DATA SINP get poly P's coefficients * JMP ATNSGN and set sign TRIERR MOVB @CCBH7,@FAC10 TRIG error (>7 in FAC10) JMP ATNSG3 ************************************************************* * TANGENT FUCTION * * FAC : = TAN(FAC) * * TAN(FAC) : = SIN(FAC)/COS(FAC) * ************************************************************* TANZZ MOV R11,R10 BL @SAVRTN Save return address BL @PUSH Save FAC on stack BL @SINZZ Compute SIN BL @XTFACZ BL @COSZZ Compute COS BL @POPSTK Pop stack into ARG CB @FAC10,@CCBH7 Check for error JEQ PWRTN3 If error MOV @FAC,R0 Is COS = zero? JEQ TAN01 Yes BL @FDIV No, TAN : = SIN(ARG)/COS(ARG) PWRTN3 B @ROLIN2 TAN01 MOVB @ARG,@SIGN BL @OVEXP Issue overflow message JMP PWRTN3 Clean up and exit ************************************************************* * INVERSE TANGENT FUCTION * * FAC : = ATN(FAC) * * STACK LEVELS USED: * * IF FAC < 0 THEN ARCTAN(FAC) = -ARCTAN(-FAC) * * IF 0 <= FAC <= TAN(PI/8) * * THEN T = FAC, ARCTAN(FAC) : = ARCTAN(T) * * IF TAN(PI/8) < FAC < TAN(3*PI/8) * * THEN T = (FAC-1) / (FAC+1), * * ARCTAN(FAC) : = PI/4 + ARCTAN(T) * * IF TAN(3*PI/8) <= FAC * * THEN T = -1/FAC, * * ARCTAN(FAC) : = PI/2 + ARCTAN(T) * * * * A polynomial approximation is used for ARCTAN(T), * * -TAN(PI/8) <= T <= TAN(PI/8) * * (HART ARCTN 4967) * ************************************************************* ATNZZ MOV R11,R10 BL @ROLOUT Get workspace and save return MOVB @FAC,R12 Save sign ABS @FAC Use ABS(FAC) CLR @QZ Assume ARG is in range BL @MOVROM Need TAN(PI/8) DATA TANPI8 into ARG * BL @FCOMPB Is TAN(3*PI/8) >= ARG? JEQ ATN02 If = JGT ATN02 If > BL @MOVROM Need TAN(3*PI/8) DATA TAN3P8 into ARG * BL @FCOMPB Is TAN(3*PI/8) > ARG? JGT ATN01 Yes, use case 2 BL @MOVROM Get a floating 1 DATA FPOS1 into ARG * NEG @ARG Use case 3 to compute BL @FDIV T = -1/ARG LI R3,PI2 Get PI/2 JMP ATN02A Add it in at the end ATN01 BL @FORMA Case 2 : T : = (ARG-1)/(ARG+1) LI R3,PI4 Get PI/4 ATN02A MOV R3,@QZ Set up to evaluate ATN02 BL @POLYW ATN(T) : = T * P(T^^2) DATA ATNP Poly to evlauate * MOV @QZ,R3 Case 1? JEQ ATNSGN Yes, don't add anything in LI R0,ARG BL @MOVRM2 BL @FADD Add in the constant ATNSGN INV R12 Check sign of result JLT ATNSG3 If sign is already on NEG @FAC else negate it ATNSG3 B @ROLIN And return ************************************************************* * GREATEST INTEGER FUNCTION * ************************************************************* GRINT MOV R11,R7 Save return address MOVB @FAC,@SIGN Save result sign ABS @FAC Absolute value MOVB @FAC,R5 Get exponent SRL R5,8 Make it into word MOV R5,@EXP For rounding CI R5,>40 Exponent < 0? JLT BITINT Yes, handle it CI R5,>45 Exponent > 10^5 ? JGT INT02 Yes, handle it AI R5,->46 Locate position MOVB @R5LB,@FAC10 Save for rounding CLR R2 LI R3,FAC8 A R5,R3 Point to 1st fractional digit INT01 SOCB *R3,R2 Remember if non-zero MOVB @R2LB,*R3+ Clear the digit INC R5 JNE INT01 MOVB @SIGN,R0 Get the sign JGT INT03 If non-negative(i.e. Positive) MOVB R2,R2 JEQ INT02 AB @CCBH7,@FAC10 Where to round up BL @ROUNU Do the rounding JMP INT03 INT02 MOVB @SIGN,R0 Check the sign JGT INT03 If positive don't negate NEG @FAC Make result negative INT03 CLR @FAC10 Indicate no error B *R7 <<<< Return from here BITINT LI R0,FAC Zero or -1 LI R1,>BFFF Default to -1 MOVB @SIGN,R2 Negative or Positive? JLT INT04 If really negative put in -1 CLR R1 If Positive put in a 0 INT04 MOV R1,*R0+ Copy in 0 or -1 CLR *R0+ and CLR *R0+ clear CLR *R0 the JMP INT03 rest * MOVE 8 BYTES FROM ROM(R3) TO CPU AT R0 MOVRM5 LI R0,FAC Move to FAC JMP MOVRM1 Merge into common code MOVROM LI R0,ARG Move to ARG MOVRM1 MOV *R11+,R3 Constant to load MOVRM2 LI R2,8 Constants are 8 bytes long A @INTRIN,R3 Add in GROM offset <<<<<<<<<< MOVB R3,@GRMWAX(R13) Write MSB of address SWPB R3 Bare the LSB MOVB R3,@GRMWAX(R13) Write the LSB MOVRM4 MOVB *R13,*R0+ Read a byte DEC R2 Moved them all yet? JNE MOVRM4 No, copy the next one RT Yes, return * ROLL OUT CPU AREA FOR WORKSPACE ROLOUT LI R1,PROAZ Processor roll out area CVROAZ EQU $+2 LI R3,VROAZ VDP roll out area MOVB @R3LB,*R15 ORI R3,WRVDP MOVB R3,*R15 LI R0,26 ROLOT1 MOVB *R1+,@XVDPWD DEC R0 JNE ROLOT1 CLR @FAC8 And save return address * SAVE RETURN ADDRESS SAVRTN INCT @STKADD MOVB @STKADD,R9 SRL R9,8 AI R9,PAD0 MOV R10,*R9 RT * ROLL IN CPU AREA AFTER WORK IS DONE ROLIN LI R1,PROAZ Processor roll out area MOVB @CVROAZ+1,*R15 LSB of address MOVB @CVROAZ,*R15 MSB of address LI R0,26 Number of bytes rolled out ROLIN1 MOVB @XVDPRD,*R1+ DEC R0 JNE ROLIN1 CLR @FAC8 ROLIN2 MOVB @STKADD,R9 SRL R9,8 AI R9,PAD0 MOV *R9,R11 DECT @STKADD RT * PUSH FAC ONTO STAK C8 EQU $+2 PUSH LI R0,8 Number to push A R0,@VSPTR Bump stack pointer MOV @VSPTR,R1 Get stack poiter MOVB @R1LB,*R15 ORI R1,WRVDP MOVB R1,*R15 LI R1,FAC PUSH1 MOVB *R1+,@XVDPWD DEC R0 JGT PUSH1 RT * POP VALUE OFF STACK INTO FAC POP LI R2,FAC MOVB @VSPTR1,*R15 LSB of address LI R0,8 MOVB @VSPTR,*R15 MSB of address S R0,@VSPTR POP1 MOVB @XVDPRD,*R2+ DEC R0 JGT POP1 RT * EXCHANGE TOP OF STACK AND FAC XTFACZ MOV R11,R10 Save return address BL @PUSH Put FAC on top LI R3,8 Working with 8 byte entries MOV R3,R5 Need another copy for below S R3,@VSPTR Point back to old top BL @POP Put it in FAC A R3,@VSPTR Restore pointer to old top MOV @VSPTR,R4 Place to move to A R4,R3 Place to move from XTFAC1 BL @GETV1 Get a byte BL @PUTV1 Put a byte INC R3 INC R4 DEC R5 Done? JNE XTFAC1 No B *R10 Yes, retrun * GET BASE 10 EXPONENT OF THE NUMBER IN FAC * EXP: Gets the base 10 exponent * OEZ: 0 if exp is even and 1 if exp is odd TENCNS CLR R0 Get base 100 exponent MOVB @FAC,R0 Put in MSB AI R0,>C000 Remove bias (SUBT >64 from MSB) SLA R0,1 Multiply it by 2 SRA R0,8 Sign fill high order byte CLR R3 and put in LSB CB @FAC1,@CBHA 1st digit of FAC one decimal * digit? JLT CNST10 Yes, base 10 exponent is even INC R0 No, take this into account in * exponent INC R3 This makes base 10 exp odd CNST10 MOV R0,@EXP MOV R3,R3 Set condition for return RT ************************************************************* * MISCELLANEOUS CONSTANTS: * CBH411 * EXC127 BYTE >41,1,27,0,0,0,0,0 127 * FHALF BYTE >3F,50 .5 * ZER3 BYTE 0,0,0,0,0,0 * SQRTEN BYTE >40,3,16,22,77,66,01,69 SQR(10) * LOG10E BYTE >3F,43,42,94,48,19,03,25 LOG10(E) * LN10 BYTE >40,2,30,25,85,09,29,94 LN(10) * CBH7 EQU $+3 * PI2 BYTE >40,1,57,7,96,32,67,95 PI/2 * RPI2 BYTE >3F,63,66,19,77,23,67,58 2/PI * PI4 BYTE >3F,78,53,98,16,33,97,45 PI/4 * CBHA EQU $+7 * CBH3F * TANPI8 BYTE >3F,41,42,13,56,23,73,10 TAN(PI/8)=SQR(2)-1 * TAN3P8 BYTE >40,2,41,42,13,56,23,73 TAN(3*PI/8)=SQR(2)+1 ** SQR POLYNOMIALS (HART SQRT 0231) * SQRP BYTE >3F,58,81,22,90,00,00,00 P02=.58812 29E+00 * BYTE >3F,52,67,87,50,00,00,00 P01=.52678 75E+00 * BYTE >3E,58,81,20,00,00,00,00 P00=.58812 E-02 * DATA SGNBIT * FLTONE * FPOS1 * SQRQ BYTE >40,01,00,00,00,00,00,00 Q01=.1 E+01 * BYTE >3F,09,99,99,80,00,00,00 Q00=.99999 8 E-01 * DATA SGNBIT ** EXPPONENT POLYNOMIALS (HART EXPD 1444) ** P02 = .18312 36015 92753 84761 54 E+02 * EXPP BYTE >40,18,31,23,60,15,92,75 ** P01 = .83140 67212 93711 03487 3446 E+03 * BYTE >41,08,31,40,67,21,29,37 * P00 = .51780 91991 51615 35743 91297 E+04 * BYTE >41,51,78,09,19,91,51,62 * DATA SGNBIT ** Q03 = .1 E+01 * EXPQ BYTE >40,1,0,0,0,0,0,0 ** Q02 = .15937 41523 60306 52437 552 E+03 * BYTE >41,01,59,37,41,52,36,03 ** Q01 = .27093 16940 85158 99126 11636 E+04 * BYTE >41,27,09,31,69,40,85,16 ** Q00 = .44976 33557 40578 41762 54723 E+04 * BYTE >41,44,97,63,35,57,40,58 * DATA SGNBIT ** LOG POLYNOMIALS (HART LOGE 2687) ** P04 = .35670 51030 88437 69 E+00 * LOGP BYTE >3F,35,67,05,10,30,88,44 ** P03 = -.11983 03331 36876 1464 E+02 * BYTE >BF,>F5,98,30,33,31,36,88 ** P02 = .63775 48228 86166 05782 E+02 * BYTE >40,63,77,54,82,28,86,17 ** P01 = -.10883 71223 55838 3228 E+03 * BYTE >BE,>FF,08,83,71,22,35,58 ** P00 = .57947 38138 44442 78265 7 E+02 * BYTE >40,57,94,73,81,38,44,44 * DATA SGNBIT * LOGQ ** Q04 = .1 E+01 * BYTE >40,01,0,0,0,0,0,0 ** Q03 = -.13132 59772 88464 0339 E+02 * BYTE >BF,>F3,13,25,97,72,88,46 ** Q02 = .47451 82236 02606 00365 E+02 * BYTE >40,47,45,18,22,36,02,61 ** Q01 = -.64076 45807 52556 00596 E+02 * BYTE >BF,>C0,07,64,58,07,52,56 ** Q00 = .28973 69069 22217 71601 9 E+02 * BYTE >40,28,97,36,90,69,22,22 * DATA SGNBIT ** SIN POLYNOMIAL (HART SIN 3344) * SINP ** REFLECTS CHANGE IN 99/4 CONSTANT TO CORRECT VALUES ** OF SIN AND COS >1 ** P07 = -.64462 13674 9 E-09 ** BYTE >C4,>FA,44,62,13,67,49,00 ** P07 = -.64473 16000 0 E-09 * BYTE >C4,>FA,44,73,16,00,00,00 ** P06 = .56882 03332 688 E-07 * CBH44 EQU $+2 * BYTE >3C,05,68,82,03,33,26,88 ** P05 = -.35988 09117 03133 E-05 * BYTE >C2,>FD,59,88,09,11,70,31 ** P04 = .16044 11684 69828 31 E-03 * BYTE >3E,01,60,44,11,68,46,98 ** P03 = -.46817 54131 06023 168 E-02 * BYTE >C1,>D2,81,75,41,31,06,02 ** P02 = .79692 62624 56180 0806 E-01 * BYTE >3F,07,96,92,62,62,45,62 ** P01 = -.64596 40975 06219 07082 E+00 * BYTE >C0,>C0,59,64,09,75,06,22 ** P00 = .15707 96323 79489 63959 E+01 * BYTE >40,01,57,07,96,32,67,95 * DATA SGNBIT ** ATN POLYNOMIAL (HART ARCTN 4967) * ATNP ** P09 = -.25357 18798 82 E-01 * BYTE >C0,>FE,53,57,18,79,88,20 ** P08 = .50279 13843 885 E-01 * BYTE >3F,05,02,79,13,84,38,85 ** P07 = -.65069 99940 1396 E-01 * BYTE >C0,>FA,50,69,99,94,01,40 ** P06 = .76737 12439 1641 E-01 * BYTE >3F,07,67,37,12,43,91,64 ** P05 = -.90895 47919 67196 E-01 * BYTE >C0,>F7,08,95,47,91,96,72 ** P04 = .11111 04992 50526 62 E+00 * BYTE >3F,11,11,10,49,92,50,53 ** P03 = -.14285 71269 75961 157 E+00 * BYTE >C0,>F2,28,57,12,69,75,96 ** P02 = .19999 99997 89961 5228 E+00 * BYTE >3F,19,99,99,99,97,89,96 ** P01 = -.33333 33333 32253 4275 E+00 * BYTE >C0,>DF,33,33,33,33,32,25 ** P00 = .99999 99999 99999 08253 E+00 * BYTE >40,01,0,0,0,0,0,0 * DATA SGNBIT ******************************************************************************** Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted May 31, 2022 Share Posted May 31, 2022 You have changed the subject. You stated that floating point numbers are more accurate in XB than in BASIC. I see no evidence to support that. Heiner Martin discusses XB on page 209 of Intern. 1 Quote Link to comment Share on other sites More sharing options...
Reciprocating Bill Posted May 31, 2022 Share Posted May 31, 2022 It appears (from the above) that Extended BASIC provides assembly versions of the transcendental functions (and SQR). TI BASIC calculates those values in GPL, and I'm not aware of any assembler versions in the console ROM (at least not that are documented in the E/A manual.) Which is perhaps why XB calculates transcendentals more quickly than TI BASIC. 3 Quote Link to comment Share on other sites More sharing options...
RXB Posted May 31, 2022 Author Share Posted May 31, 2022 25 minutes ago, senior_falcon said: You have changed the subject. You stated that floating point numbers are more accurate in XB than in BASIC. I see no evidence to support that. Heiner Martin discusses XB on page 209 of Intern. You are correct XB is not so much more accurate but does way more than TI Basic can do with Floating Point. TI Intern ignores a ton of other flags and pointers in XB, and TI Intern does not show a single byte of XB code GPL/Assembly. TI Intern is great at TI OS and Basic, it does not show XB at all other than some references talking about XB. Ok well answer the original question: So I ask again why does XB not use TI Basic version of CIF? (Do you know?) Quote Link to comment Share on other sites More sharing options...
Reciprocating Bill Posted May 31, 2022 Share Posted May 31, 2022 (edited) An assembly version of CIF appears to be absent from the console ROM, which is why the E/A loader loads it into RAM to make it available to Option 3 programs, and why Extended BASIC has to provide its own. Edited May 31, 2022 by Reciprocating Bill Added "An assembly version" 2 Quote Link to comment Share on other sites More sharing options...
RXB Posted May 31, 2022 Author Share Posted May 31, 2022 1 minute ago, Reciprocating Bill said: CIF appears to be absent from the console ROM, which is why the E/A loader loads it into RAM to make it available to Option 3 programs, and why Extended BASIC has to provide its own. So how does TI Basic do it? (Trick Question) Quote Link to comment Share on other sites More sharing options...
Reciprocating Bill Posted May 31, 2022 Share Posted May 31, 2022 (edited) It doesn't have to. The only reason one needs that conversion is to make integer values utilized in assembly available to the interpreter as BCD. Since TI BASIC can't utilize assembly code, it has no need for that conversion. Edited May 31, 2022 by Reciprocating Bill 2 Quote Link to comment Share on other sites More sharing options...
apersson850 Posted June 1, 2022 Share Posted June 1, 2022 I've noticed the same thing when I built my 16-bit wide RAM in the console. The difference in execution speed for assembly code with both the workspace and the code in expansion RAM is roughly 110%. That is, fast RAM cuts the time to a little less than half. For Extended BASIC the difference is so small that you have to use a stopwatch to see it. In reality, standard expansion or fast expansion doesn't make any meaningful difference. For Pascal, the difference is roughly 10%. The p-system runs a lot of code that's transferred to the 8K RAM section. The main advantage is that you don't have to consider how to best use the little RAM PAD to speed up your assembly programs. Just run them where they are, and they'll go as fast as possible. But when an interpreter runs sequential code from memory, reading a byte from CPU RAM, GROM or from VDP RAM doesn't make much difference. When reloading the address it does, but you don't do that all the time. 1 Quote Link to comment Share on other sites More sharing options...
RXB Posted June 1, 2022 Author Share Posted June 1, 2022 9 hours ago, apersson850 said: I've noticed the same thing when I built my 16-bit wide RAM in the console. The difference in execution speed for assembly code with both the workspace and the code in expansion RAM is roughly 110%. That is, fast RAM cuts the time to a little less than half. For Extended BASIC the difference is so small that you have to use a stopwatch to see it. In reality, standard expansion or fast expansion doesn't make any meaningful difference. For Pascal, the difference is roughly 10%. The p-system runs a lot of code that's transferred to the 8K RAM section. The main advantage is that you don't have to consider how to best use the little RAM PAD to speed up your assembly programs. Just run them where they are, and they'll go as fast as possible. But when an interpreter runs sequential code from memory, reading a byte from CPU RAM, GROM or from VDP RAM doesn't make much difference. When reloading the address it does, but you don't do that all the time. Hmm do you mean changing address locations? After all VDP and GROM both are AUTOINCREMENTING after you load the address. There is a huge difference between changing location to read of RAM vs VDP/GROM as you do not need a subroutine to switch address in RAM. For example to switch VDP address you have to do this: * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Write VRAM address * Expects address in R0 * * BL here for writing data * VWADD ORI R0,>4000 * set to write VRAM data * * BL here for reading data * VWADDA MOVB @GR0LB,*R15 * write LSB of R0 to VDPWA MOVB R0,*R15 * write MSB of R0 to VDPWA ANDI R0,>3FFF * ensure R0 returned intact RT Whereas in RAM you do this: MOV @FAC,@ISR * Put FAC into ISR Interupt hook RAM does not require a delay and does word at a time mostly, while VDP/GROM are Byte based in a Word based CPU. Not hard to see this is costly the more bytes transferred as half a word at a time is being used vs full words like RAM. 1 Quote Link to comment Share on other sites More sharing options...
apersson850 Posted June 2, 2022 Share Posted June 2, 2022 14 hours ago, RXB said: Hmm do you mean changing address locations? After all VDP and GROM both are AUTOINCREMENTING after you load the address. Yes, it is, so you only need to reload the address when the program makes a jump. That's why there's not too much difference in performance between reading bytes sequentially from VDP RAM vs. CPU RAM. And most interpreted code (all we discuss here) are byte-sized anyway, so the byte/word processing you write about is irrelevant. It's the same for both. All together it gives that having 16-bit RAM in a machine doesn't improve Extended BASIC's performance in any significant way. It's barely noticeable with the p-system, in spite of having about ten times as much impact there. Quote Link to comment Share on other sites More sharing options...
RXB Posted June 2, 2022 Author Share Posted June 2, 2022 2 hours ago, apersson850 said: Yes, it is, so you only need to reload the address when the program makes a jump. That's why there's not too much difference in performance between reading bytes sequentially from VDP RAM vs. CPU RAM. And most interpreted code (all we discuss here) are byte-sized anyway, so the byte/word processing you write about is irrelevant. It's the same for both. All together it gives that having 16-bit RAM in a machine doesn't improve Extended BASIC's performance in any significant way. It's barely noticeable with the p-system, in spite of having about ten times as much impact there. So you just implied that VDP/GROM is same speed as Assembly for reading/writing bytes? Or as you said "That's why there's not to much difference in performance between reading bytes sequentially from VDP RAM vs CPU RAM." Sorry that is totally hogwash as I been writing GPL for XB for 30 years now. Never has VDP/GROM been the same speed as Assembly doing the samething or reading/writing bytes. I just created RXB 2021 last year and the change in speed from GPL to Assembly is plain to see. Like CALL HCHAR for example is about 9 times faster proving what you said above is hogwash! Quote Link to comment Share on other sites More sharing options...
Willsy Posted June 2, 2022 Share Posted June 2, 2022 I don't think its hogwash. Think of the wider picture. We don't have DMA on the 9900, so anything we do with a sequence of bytes - reading a sequence of bytes from memory, or writing a sequence of bytes to memory - be that RAM, GRAM, GROM, or VDP, involves processing them in a loop in some way - either a tight loop, or an unrolled, or partially unrolled loop. The thing that you're missing is, as an overall percentage of the compute time required to execute the loop and process the data/do whatever it is you're doing, the memory interface is a relatively small contributor to the overall compute time. Don't forget, accessing VDP or GROM memory is a single 9900 machine code instruction, so it can't be that slow. When you consider something like the GPL interpreter, where it is running code from GROM memory, the reading of the bytes via the GROM memory interface doesn't really make any difference, because the interpreter then goes off and does something with those bytes, and that will take a lot longer than the time it took to deliver it to the CPU via the GROM interface. By far the biggest impact of BASIC/XB/RXB on the TI is the dual interpreted nature of the system itself. The technically clever (especially considering they only had 256 bytes of CPU ram!) emulation of a different instruction set on top of the 9900 is the reason for it's slowness in general. But I know you know that very well. 2 Quote Link to comment Share on other sites More sharing options...
TheMole Posted June 2, 2022 Share Posted June 2, 2022 (edited) 1 hour ago, RXB said: So you just implied that VDP/GROM is same speed as Assembly for reading/writing bytes? You're missing the point, or at the very least positing a false dichotomy. This is /not/ about Assembly vs. anything else, this is about the impact of using different types of memory on BASIC program execution speed. The supposition is that using faster memory with the same software implementation (e.g. GPL, Assembly, ...) will lead to faster execution speeds. Or, in this explicit example that faster 16-bit memory will greatly improve execution speeds over slower 8-bit memory. It has been demonstrated multiple times now, by multiple people, that the actual speed increase from using faster memory over slower memory is negligible. Not only has it been demonstrated, people have also explained why that is. So the conclusion is, regardless of how you feel about that, that while 16-bit memory is faster than 8-bit memory and 8-bit memory is faster than VDP RAM and GROM, the actual impact on execution speed of BASIC programs isn't appreciable. I hate saying this, but nothing I've said here has not been said before, you really need to read and do your best to understand what other people have posted before reacting. And please keep the snarkiness to yourself when you do end up disagreeing with someone. We're all here to learn and enjoy ourselves, not to get told off by someone who only half reads these posts. Edited June 2, 2022 by TheMole 4 Quote Link to comment Share on other sites More sharing options...
+TheBF Posted June 2, 2022 Share Posted June 2, 2022 1 hour ago, RXB said: Never has VDP/GROM been the same speed as Assembly doing the samething or reading/writing bytes. This statement may be part of the confusion here Rich. We are not comparing VDP/GROM to Assembly Language One is a form of memory. The other is a programming language. There is nothing to compare here. We are all trying to say: when you read the SAME program from different types of memory and the program is interpreted Memory type (RAM,VDP RAM, GROM) doesn't make very much difference to the execution speed because reading the program bytes is a small percentage of the total time. And as proof of this, my tests and Bill's tests indicated BASIC program code, read from CPU RAM is only 5% faster than reading the program from VDP RAM. 1 1 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted June 2, 2022 Share Posted June 2, 2022 1 hour ago, RXB said: So you just implied that VDP/GROM is same speed as Assembly for reading/writing bytes? This sentence makes no sense. Or as you said "That's why there's not to much difference in performance between reading bytes sequentially from VDP RAM vs CPU RAM." There isn't much. The only difference is the time to set the address. Once that is set it is a simple loop: (Move from CPU RAM to CPU RAM. R1 is source address, R2 is destination, R3 is count) LOOP MOVB *R1+,*R2+ DEC R3 JNE LOOP (Move from VDP ram to CPU ram. R1 contains >8800, R2 is desination, R3 is count) LOOP MOVB *R1,*R2+ DEC R3 JNE LOOP This is actually a bit faster because there is no need to increment R1. Sorry that is totally hogwash as I been writing GPL for XB for 30 years now. Never has VDP/GROM been the same speed as Assembly doing the samething or reading/writing bytes. See above. I just created RXB 2021 last year and the change in speed from GPL to Assembly is plain to see. Like CALL HCHAR for example is about 9 times faster proving what you said above is hogwash! Your HCHAR is quickly writing bytes sequentially to VDP, which, of course, proves apersson's point. Your HCHAR does prove one thing, though. Assembly is faster than GPL. 1 2 Quote Link to comment Share on other sites More sharing options...
GDMike Posted June 2, 2022 Share Posted June 2, 2022 Forth can be seen "FAST" even with a users sloppy coding just by the way it's constructed. Quote Link to comment Share on other sites More sharing options...
Reciprocating Bill Posted June 2, 2022 Share Posted June 2, 2022 There are some other interesting approaches that can help tease out the performance impact of utilizing VDP RAM in settings other than the running XB interpreter. For example, I’m tempted to re-code my assembly version of the Sieve of Erastothenes, placing the 8192 byte array in VDP. A quick run of the Sieve in Chipmunk BASIC shows that the array is read and/or writen to 24,573 times during the course of a single interation of the sieve (including initialization). What impact will the use of VDP RAM have on Sieve performance, relative to an array in RAM? Stay tuned. 4 Quote Link to comment Share on other sites More sharing options...
RXB Posted June 2, 2022 Author Share Posted June 2, 2022 5 hours ago, Willsy said: I don't think its hogwash. Think of the wider picture. We don't have DMA on the 9900, so anything we do with a sequence of bytes - reading a sequence of bytes from memory, or writing a sequence of bytes to memory - be that RAM, GRAM, GROM, or VDP, involves processing them in a loop in some way - either a tight loop, or an unrolled, or partially unrolled loop. The thing that you're missing is, as an overall percentage of the compute time required to execute the loop and process the data/do whatever it is you're doing, the memory interface is a relatively small contributor to the overall compute time. Don't forget, accessing VDP or GROM memory is a single 9900 machine code instruction, so it can't be that slow. When you consider something like the GPL interpreter, where it is running code from GROM memory, the reading of the bytes via the GROM memory interface doesn't really make any difference, because the interpreter then goes off and does something with those bytes, and that will take a lot longer than the time it took to deliver it to the CPU via the GROM interface. By far the biggest impact of BASIC/XB/RXB on the TI is the dual interpreted nature of the system itself. The technically clever (especially considering they only had 256 bytes of CPU ram!) emulation of a different instruction set on top of the 9900 is the reason for it's slowness in general. But I know you know that very well. Running from VDP vs RAM is not the same speed. Why do you people insist that VDP is same speed as RAM when you all go with Assembly? It is like you refuse to admit RAM is faster then VDP or GROM. And by the way VDP and GROM are very close to same speed. If VDP/GROM/RAM are the same speed why even go with Assembly? (It is the worst one for wasting memory!) Quote Link to comment Share on other sites More sharing options...
RXB Posted June 2, 2022 Author Share Posted June 2, 2022 4 hours ago, TheMole said: So the conclusion is, regardless of how you feel about that, that while 16-bit memory is faster than 8-bit memory and 8-bit memory is faster than VDP RAM and GROM, the actual impact on execution speed of BASIC programs isn't appreciable. You just said two total opposites in same sentence? 16 bit is faster then 8 bit and 8 bit is faster then VDP/GROM so why is TI Basic slower then XB? Per your logic they are not, per these above arguments it is not. See why I can not fathom your lack of logic. How about being factual and quit implying there is no difference as you just stated there is one. If there is no difference as you argue why is TI Basic slower then XB? Quote Link to comment Share on other sites More sharing options...
RXB Posted June 2, 2022 Author Share Posted June 2, 2022 4 hours ago, TheBF said: This statement may be part of the confusion here Rich. We are not comparing VDP/GROM to Assembly Language One is a form of memory. The other is a programming language. There is nothing to compare here. We are all trying to say: when you read the SAME program from different types of memory and the program is interpreted Memory type (RAM,VDP RAM, GROM) doesn't make very much difference to the execution speed because reading the program bytes is a small percentage of the total time. And as proof of this, my tests and Bill's tests indicated BASIC program code, read from CPU RAM is only 5% faster than reading the program from VDP RAM. 5%? Where did the 1% or 2% claim go? That is what got me started? Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.