RXB - Rich Extended Basic

[RXB]

 

Oh, hell NO! I hated it, took too damn much time and got in my way. I thought you meant it would not automatically load DSK1.LOAD upon entering RXB. My misunderstanding, apologies.

 

I have multiple configurations I work with, for instance the Super Cart handles my HDX stuff, when I switch the widget to XB I load off of disk. It's only now that I'm regretting not getting a multiple bank Super Cart because with the HxC coming, I can see that I'll be needing 4DOS again, and I don't want to keep having to reload 4A DOS and Quickload in and out of the Super Cart. It's always something.

Press any key in RXB 2001 or RXB 2012 and it by passes the search and goes to Edit Mode in XB.

 

RXB 2014 will have all the Hard Drive and Disk utilities fixed to work properly again.

I am also doing a small rewrite of REA 2011 to fix what I can and make it more useful.

[+Lee Stewart]

Also working on fixing the freaking horridly slow and bloated RANDOM number seed and and possible fixing RND to not be so slow in XB.

Here is the RANDOM seed:

 

 

<0363> A295 42,03,23 X2SEED BYTE >42,>03,>23,>15,>00 * =   33521, X2 INITIAL VAL
       A298 15,00
<0364> A29A 43,02,3E X1SEED BYTE >43,>02,>3E,>2A,>17 * = 2624223, X1 INITIAL VAL
       A29D 2A,17
<0365>               ***********************************************************
<0366>               *           PSEUDO-RANDOM NUMBER GENERATOR
<0367>               *      X(N+1) = (A*X(N)+C) MOD M;  RND = X/M
<0368>               *    WHERE:                 X = X2 * 1E7 + X1
<0369>               *                           A = A2 * 1E7 + A1
<0370>               *                           C = C2 * 1E7 + C1
<0371>               *                           M = 1E14
<0372>               * ASSUMPTIONS:
<0373>               *  (1) All numbers are integers; fractional parts are
<0374>               *      truncated
<0375>               *  (2) If the variables listed below start in the ranges
<0376>               *     specified. They will also end in the ranges specified
<0377>               *
<0378>               * CONSTANTS: 0 <= A2 < 5E6 ; 0 <= C2 < 1E7
<0379>               *            0 <= A1 < 5E6 ; 0 <= C1 < 1E7
<0380>               * VARIABLES: 0 <= X2 < 1E7 ; 0 <= T1 <= 1E14 ; 0 <= T2 < 1E
<0381>               *            0 <= X1 < 1E7 ; 0 <= T3 <= 1E14 ; 0 <= T4 < 1E
<0382>               *
<0383>               *        STACK USAGE:
<0384>               *            CONSTANT REFS      CONTANT REFS    CONTANT REF
<0385>               * +---------+      IN/OUT            IN/OUT          IN/OUT
<0386>               * | STACK+4 | X2*A1(F)(H)       --    ----      --    ----

99/4 GPL-ASSEMBLER (Pass 3) correct                                   PAGE 0016 
EQUATES EXEC-359
<0387>               * +---------+
<0388>               * | STACK+3 |   T2 (C)(J)       --    ----      --    ----
<0389>               * +---------+
<0390>               * | STACK+2 |   T1 (B)(D)   new X1   (E)(N)     --    ----
<0391>               * +---------+
<0392>               * | STACK+1 |old X1(A)(G)       T3   (K)(L) new X2   (M)(P)
<0393>               * +---------+
<0394>               ***********************************************************
<0395>               * COMPUTE NEW VALUE FOR X1, SAVE IT IN V@RNDX1
<0396>               *                             STACK
<0397>               *                               SREFS   FAC CONTENTS
<0398> A29F 35,00,05 NRND   MOVE 5,V@RNDX1,@FAC        FAC = X1
       A2A2 4A,A3,A5
<0399> A2A5 86,4F           CLR  @FAC5                 FAC = CLR
<0400> A2A7 87,50           DCLR @FAC6                 FAC = CLR
<0401> A2A9 0F,77           XML  VPUSH          (A)    FAC = X1
<0402> A2AB 31,00,08        MOVE 8,G@RNDA1,@ARG        ARG = A1
       A2AE 5C,A3,57
<0403> A2B1 0F,08           XML  FMUL                  FAC = X1*A1
<0404> A2B3 31,00,08        MOVE 8,G@RNDC1,@ARG        ARG = C1
       A2B6 5C,A3,67
<0405> A2B9 0F,06           XML  FADD               T1=FAC = X1*A1+C1
<0406> A2BB 0F,77           XML  VPUSH          (B)    FAC = T1
<0407> A2BD 31,00,08        MOVE 8,G@RNDEM,@ARG        ARG = 1/1E7
       A2C0 5C,A3,77
<0408> A2C3 0F,08           XML  FMUL                  FAC = T1/1E7
<0409> A2C5 06,00,22        CALL GRINT              T2=FAC = INT(T1/1E7)
<0410> A2C8 0F,77           XML  VPUSH          (C)    FAC = T2
<0411> A2CA 31,00,08        MOVE 8,G@RNDEP,@ARG        ARG = 1E7
       A2CD 5C,A3,6F
<0412> A2D0 0F,08           XML  FMUL                  FAC = T2*1E7
<0413> A2D2 A7,6E,00        DSUB 8,@VSPTR
       A2D5 08
<0414> A2D6 0F,0C           XML  SSUB           (D) X1=FAC = T1-T2*1E7
<0415> A2D8 35,00,05        MOVE 5,@FAC,V@RNDX1        FAC = X1 (new)
       A2DB A3,A5,4A
<0416> A2DE 0F,77           XML  VPUSH          (E)    FAC = X1
<0417>               * COMPUTE NEW VALUE FOR X2, SAVE IT IN V@RNDX2
<0418> A2E0 35,00,05        MOVE 5,V@RNDX2,@FAC        FAC = X2
       A2E3 4A,A3,A0
<0419> A2E6 86,4F           CLR  @FAC5                 FAC = CLR
<0420> A2E8 87,50           DCLR @FAC6                 FAC = CLR
<0421> A2EA 31,00,08        MOVE 8,G@RNDA1,@ARG        ARG = A1
       A2ED 5C,A3,57
<0422> A2F0 0F,08           XML  FMUL                  FAC = X2*A1
<0423> A2F2 A3,6E,00        DADD 8,@VSPTR
       A2F5 08
<0424> A2F6 0F,77           XML  VPUSH          (F)    FAC = X2*A1
<0425> A2F8 A7,6E,00        DSUB 24,@VSPTR
       A2FB 18
<0426> A2FC 0F,78           XML  VPOP           (G)    FAC = X1
<0427> A2FE A3,6E,00        DADD 32,@VSPTR
       A301 20
<0428> A302 31,00,08        MOVE 8,G@RNDA2,@ARG        ARG = A2
       A305 5C,A3,4F
<0429> A308 0F,08           XML  FMUL                  FAC = X1*A2
<0430> A30A 0F,0B           XML  SADD           (H)    FAC = X2*A1+X1*A2
<0431> A30C 31,00,08        MOVE 8,G@RNDC2,@ARG        ARG = C2
       A30F 5C,A3,5F
<0432> A312 0F,06           XML  FADD                  FAC = X2*A1+X1*A2
<0433> A314 0F,0B           XML  SADD           (J) T3=FAC = X2*A1+X1*A2
<0434> A316 A7,6E,00        DSUB 16,@VSPTR
       A319 10
<0435> A31A 0F,77           XML  VPUSH          (K)    FAC = T3

99/4 GPL-ASSEMBLER (Pass 3) correct                                   PAGE 0017 
EQUATES EXEC-359
<0436> A31C 31,00,08        MOVE 8,G@RNDEM,@ARG        ARG = 1/1E7
       A31F 5C,A3,77
<0437> A322 0F,08           XML  FMUL                  FAC = T3/1E7
<0438> A324 06,00,22        CALL GRINT              T4=FAC = INT(T3/1E7)
<0439> A327 31,00,08        MOVE 8,G@RNDEP,@ARG        ARG = 1E7
       A32A 5C,A3,6F
<0440> A32D 0F,08           XML  FMUL                  FAC = T4*1E7
<0441> A32F 0F,0C           XML  SSUB           (L) X2=FAC = T3-T4*1E7
<0442> A331 35,00,05        MOVE 5,@FAC,V@RNDX2        FAC = X2 (new)
       A334 A3,A0,4A
<0443>               * COMPUTE NEW VALUE FOR RND, LEAVE IT IN FAC
<0444> A337 31,00,08        MOVE 8,G@RNDEM,@ARG        ARG = 1/1E7
       A33A 5C,A3,77
<0445> A33D 0F,08           XML  FMUL                  FAC = X2/1E7
<0446> A33F 0F,77           XML  VPUSH          (M)    FAC = X2/1E7
<0447> A341 A3,6E,00        DADD 8,@VSPTR
       A344 08
<0448> A345 0F,78           XML  VPOP           (N)    FAC = X1
<0449> A347 0F,08           XML  FMUL                  FAC = X1/1E7
<0450> A349 0F,08           XML  FMUL                  FAC = X1/1E14
<0451> A34B 0F,0B           XML  SADD           (P)RND=FAC = (X2/1E7)+(X1/1E14)
<0452> A34D 0F,75           XML  CONT
<0453>               ***********************************************************
<0454>               * CONSTANTS FOR THE RANDOM NUMBER ROUTINE
<0455> A34F 43,01,2B RNDA2  BYTE >43,>01,>2B,>59,>52,>00,>00,>00 * = 1438982
       A352 59,52,00
       A355 00,00
<0456> A357 42,2A,08 RNDA1  BYTE >42,>2A,>08,>15,>00,>00,>00,>00 * = 0420821
       A35A 15,00,00
       A35D 00,00
<0457> A35F 43,02,0B RNDC2  BYTE >43,>02,>0B,>20,>30,>00,>00,>00 * = 2113248
       A362 20,30,00
       A365 00,00
<0458> A367 43,06,36 RNDC1  BYTE >43,>06,>36,>05,>13,>00,>00,>00 * = 6540519
       A36A 05,13,00
       A36D 00,00
<0459> A36F 43,0A,00 RNDEP  BYTE >43,>0A,>00,>00,>00,>00,>00,>00 * = 1E7
       A372 00,00,00
       A375 00,00
<0460> A377 3C,0A,00 RNDEM  BYTE >3C,>0A,>00,>00,>00,>00,>00,>00 * = 1/1E7
       A37A 00,00,00
       A37D 00,00
<0461>               ***********************************************************
<0462>               *                   RANDOMIZE STATEMENT
<0463>               ***********************************************************
<0464> A37F 06,6A,78 NRNDMZ CALL CHKEND            Seed provider?
<0465> A382 63,C0           BS   RNDM1             No
<0466>               * RANDOMIZE given a see value
<0467>               * (99,000,000,000,001 possible starting positions)
<0468>               * (Place-value is ignored in the input number)
<0469> A384 0F,74           XML  PARSE             Parse the seed
<0470> A386 83              BYTE TREMZ           * Up to end of statement
<0471> A387 06,A3,ED        CALL CKSTNM
<0472> A38A 8F,4A           DCZ  @FAC              Check FAC for zero
<0473> A38C 63,B6           BS   GA3B6
<0474> A38E BE,4A,46        ST   >46,@FAC          0 < FAC < 1E14
<0475> A391 0F,77           XML  VPUSH             Let FAC = X2*1E7+X1
<0476> A393 31,00,08        MOVE 8,G@RNDEM,@ARG        ARG = 1/1E7
       A396 5C,A3,77
<0477> A399 0F,08           XML  FMUL                  FAC = X2+X1/1E7
<0478> A39B 06,00,22        CALL GRINT                 FAC = X2
<0479> A39E 35,00,05        MOVE 5,@FAC,V@RNDX2        FAC = X2
       A3A1 A3,A0,4A
<0480> A3A4 31,00,08        MOVE 8,G@RNDEP,@ARG        ARG = 1E7

99/4 GPL-ASSEMBLER (Pass 3) correct                                   PAGE 0018 
EQUATES EXEC-359
       A3A7 5C,A3,6F
<0481> A3AA 0F,08           XML  FMUL                  FAC = X2*1E7
<0482> A3AC 0F,0C           XML  SSUB                  FAC = X1
<0483> A3AE 35,00,05        MOVE 5,@FAC,V@RNDX1        FAC = X1
       A3B1 A3,A5,4A
<0484> A3B4 0F,75           XML  CONT                  FAC = X1
<0485> A3B6 BD,A3,A0 GA3B6  DST  @FAC,V@RNDX2          FAC = 0
       A3B9 4A
<0486> A3BA BD,A3,A5        DST  @FAC,V@RNDX1          FAC = 0
       A3BD 4A
<0487> A3BE 0F,75           XML  CONT
<0488>               * RANDOMIZE given number seed value (use GPL RAND function)
<0489>               * (16K possible starting positions)
<0490> A3C0 BF,4A,42 RNDM1  DST  >4201,@FAC            FAC = >4201
       A3C3 01
<0491> A3C4 86,4E           CLR  @FAC4                 FAC4= >00
<0492> A3C6 06,A3,D2        CALL RNDMZ
<0493> A3C9 03,A5           DATA RNDX1
<0494> A3CB 06,A3,D2        CALL RNDMZ             Set up seed
<0495> A3CE 03,A0           DATA RNDX2
<0496> A3D0 0F,75           XML  CONT              Continue on
<0497> A3D2 88,52    RNDMZ  FETCH @FAC8            Fetch address of seed (high b
<0498> A3D4 88,53           FETCH @FAC9            Fetch address of seed (low by
<0499> A3D6 02,63           RAND 99                GPL Randomize
<0500> A3D8 BC,4C,78        ST   @RANDOM,@FAC2     >00<=FAC+2<=FF
<0501> A3DB E6,4C,02        SRL  2,@FAC2           >00<=FAC+2<=3F
<0502> A3DE 02,63           RAND 99                GPL Randomize
<0503> A3E0 BC,4D,78        ST   @RANDOM,@FAC3     >00<=FAC+3<=FF
<0504> A3E3 E6,4D,02        SRL  2,@FAC3           >00<=FAC+3<=3F
<0505> A3E6 35,00,05        MOVE 5,@FAC,V*FAC8     Put in seed
       A3E9 B0,52,4A
<0506> A3EC 00              RTN
<0507> A3ED D6,4C,65 CKSTNM CEQ  >65,@FAC2
<0508> A3F0 6D,BE           BS   ERRSNM
<0509> A3F2 00              RTN
<0510> A3F3 40,01,00 FLT1   BYTE >40,>01,>00,>00,>00,>00,>00,>00
       A3F6 00,00,00
       A3F9 00,00

 

 

Why would TI make it so freaking complicated and bloated?

What problem were they attempting to solve?

It looks like TI was attempting to create a new version of math for RANDOM numbers!

 

P.S.

I am thinking of making a IRND that is integer based only version of RND unlike the Floating Point version.

Also a IRANDOM seed that is a Integer based only version of RANDOM seed unlike the Floating Point version.

 

 

This is something I've been meaning to take a look at for a long time. I'm still not really ready to do it; but, I'll share what I've been thinking:

 

First off, RND should always produce the same series of pseudo-random numbers every time it starts with the same seed. That's why RANDOMIZE has the option to be followed by a number that will become the new seed for the next time RND is run. The reason the other use of RANDOMIZE is important is that you get an unpredictable number for the seed. The random number seed is stored at >83C0 and is 16 bits wide. TI Basic puts the first 2 bytes of the 8 byte floating point (FP) number following RANDOMIZE into >83C0. I'm not sure how XB does it because I haven't yet tried to decipher the code you posted, Rich.

 

The code you've posted before for TI Basic's RND is more complicated than it looks. It calls the GPL RAND function at least 7 times and could be called as much as 63 times, though that is highly unlikely because the first time RAND is called, it would have to return 0 followed by a 0 every time thereafter for the next 62 calls! The TI Basic RND function builds an 8-byte FP number at FAC (>834A) by first placing >3F (offset-64 code for a radix-100 exponent of -1) in the exponent byte to insure a positive number less than 1. It then proceeds to call RAND 7 more times for each of the next 7 bytes of the FP number. If the first byte is 0, it decrements the exponent and tries again until the result is non-zero or the exponent is decremented to 0, in which case it sets the FP number to 0. Otherwise,the next 6 bytes are determined, 0 or not. Here's the console ALC for the GPL RAND function (which, BTW, must be called with a maximum return value: RAND 99, in this case):

 

 

 

GPL RAND:

027A 0204 LI 4,>6FE5 Generate random number

027C 6FE5

027E 3920 MPY @>83C0,4

0280 83C0

0282 0225 AI 5,>7AB9

0284 7AB9

0286 C805 MOV 5,@>83C0 Load random number seed

0288 83C0

028A D19D MOVB *13,6 Fetch limit

028C 0986 SRL 6,8 in Lbyte

028E 0586 INC 6 +1

0290 04C4 CLR 4

0292 06C5 SWPB 5

0294 3D06 DIV 6,4

0296 D820 MOVB @>83EB,@>8378 Random number on source

0298 83EB

029A 8378

029C 1006 JMP >02AA To GPL interpreter

 

 

 

The formula that RAND uses to calculate the next seed to store at >83C0 is >6FE5 * <old seed> + >7AB9. It then returns a single byte in >8378 that is between 0 and the maximum number passed to RAND. The TI Forth programmers added a step that is perhaps unintentionally missing from TI Basic: a circular right shift of 5 bits.

 

In TI Forth and fbForth, RND returns a positive 16-bit integer. To get a floating point random number in TI Forth/fbForth, there is FRND, which calls RND 7 times to build the FP number to return.

 

RANDOMIZE in TI Forth/fbForth starts a 16-bit counter that is stopped when the next video interrupt is detected. The value of this counter becomes the new seed.

 

I haven't quite figured out what TI Basic is doing in its RANDOMIZE, but it is similarly simple. Again, the idea is to produce an unpredictable number for the new seed.

 

XB's versions are complicated, as you say. I suspect the programmers were trying to make a better RND with better distribution of digits. It is riddled with slow floating point math. I have no idea (yet) why RANDOMIZE seems more complicated.

 

Hope these ramblings help a little.

 

...lee

[RXB]

Lee

 

I have replaced the RND in XB with the TI BASIC RND and tests show it is almost twice as fast now.

TI BASIC RND when in TI BASIC is much slower when you add more variables to a test program as the added VDP access slows TI BASIC to a crawl.

But has a minimum effects on XB so the same RND in RXB or XB is much faster.

 

Some XB games are noticeably faster. And I can see a minimum effect overall as a side effect of this change.

 

I am including a copy of how to load into RXB or XB or SXB or XB 2.6 into Classic99 and you guys can use to test it.

README shows how.

 

Forgot to mention it uses GRAM >A000

RXB RND.zip

Edited August 11, 2014 by RXB

[sometimes99er]

How about an easy way to turn those I/V254's into E/A 5's!

LOL well XB256 does that already.

Really? I must be losing my mind. I thought XB256 was just a set of call link commands that allowed for extra stuff WITHIN the Extended BASIC environment. Let me be clear with what you are saying, you are saying that XB256 will take an XB program, that was saved in I/V 256 format, and convert it into an E/A 5 program that can be run WITHOUT XB but by using the Editor Assembler module?

Yes, it got that far. Of course it all goes from floating point to integer and a few things are not possible, like OPEN, and some are used slightly differently, like RND.

 

http://atariage.com/forums/topic/224905-xb-game-developers-package

[RXB]

Yes, it got that far. Of course it all goes from floating point to integer and a few things are not possible, like OPEN, and some are used slightly differently, like RND.

 

http://atariage.com/forums/topic/224905-xb-game-developers-package

I was not saying XB256 package takes IV254 files and turns them into EA5 programs.

I was saying that there are tools to take XB programs and turn them into EA5 programs.

There is no easy way to do this and most likely will never be.

Even the tools require a considerable amount of knowledge.

[sometimes99er]

I was not saying XB256 package takes IV254 files and turns them into EA5 programs.

Okay, fooled me.

 

Anyway, I would still say it does (on a larger scale, but of course many/most things won't compile just like that etc.).

 

I was not saying XB256 package takes IV254 files and turns them into EA5 programs.

I was saying that there are tools to take XB programs and turn them into EA5 programs.

There is no easy way to do this and most likely will never be.

Even the tools require a considerable amount of knowledge.

Yes.

[senior_falcon]

Actually, XB256 consists of assembly subroutines that add to the versatility of XB. Two independant screens are available, one with 256 characters, scroll routines, etc. The compiler will start with an XB program and create an assembly language file that can be loaded as EA5 or as an XB program. Compiled programs run much faster, but there are some limitations on what can be compiled. I don't see how you could convert an XB program into EA5 format so that it would run as an XB program without the XB cartridge in the slot. If you can live with having the XB cartridge in the slot, then it should be fairly easy to convert an XB program into EA5 simply by copying the appropriate memory locations in the CPU and VDP and having the EA5 loader restore them. If this were done after the prescan then the program would start immediately.

 

Of course, it would be possible to run a TI BASIC program using an EA5 loader since BASIC is in the console by default.

Edited August 11, 2014 by senior_falcon

[sometimes99er]

If you can live with having the XB program in the slot, then it should be fairly easy to convert an XB program into EA5 simply by copying the appropriate memory locations in the CPU and VDP and having the EA5 loader restore them.

Ah, yes. Never thought of that as an answer to the question.

 

How about an easy way to turn those I/V254's into E/A 5's!

[Gazoo]

 

... If you can live with having the XB cartridge in the slot, then it should be fairly easy to convert an XB program into EA5 simply by copying the appropriate memory locations in the CPU and VDP and having the EA5 loader restore them. If this were done after the prescan then the program would start immediately.

 

Can you perhaps elaborate on this? Perhaps a tutorial? It would be nice to be able to store XB programs in the ROM area of the ubergrom cart and be able to run them from there. It's easy enough to do with EA5 programs, and doing do with XB programs seems like it would only take an additional step or two.

 

Gazoo

[RXB]

Many years ago using the SAMS I did exactly that.

Wrote a GPL program that copied all the VDP and VDP registers to SAMS banks of memory then copied the 32K.

Saved the entire thing to Hard Drive as a single file in Int/Var 132 format. (do not remember why I used that size)

 

You can do this now with RXB 2001 using CALL USER and CALL BLOAD and CALL BSAVE utilizing the SAMS.

You just need to load the VDP last before you start the program.

 

It is not EA5 as that is a different module then XB. But accomplishes that in the easy to use XB environment.

Edited August 11, 2014 by RXB

[RXB]

Please can you guys try out the new RND in XB I posted a easy to use version in Classic99.

[RXB]

Preview 2014 number 2

 

Also another test of RND vs TI BASIC RND

 

[senior_falcon]

Rich, anything that speeds up XB is a good thing and since RND is a real boondoggle your mods are great and will be much appreciated. However, your demo above doesn't prove anything about the relative speeds of RND in XB vs TI BASIC. There are way too many program lines to be able to say that one line is the culprit. In fact your simple demo in post #357 shows that RND in BASIC is a bit faster, and also that the new RXB is way faster than the old XB. Actually, you under report the speed increase in RXB. Your test program was:

100 X=RND

110 Y=Y+1

120 GOTO 100

You don't take into account how much time lines 110 and 120 take, which should be the same in RXB and standard XB. You can run your program for one minute and print Y, then change line 120 to GOTO 110 and run that for one minute. That will give you enough information so you can determine how much time it takes to execute line 100 once. A slightly different test I did shows the BASIC RND running almost 6 times faster than XB and your routine should be around 5 times faster!

 

Here are some benchmarks that will show the real reason the program above runs slower in BASIC compared to RXB. (BTW, I used Win994a for these because I feel the timing is more accurate than Classic99 - sorry Tursi!)

10 FOR I=1 TO 10000

20 NEXT I

Runs in 27 seconds in BASIC and 36 seconds in XB

Then this program:

10 FOR R=1 TO 24

20 FOR C=1 TO 32

30 CALL HCHAR(R,C,42)

40 NEXT C

50 NEXT R

This takes 16 seconds in XB and 38 seconds in BASIC. After you subtract the amount of time spent looping it will be around 13 seconds vs 35 seconds which means BASIC takes more than 2.5 times longer for each CALL HCHAR. So it's not the RND that makes your test program faster; it is all the CALL HCHARs that are used.

 

(edit) I ran the RND speed test as described above. Each result is Y after one minute:

TI BASIC:

3657 with RND

11585 without RND - Then 60/3657-60/11585 give .0112 seconds per RND

TIXB

858 with RND

9128 without RND- Then 60/858-60/9128 gives.0633 seconds per RND

Edited August 13, 2014 by senior_falcon

[RXB]

Yea like have mentioned before the sheer size of the list in XB vs TI Basic is also costing speed for RXB or XB.

Compare how many commands are in XB vs TI Basic.

 

Every single time a command of any type is used in Basic or XB it has to do a search and the longer the list the longer it takes.

I tried to keep the list very efficient for XB but the problem is the locations where they put them makes that very hard to manage without changing locations to much.

The issue would become some software would not function as some software like Bruce Harrisons software depends on stuff to be at a set location.

Thus in order to stay backwards compatible I am forced to leave stuff where it was originally located, but if I could moved it would speed up many functions in XB slightly.

 

Many years ago I added like 110 commands to XB in a old RXB version but it was slow as you could see the slow down in huge XB programs. (I think version 5.50 or 5.55 up to 7.80)

 

You are correct that TI Basic RND alone is still faster then 2014 RXB RND but only slightly.

And as I said before no one writes those types of programs so a mute data point. What use is RND if all you can do is a 2 or 3 line program?

[+InsaneMultitasker]

 

You are correct that TI Basic RND alone is still faster then 2014 RXB RND but only slightly.

And as I said before no one writes those types of programs so a mute data point. What use is RND if all you can do is a 2 or 3 line program?

 

I think a good takeaway here is that to compare command or instruction speeds, you must first eliminate the time it takes to execute everything else. Otherwise the results may be skewed by differences in the interpreters, commands, etc.

[gregallenwarner]

I don't know anything about the internal workings of XB or RXB, but when you mention the calls which have to traverse a list, and when the list gets longer the search takes longer, I can only wonder, is it possible to use a hash table instead of a list structure for storing the routines to be called? That way, no matter how long the list gets, the lookup time will be of complexity O(1) rather than O(n) of a list, assuming sequential search.

 

Or, if the command list was sorted alphabetically, then at the very least a binary search could be implemented for O(log n) lookup time, greatly improving search time.

 

Again, I don't know much about how XB or RXB are constructed. My only familiarity is with Assembly.

[Willsy]

The numeric token values could simply be their ordinal position in the table, making it very easy to look up their address from an array. We're 30 odd years too late though!

Edited August 13, 2014 by Willsy

[gregallenwarner]

I was just thinking, if Rich wanted to speed up RXB even more and REALLY kick XB and TIBasic's a**, a rewrite of the command search routine could be worth a look. Just my humble opinion.

[senior_falcon]

 

I think a good takeaway here is that to compare command or instruction speeds, you must first eliminate the time it takes to execute everything else. Otherwise the results may be skewed by differences in the interpreters, commands, etc.

Yes that is exactly my point. Look, I don't want to be an apologist for TI BASIC. There are lots of things I dislike about it - the slow startup, the slow garbage collection, etc. But the idea that graphics statements somehow make RND execute more slowly is silly. Check it out for yourself - add those lines: 10 X=RND 20 Y=Y+1 30 GOTO 10 to kaleidoscope (adjusting the line numbers as necessary) and see if that loop runs slower.

 

As far as BASIC always being inferior to XB, consider a program that computes Pi to 100 digits. No graphics are needed and it seems to me that being able to run that 10% to 15% faster in TI BASIC would be a plus.

[RXB]

I don't know anything about the internal workings of XB or RXB, but when you mention the calls which have to traverse a list, and when the list gets longer the search takes longer, I can only wonder, is it possible to use a hash table instead of a list structure for storing the routines to be called? That way, no matter how long the list gets, the lookup time will be of complexity O(1) rather than O(n) of a list, assuming sequential search.

 

Or, if the command list was sorted alphabetically, then at the very least a binary search could be implemented for O(log n) lookup time, greatly improving search time.

 

Again, I don't know much about how XB or RXB are constructed. My only familiarity is with Assembly.

The ROM 0 & GROM 0 (zero) has the DSR search so works like this:

Look in TIINTERN book page 99 at >0010 this is the branch in GROM for DSRLNK

You see the TI used the same routine to find a device and considers any name a device, so CALL EA or OLD EA in RXB is just as valid as SAVE DSK1......

 

A byte value of >10 tells it to search for names in GROM or VDP and ROMs this is why Assembly normally can not find anything in GROM or VDP as it never looks for things like CS1 or CS2.

On the otherhand the GPL DSRLNK always looks if you use >10 using the GSRLNK that follows the GPL DSRLNK in GROM 0

 

So to answer your question this would require a entire rewrite of GROM 0 and ROM 0 (zero) to use that type of search.

Another can of worms is that XB does not use the same name search that Basic uses as the two have different set ups for how the name list works the order is reversed on purpose so the OS does not confuse

the list from BASIC with XB or visa versa. This was a well thought out safety measure to create less cartridge conflicts down the line.

 

TI never intended for someone like me to put so many device names into the list that it bogged down the OS to a crawl.

[RXB]

Yes that is exactly my point. Look, I don't want to be an apologist for TI BASIC. There are lots of things I dislike about it - the slow startup, the slow garbage collection, etc. But the idea that graphics statements somehow make RND execute more slowly is silly. Check it out for yourself - add those lines: 10 X=RND 20 Y=Y+1 30 GOTO 10 to kaleidoscope (adjusting the line numbers as necessary) and see if that loop runs slower.

 

As far as BASIC always being inferior to XB, consider a program that computes Pi to 100 digits. No graphics are needed and it seems to me that being able to run that 10% to 15% faster in TI BASIC would be a plus.

If you are going to argue that Basic is better then XB we are done discussing here.

 

RXB runs Basic programs faster then Basic can run it's own programs.

Unless you rig the contest by only using things TI Basic is faster at like RND or PI as if no one is going to ever write anything else.

After all all around performance is 100% better then only doing a few things well, again unless you do nothing else at all permanently.

 

I doubt you are going to find anyone that says TI Basic is better then XB to use.

[+InsaneMultitasker]

I doubt you are going to find anyone that says TI Basic is better then XB to use.

 

The last time I used BASIC for anything was probably 1985 or 1986. XB all the way!! I see this as separate from the benchmarking conversation.

[senior_falcon]

Rich, you are changing the subject. Of course XB is better 99.9% of the time, maybe 99.99% (Although if you had more than 8K of A/L subs one could make a case for using TI BASIC using the EA or MiniMemory cartridge which can load up to 32K of assembly routines much faster than the XB loader can. But now I'm changing the subject...)

 

You posted a video showing the same program running slower in BASIC compared to RXB and repeatedly said the reason for that was the random number generator. You also said that adding graphics slows down RND in BASIC. Neither of these is correct, as both your tests and my tests show. I showed how to determine the amount of time it takes to execute a program line and from that found that RXB does RND 5x faster than XB, not the 2.5x that you claimed. That should make you happy and you should be trumpeting that fact and the many, many other excellent features of RXB, rather than continuing to repeat information that your own tests show is incorrect.

 

To reiterate, RND has nothing to do with why BASIC is slower - it is the use of CALLs. They are usually around 2.5x slower (if interested you can use the method above to find out exactly how much slower) and of course running BASIC programs in RXB takes advantage of the faster XB CALLs, which is great. Faster is better. And by the way, thank you very much for putting all the effort into this package. I am sure there are times when it feels like a bottomless pit that you are throwing your time into.

[senior_falcon]

 

Can you perhaps elaborate on this? Perhaps a tutorial? It would be nice to be able to store XB programs in the ROM area of the ubergrom cart and be able to run them from there. It's easy enough to do with EA5 programs, and doing do with XB programs seems like it would only take an additional step or two.

 

Gazoo

I don't believe you can do this directly with the EA5 loader, but I think it can be done this way:

1 - write an assembly subroutine that first copies VDP memory to a disk file. The brute force method would be to copy the entire VDP, the finesse method would just copy the areas actually used by XB. Then it should copy high memory. As before, you can brute force it or finesse it. Finally copy low memory and the scratchpad to another file. Again, brute force or finesse - your choice. The files should probably have sequential names like in EA5 programs - i.e. GAME, GAMF, etc. Also, you would have to record the workspace and program counter.

2 - load the XB program, then use CALL INIT and CALL LOAD to load the assembly routine to low memory. Add CALL LINK("PROGNAME") to your XB program at the line where you would like it to be saved. This could be at the beginning after the prescan or even better, after all the characters have been defined and the screen drawn. Run the program to save all the memory locations.

3 - write a loader that runs as an EA5 program. This should read the files created above and load them into the proper memory locations. Set up the workspace and program counter and now you are exactly where you were when you interrupted the program to save the files. Return to XB and you will resume running the program at the point where it was saved.

 

Of course, all this assumes that you still have the XB cartridge in the slot.

[gregallenwarner]

The ROM 0 & GROM 0 (zero) has the DSR search so works like this:

Look in TIINTERN book page 99 at >0010 this is the branch in GROM for DSRLNK

You see the TI used the same routine to find a device and considers any name a device, so CALL EA or OLD EA in RXB is just as valid as SAVE DSK1......

 

A byte value of >10 tells it to search for names in GROM or VDP and ROMs this is why Assembly normally can not find anything in GROM or VDP as it never looks for things like CS1 or CS2.

On the otherhand the GPL DSRLNK always looks if you use >10 using the GSRLNK that follows the GPL DSRLNK in GROM 0

 

So to answer your question this would require a entire rewrite of GROM 0 and ROM 0 (zero) to use that type of search.

Another can of worms is that XB does not use the same name search that Basic uses as the two have different set ups for how the name list works the order is reversed on purpose so the OS does not confuse

the list from BASIC with XB or visa versa. This was a well thought out safety measure to create less cartridge conflicts down the line.

 

TI never intended for someone like me to put so many device names into the list that it bogged down the OS to a crawl.

 

I gotcha. I didn't know how TI Basic's and XB's searches were constructed.

 

As a side note, approximately how much GPL is there in XB and in RXB? Or do they even rely on GPL at all?