StrangeCart

[+RXB]

RXB unlike XB256 can work with ONLY CONSOLE without 32K or any other devices.

And you get Assembly speeds from CONSOLE.

They are not even close to the same approach.

You are not being objective in the least.

 

Also if you take out the GROM delays then GPL would be the same speed as Forth.

 

[fabrice montupet]

There is nowhere in my message where I were subjective. I tested for a while RXB and XB256 and made my choice. Please, accept that.
"ONLY CONSOLE without 32K ", an argument that you constantly put forward in loops and loops on AtariAge, yes it is technically interesting, an especially taste for challenge for you but, for present users, who in here really cares now, we are not anymore in the years 80 where any TI-99/4A expansion cost an arm and a leg. Now the 32 KB expansion costs nearly nothing. Like XB256, if ones want to use RXB, he must get too a FlashROM 99 or a FinalGROM99 that cost . So if ones can buy a such cartridge he can also buy a 32Kb expansion.  We see now that price is not a problem anymore. So I personally prefer using a language that offers many powerful graphic and sound features and great performances thanks to compilation,  benefiting in addition the 32KB memory space for more elaborated programs than the 16KB of the stock computer can offers.

[+Ksarul]

14 hours ago, RXB said:

A good portion of XB3 is Assembly in the ROMs so I have been disassembling XB3 as there is no source code.

So far I have 90% of ROM 1 done and 30% of ROM 2 done.

With the GPL and ROMs source I can make XB way faster as more Assembly replaces GPL and is 100% backwards compatible.

If GPL could be speeded up it would kill my task entirely as useless.

It wouldn't be useless, Rich, but it would give people some additional use cases. That is the beauty of our hobby--variety.

[+TheBF]

1 hour ago, RXB said:

Also if you take out the GROM delays then GPL would be the same speed as Forth.

It would be the about same speed as byte-coded Forth. 

 

Byte code Forth is about 30% .. 40% slower than indirect threaded code Forth (Most TI-99 Forth systems)

ITC is 15% slower than direct threaded code Forth

DTC  is ~20% .. 30% slower than sub-routine threaded code Forth (Camel99 DTC Forth)

STC  is  ~2.5X slower than native code generating Forth compilers.

 

[senior_falcon]

On 6/8/2023 at 6:03 AM, speccery said:

At least I don't see it that way. When we think about speeding up GPL in the broad sense, it appears there would be three ways to go:

1. Convert GPL to TMS9900 machine code, which is what you have been doing. The beauty of this is that all you would need in addition to the bare computer is a ROM/GROM cartridge (I guess ROM only if everything was converted from GPL to assembly). Also, this approach is "era correct" since you're using the original CPU etc. aside from potentially using higher density memory chips RXB could have existed back in the day with the same good performance.

In principle, you could take a gpl program like TI BASIC or XB and do an instruction by instruction replacement of the gpl code with assembly instructions.

The following lines are from the TI BASIC interpreter, with assembly equivalents on the right.

Naturally, what I have written would need some changes. There are no labels. CALL GROM is stack oriented, so instead of BL you'd have to implement a stack for this, but I think you could use the same stack locations as regular BASIC.

I am certain that a total rewrite would be more efficient, but this approach has the advantage of not needing a lot of design work. It is based on code that is known to work, so you would not need to reinvent TI BASIC.

I wonder if one of the AI engines in the news recently could be trained to do this automatically.

 

(Edit) The beauty of converting TI BASIC as a first step is that it runs from VDP ram, which means that you have 32K of memory to use for the interpreter. So you you can just load and test without the complexities of a bank switched cartridge. This would be an excellent first step to see:

1 - if this is even possible

2 - if it is possible, what sort of speed increase could result.

 

2C2B DST @>8314,>0064       MOV @HX0064,@>8314
2C2F DST @>831E,>000A       MOV @HX000A,@>831E
2C33 ST @>8308,>2C            MOVB @HX2C00,@>8308            
2C36 DDEC @>8320               DEC @>8320
2C38 CALL GROM@>2C75        BL @G2C75
2C3B BS GROM@>2C2A          JEQ G2C2A
2C3D CALL GROM@>2EF9        BL @G2EF9
2C40 CZ @>830C                    CB @HX000A,@>830C  or MOVB @>830C,@>830C
2C42 BR GROM@>2C4F           JNE G2C4F
2C44 CZ @>8300                   CB @HX000A,@>8300
2C46 BR GROM@>2C4D         JNE G2C4D        (This seems odd, I think it could be BR GROM@>2016)
2C48 CALL GROM@>2C75       BL @G2C75
2C4B BR GROM@>2C65          JNE G2C65
2C4D BR GROM@>2016          JNE G2016
2C4F DST @>8314,@>8344     MOV @>8344,@>8314
2C52 CZ @>8300                    CB @HX000A,@>8300
2C54 BR GROM@>2C60          JNE G2C60
2C56 CALL GROM@>2C75        BL @G2C75
2C59 BS GROM@>2C2A           JEQ G2C2A
2C5B ST @>830E,@>8309       MOVB @>8309,@>830E
2C5E BS GROM@>2C65           JEQ G2C65
2C60 CALL GROM@>2C7A        BL @G2C7A
2C63 BS GROM@>2C2A           JEQ G2C2A
2C65 CALL GROM@>2EF9         BL @G2EF9

 

                                  HX0064 DATA >0064

                                  HX000A DATA >000A

 

 

Edited June 9 by senior_falcon

[+RXB]

10 hours ago, fabrice montupet said:

There is nowhere in my message where I were subjective. I tested for a while RXB and XB256 and made my choice. Please, accept that.
"ONLY CONSOLE without 32K ", an argument that you constantly put forward in loops and loops on AtariAge, yes it is technically interesting, an especially taste for challenge for you but, for present users, who in here really cares now, we are not anymore in the years 80 where any TI-99/4A expansion cost an arm and a leg. Now the 32 KB expansion costs nearly nothing. Like XB256, if ones want to use RXB, he must get too a FlashROM 99 or a FinalGROM99 that cost . So if ones can buy a such cartridge he can also buy a 32Kb expansion.  We see now that price is not a problem anymore. So I personally prefer using a language that offers many powerful graphic and sound features and great performances thanks to compilation,  benefiting in addition the 32KB memory space for more elaborated programs than the 16KB of the stock computer can offers.

Do whatever you want no one is stopping you.

I do not rag on anything you do and getting sick of you doing it to me.

 

[+RXB]

6 hours ago, TheBF said:

It would be the about same speed as byte-coded Forth. 

 

Byte code Forth is about 30% .. 40% slower than indirect threaded code Forth (Most TI-99 Forth systems)

ITC is 15% slower than direct threaded code Forth

DTC  is ~20% .. 30% slower than sub-routine threaded code Forth (Camel99 DTC Forth)

STC  is  ~2.5X slower than native code generating Forth compilers.

 

Well unlike Forth the OS is on the 16 bit bus that includes the GPL Interpreter.

Tursi emulated GROM without the delays and stated it was as fast as Forth.

[+TheBF]

5 hours ago, RXB said:

Well unlike Forth the OS is on the 16 bit bus that includes the GPL Interpreter.

Tursi emulated GROM without the delays and stated it was as fast as Forth.

Yes the 16 bit buss is a huge advantage on the 99 for sure. Very hard to top that.

Tursi's comparison to Forth is true as long as you limit the comparison to the indirect threaded Forth's like all the Forth's made for TI-99 in the past. 

 

I have a directed threaded compiler that is about 15% faster than Turbo Forth on most things I have tested. 

 

I have not made a sub-routine threaded Forth yet, but I want to make one to see what happens.

What this means is that Forth compiles real machine code, but each word is a 9900 sub-routine.

It should be about 2X faster than threaded Forths out there right now.  Downside is that programs will be much bigger.

The fix for that is to do a lot "inline" instructions rather than calling every command. We shall see if I can figure that out.

(This is how the commercial Forth compilers work since 1995 or so) 

 

I have a machine Forth system that generates native code which is 3X to 5X faster on some tests I have done. It is only a compiler, no interpreter.

 

And if you want to get really crazy, I made something called ASMFORTH. It is a Forth virtual machine with two stacks, Forth syntax for loops and branching but you can also use the registers. :-)

I made this one because @Reciprocating Bill made a sieve benchmark that blew everything out of the water including GCC and was 10X faster than threaded Forth.  

 

Here is what the code looks like. (It's really an assembler in a disguise)  

https://github.com/bfox9900/ASMFORTH/blob/main/demo/ASMFORTH-SIEVE.FTH

 

All that to say Forth is really just an idea about computing. How you implement it is a personal choice.

 

 

 

[Tursi]

6 hours ago, RXB said:

Well unlike Forth the OS is on the 16 bit bus that includes the GPL Interpreter.

Tursi emulated GROM without the delays and stated it was as fast as Forth.

I don't know how fast Forth is. I did run a console with no real GROMs and UberGROMs that were 2-3 times faster than real GROMs... and it didn't make much difference to performance of TI BASIC. (A simple FOR...NEXT for 300 counts is about 1 second in either case). I then analyzed the GPL interpreter and determined that the GPL interpreter doesn't hit the GROMs often enough for their performance to make a lot of difference.

 

Classic99 didn't emulate GROM speed in the early days, and it was pretty hard to see the difference. Except for copy loops the impact of GROM speed is pretty minimal.

 

Please don't propagate that through the threads. Rich just remembered a little wrong.

 

I do believe that with modern techniques we could re-write the GPL interpreter and make it fly. It does a lot of redundant work. But I guess nobody will believe me until it's done.  My thinking is ideas like the strangecart are better - I want to emulate the system on the cartridge and only talk to the console for actual I/O. Should be able to make XB fly that way.

 

Edited June 9 by Tursi

[+RXB]

My bad, I guess i just remembered that one statement without the context.

 

[fabrice montupet]

12 hours ago, RXB said:

Do whatever you want no one is stopping you.

I do not rag on anything you do and getting sick of you doing it to me.

 

I read all the threads only because I am very interested in all concerning our dear TI-99/4A and I participate when I like to, don't be paranoiac.  So catch your breath and don't be surprised if, maybe one day, I answer to a future message from you to share my point of view.

[+TheBF]

18 hours ago, senior_falcon said:

In principle, you could take a gpl program like TI BASIC or XB and do an instruction by instruction replacement of the gpl code with assembly instructions.

The following lines are from the TI BASIC interpreter, with assembly equivalents on the right.

Naturally, what I have written would need some changes. There are no labels. CALL GROM is stack oriented, so instead of BL you'd have to implement a stack for this, but I think you could use the same stack locations as regular BASIC.

I am certain that a total rewrite would be more efficient, but this approach has the advantage of not needing a lot of design work. It is based on code that is known to work, so you would not need to reinvent TI BASIC.

I wonder if one of the AI engines in the news recently could be trained to do this automatically.

 

(Edit) The beauty of converting TI BASIC as a first step is that it runs from VDP ram, which means that you have 32K of memory to use for the interpreter. So you you can just load and test without the complexities of a bank switched cartridge. This would be an excellent first step to see:

1 - if this is even possible

2 - if it is possible, what sort of speed increase could result.

 

2C2B DST @>8314,>0064       MOV @HX0064,@>8314
2C2F DST @>831E,>000A       MOV @HX000A,@>831E
2C33 ST @>8308,>2C            MOVB @HX2C00,@>8308            
2C36 DDEC @>8320               DEC @>8320
2C38 CALL GROM@>2C75        BL @G2C75
2C3B BS GROM@>2C2A          JEQ G2C2A
2C3D CALL GROM@>2EF9        BL @G2EF9
2C40 CZ @>830C                    CB @HX000A,@>830C  or MOVB @>830C,@>830C
2C42 BR GROM@>2C4F           JNE G2C4F
2C44 CZ @>8300                   CB @HX000A,@>8300
2C46 BR GROM@>2C4D         JNE G2C4D        (This seems odd, I think it could be BR GROM@>2016)
2C48 CALL GROM@>2C75       BL @G2C75
2C4B BR GROM@>2C65          JNE G2C65
2C4D BR GROM@>2016          JNE G2016
2C4F DST @>8314,@>8344     MOV @>8344,@>8314
2C52 CZ @>8300                    CB @HX000A,@>8300
2C54 BR GROM@>2C60          JNE G2C60
2C56 CALL GROM@>2C75        BL @G2C75
2C59 BS GROM@>2C2A           JEQ G2C2A
2C5B ST @>830E,@>8309       MOVB @>8309,@>830E
2C5E BS GROM@>2C65           JEQ G2C65
2C60 CALL GROM@>2C7A        BL @G2C7A
2C63 BS GROM@>2C2A           JEQ G2C2A
2C65 CALL GROM@>2EF9         BL @G2EF9

 

                                  HX0064 DATA >0064

                                  HX000A DATA >000A

 

 

This is wild. You show that there is a one to one correspondence here between GPL and 9900 Ass'y language. 

The only advantage with this kind of interpreter would therefore be portability. Program size is going to be the same or similar.

 

 

 

[+RXB]

2 hours ago, TheBF said:

This is wild. You show that there is a one to one correspondence here between GPL and 9900 Ass'y language. 

The only advantage with this kind of interpreter would therefore be portability. Program size is going to be the same or similar.

 

 

 

Yea that is exactly what I am doing in RXB. 

Taking GPL routines and turning them into Assembly.

The big difference is I am doing it so it can still run from Console only without need for expansion RAM, 

of course, this is way tougher than using Expansion RAM.

Example of a math routine:

Spoiler

763C 0203  LI   R3,>7B14      (>4001 3907 6020 435F)                                         
763E 7B14                                                             
7640 0204  LI   R4,ARG                                             
7642 835C                                                            
7644 CD33  MOV  *R3+,*R4+     >4001 INTO ARG                           
7646 CD33  MOV  *R3+,*R4+     >3907 INTO ARG2                             
7648 CD33  MOV  *R3+,*R4+     >6020 INTO ARG4                             
764A C513  MOV  *R3,*R4       >435F INTO ARG6                             
764C C30B  MOV  R11,R12                      (??)                             
764E 06A0  BL   @FADD =>0D80                                                  
7650 0D80                                                             
7652 C2CC  MOV  R12,R11                      (??)                             
7654 C28B  MOV  R11,R10        *                            
7656 06A0  BL   @>79F6                       (??)                             
7658 79F6                                    (y?)                             
765A 0203  LI   R3,>7B1C      (>3F3F 4213 4D17 433A)                                          
765C 7B1C                                                           
765E 0204  LI   R4,ARG                                              
7660 835C                                                            
7662 CD33  MOV  *R3+,*R4+    >3F3F INTO ARG                            
7664 CD33  MOV  *R3+,*R4+    >4213 INTO ARG2                             
7666 CD33  MOV  *R3+,*R4+    >4D17 INTO ARG4                             
7668 C513  MOV  *R3,*R4      >433A INTO ARG6                             
766A 06A0  BL   @FMULT =>0E88                                                
766C 0E88                                                             
766E 04CC  CLR  R12                          (??)                             
7670 D320  MOVB @FAC,R12                   (? )                             
7672 834A                                    (?J)                             
7674 0760  ABS  @FAC                       (?`)                             
7676 834A                                    (?J)                             
7678 9820  CB   @FAC,@>7C9E   (>44)                             
767A 834A                                                              
767C 7C9E                                                              
767E 15D9  JGT  >7632                        (??)                             
7680 06A0  BL   @>7A26                       (??)                             
7682 7A26                                    (z&)                             
7684 06A0  BL   @>7028                       (??)                             
7686 7028                                    (p()                             
7688 D060  MOVB @FAC,R1                    (?`)                             
768A 834A                                    (?J)                             
768C 130B  JEQ  >76A4                        (??)                             
768E 0221  AI   R1,>BA00                     (?!)                             
7690 BA00                                    (??)                             
7692 1508  JGT  >76A4                        (??)                             
7694 0221  AI   R1,>5100                     (?!)                             
7696 5100                                    (Q?)                             
7698 0981  SRL  R1,8                         (??)                             
769A D821  MOVB @VAR0(R1),@R12LB            (?!)                             
769C 8300                                    (??)                             
769E 83F9                                    (??)                             
76A0 024C  ANDI R12,>FF03                    (?L)                             
76A2 FF03                                    (??)                             
76A4 06A0  BL   @SSUB                       (??)                             
76A6 0D74                                    (?t)                             
76A8 2320  COC  @>6058,12    (>0001)                            
76AA 6058                                                                
76AC 1609  JNE  >76C0                        (??)                             
76AE 0201  LI   R1,ARG                                             
76B0 835C                                                             
76B2 CC60  MOV  @>7B76,*R1+  (>4001 INTO ARG)                            
76B4 7B76                                                            
76B6 04F1  CLR  *R1+         >0000 INTO ARG2                             
76B8 04F1  CLR  *R1+         >0000 INTO ARG4                             
76BA 04D1  CLR  *R1          >0000 INTO ARG6                            
76BC 06A0  BL   @>0D7C                       (??)                             
76BE 0D7C                                    (?|)                             
76C0 2320  COC  @>60C2,12    (>0002)                            
76C2 60C2                                                             
76C4 1601  JNE  >76C8                        (??)                             
76C6 054C  INV  R12                          (?L)                             
76C8 C80C  MOV  R12,@TOPSTK                   (??)                             
76CA 8310                                    (??)                             
76CC 0203  LI   R3,FAC                                            
76CE 834A                                                            
76D0 0204  LI   R4,ARG                                               
76D2 835C                                                          
76D4 0205  LI   R5,LINUM                                              
76D6 8312                                                             
76D8 CD13  MOV  *R3,*R4+     FAC INTO ARG                            
76DA CD73  MOV  *R3+,*R5+    FAC INTO *>8312                             
76DC CD13  MOV  *R3,*R4+     FAC2 INTO ARG2                            
76DE CD73  MOV  *R3+,*R5+    FAC2 INTO *>8312                           
76E0 CD13  MOV  *R3,*R4+     FAC4 INTO ARG4                           
76E2 CD73  MOV  *R3+,*R5+    FAC4 INTO *>8312                             
76E4 C513  MOV  *R3,*R4      FAC6 INTO ARG6                             
76E6 C553  MOV  *R3,*R5      FAC6 INTO *>8312                             
76E8 06A0  BL   @FMULT =>0E88                                                
76EA 0E88                                                            
76EC 06A0  BL   @>7A9E                       (??)                             
76EE 7A9E                                    (z?)                             
76F0 7BEC  SB   @>0203(R12),@LINUM(R15)      ({?)                             
76F2 0203                                    (??)                             
76F4 8312                                    (??)                             
76F6 0204  LI   R4,ARG                                             
76F8 835C                                                                
76FA CD33  MOV  *R3+,*R4+                    (?3)                             
76FC CD33  MOV  *R3+,*R4+                    (?3)                             
76FE CD33  MOV  *R3+,*R4+                    (?3)                             
7700 C513  MOV  *R3,*R4                      (??)                             
7702 06A0  BL   @FMULT =>0E88                                                
7704 0E88                                                            
7706 0560  INV  @TOPSTK                       (?`)                             
7708 8310                                    (??)                             
770A 1102  JLT  >7710                        (??)                             
770C 0520  NEG  @FAC         NEGATE 1st WORD                            
770E 834A                                                              
7710 0460  B    @>74A4                       (?`)                             
7712 74A4                          

 

[senior_falcon]

3 hours ago, TheBF said:

This is wild. You show that there is a one to one correspondence here between GPL and 9900 Ass'y language. 

The only advantage with this kind of interpreter would therefore be portability. Program size is going to be the same or similar.

Actually, GPL is considerably more compact if you don't count the interpreter. In the example above, the gpl instructions take 58 bytes and the assembly instructions take 94.

I deliberately chose a section of code that was easy to convert to assembly. Most of the gpl instructions could be converted directly to assembly, but there are some more complex instructions such as IO and a strange one called FMT, which I have never used.

From Intern:

Op-Code: >08
 Description: FMT several operands
Description: Special output command for the screen. The FMT Interpreter is independent of the GPL Interpreter. ( See ROM-Listing >04DE through >05A1 )

 

So the task would require a good understanding of GPL. I think a clever programmer could write something that did the conversion automatically.

 

 

[+RXB]

3 hours ago, senior_falcon said:

Actually, GPL is considerably more compact if you don't count the interpreter. In the example above, the gpl instructions take 58 bytes and the assembly instructions take 94.

I deliberately chose a section of code that was easy to convert to assembly. Most of the gpl instructions could be converted directly to assembly, but there are some more complex instructions such as IO and a strange one called FMT, which I have never used.

From Intern:

Op-Code: >08
 Description: FMT several operands
Description: Special output command for the screen. The FMT Interpreter is independent of the GPL Interpreter. ( See ROM-Listing >04DE through >05A1 )

 

So the task would require a good understanding of GPL. I think a clever programmer could write something that did the conversion automatically.

 

 

I started a GPL conversion project at one time into pure assembly.

It ended when it appeared that I was not up to that level of conversion.

Which is why I was hopeful someone would make a device like strange cart to do that instead.

[speccery]

I've worked a little on optimising Basic execution on the StrangeCart, and I've been thinking about token formats for Basic. This message is going to be a bit technical, hopefully it makes sense. 

 

The tokenizer in the TI BASIC is a bit weird. Consider this line:

10 ABC=123

The TI BASIC tokenizer - and my tokenizer by default - create this, a screenshot from js99er.net VDP memory:

There is the line number table at >37C9, which has a single entry: Line number >000A (10 decimal) and the pointer to the line, >37CE.

In there we have (everything in hex):

37CE: 41 42 43 (ABC)
37D1: BE (token for assignment = )
37D2: C8 03 31 32 33 (Unquoted string, length 3, contents 123)

Thus at >37CE we find the the string ABC, in ASCII. Before it, the byte at >37CD is >0A which is the length of the tokenized line. The pointer in line number table never points to the length byte, it points to the first actual character.  

 

Anyway, the thing is that the variable name ABC is presented just like that, ABC, while the number 123 is tokenized as unquoted string, which conveniently includes the length byte. As I've been focused on performance, the small issue with ABC being stored just like that is that since there is no string length, the interpreter needs to count the length every time so that it can search the symbol table with that length. On the other hand, the constant 123 is stored as a string with length. 

From a performance point of view, the interpreter could run faster if the variable name length was precomputed, i.e. if it was stored as an unquoted string. I already implemented this as an optional feature, and it does improve performance if the variable names are a bit longer.

 

For the constant 123, it would be better if the numeric constants would be stored with their own token, and then stored in binary format not requiring any run time conversions. For example if there was a token for 16-bit integers, 123 could be encoded with that token followed by two bytes. This could then be interpreted in fixed time, very fast, without all the checks normally needed when converting from ASCII to a binary number. In a simple scenario all numbers could be handled with two tokens: a token for 16 bit numbers, and another token for floating point format constants to handle all non-integers and numbers not fitting in to 16 bits.

 

For variable references, it's time consuming and complex to have to search for symbol table all the time.  I'm thinking about creating a new token for variable references, let's call it VAR, and have a separate table which would contain the name, and a runtime pointer to the variable entry in the runtime symbol table. That would mean that the name "ABC" would be copied into a variable name table, let's say as entry 0 since it's the first variable in the program. In the tokenized program line there would be the token VAR, followed by an 8-bit index into the variable name table. This way all references to ABC would become two bytes VAR >00, and the program size would become smaller if ABC was used a lot (ABC uses 3 bytes, VAR+index two bytes). The variable name table would need to contain the length of 3, the string ABC, and a pointer to the runtime symbol table.

 

In this setup the variable name table would become an integral part of a Basic program, as important as the tokenized lines. However, it would be possible to convert it back to normal TI Basic format for saving. Also listing would be simple,

 

When a program is run, the symbol table is cleared at start. [The symbol table in the StrangeCart Basic contains all variable values, their dimensions if they are arrays, their type (floating point or string) etc.]

With this new token format the pointers in the variable name table would also need to be set to zero on start. As VAR 0 is encountered for the first time, the variable would be created in the runtime symbol table normally, the same way variables are created as they are encountered during interpretation. Once that's done, the address of the variable in the symbol table would be stored into this new variable name table. The net result would be that variables would never have to be searched, instead they could be directly referenced with the pointers in the variable name table. 

 

Sorry if this was a bit confusing, there are quite a few tables involved, but the benefit of this type of arrangement is that all variable references could be done in fixed time, regardless of program size. The program could still be listed normally. When saving, a simple conversion would have to be done to get back to TI BASIC format. The interpreter would not need to worry about variable names during runtime.

 

If you got this far you might wonder why not store the addresses of variables directly into the token stream. This could be done, but it would expand the size of the tokenized code quite a lot. It also might cause complications when editing the code - removing lines or adding new ones.

The other observation one might have is that what happens if a program has more than 256 variable names, since that's the maximum that a single byte after VAR token could reference. I think it rarely happens - if ever with TI Basic programs. This could be mitigated for example so that there would be an escape into two bytes after VAR token. A simple way would be to store indices 0-127 as a single byte. Having the most significant bit set would mean there would be another index byte, thus creating 15-bit index values.

[+RXB]

I have been working with GPL the core of TI Basic and XB for way over 20 years now.

I believe the biggest problem for TI Basic and XB is Floating Point math has to be converted back and forth from Integer constantly.

An example is ROW=7 and COL=21 are both saved in the program as Floating-Point format, and when you do a DISPLAY AT(ROW,COL):A$

First the Floating-Point values of ROW and COL have to fetched and converted to Integer before being used.

This is also a problem for just ROW=ROW+16 too!

ROW is fetched and converted to Integer both times than 16 is added to it.

This really slows down the execution in a loop.

Why I think integer math added would really speed up just about everything in TI Basic and XB.

The second problem is all Variable names and Strings are stored in slower VDP RAM.