RXB - Rich Extended Basic

[RXB]

RXB 2024 B CALL HEX DOCUMENTS

 

 

 

[RXB]

RXB 2024C CALL SAMS

 

 

[MikeV]

 

 

 

 

 

 

A copy of the RXB 2024 Reference Guide with navigation links (clickable) for quick referencing.

RXB2024.pdf

[MikeV]

On 3/9/2024 at 6:58 PM, RXB said:

RXB 2024C CALL SAMS

 

 

Hey Rich - saw your RXB SAMS video and the concept is great!

 

As part of RXB SAMS would it be possible to include variable length string support with CALL MOVES to populate arrays, etc? It would provide a significant conservation of conventional memory and be very fast. As I am uncertain of the correct terminology I attach a hex-view below:

This file was made with CALL MOVES AND PSAVE. As the strings are variable length I used a "FIXED" length of 16 bytes as the baseline maximum. As can be seen when the string length is less than the defined length the last byte value is the string length (same as on disk files when the VARIABLE length attribute is declared). These are indicated in squares. This does not occur with fixed length strings that are fully occupied, e.g. a CALL MOVES("$R",64,...) to move a 64 digit CHAR CODE. I do not know if it is RXB that provides the string length byte or the TI operating system?

 

To use the strings I had to convert them as follows:

4990 FOR J=1 TO 20
5000 CALL MOVES("R$",16,Y2,V$):: Q=POS(V$,CHR$(0),1):: V$=SEG$(V$,1,Q-2):: Y2=Y2+16

 

This works, but is slow...

 

An RXB conversion routine would be so much quicker! Imagine all the DATA statements, ARRAYS, etc. loaded with PLOAD and stored in SAMS? (But very fast.) A real memory saver. Is it possible that the RXB CALL MOVES could have a "max string length" value vs only a fixed one, find the string length byte and render the variable string?

 

[RXB]

3 hours ago, MikeV said:

Hey Rich - saw your RXB SAMS video and the concept is great!

 

As part of RXB SAMS would it be possible to include variable length string support with CALL MOVES to populate arrays, etc? It would provide a significant conservation of conventional memory and be very fast. As I am uncertain of the correct terminology I attach a hex-view below:

This file was made with CALL MOVES AND PSAVE. As the strings are variable length I used a "FIXED" length of 16 bytes as the baseline maximum. As can be seen when the string length is less than the defined length the last byte value is the string length (same as on disk files when the VARIABLE length attribute is declared). These are indicated in squares. This does not occur with fixed length strings that are fully occupied, e.g. a CALL MOVES("$R",64,...) to move a 64 digit CHAR CODE. I do not know if it is RXB that provides the string length byte or the TI operating system?

 

To use the strings I had to convert them as follows:

4990 FOR J=1 TO 20
5000 CALL MOVES("R$",16,Y2,V$):: Q=POS(V$,CHR$(0),1):: V$=SEG$(V$,1,Q-2):: Y2=Y2+16

 

This works, but is slow...

 

An RXB conversion routine would be so much quicker! Imagine all the DATA statements, ARRAYS, etc. loaded with PLOAD and stored in SAMS? (But very fast.) A real memory saver. Is it possible that the RXB CALL MOVES could have a "max string length" value vs only a fixed one, find the string length byte and render the variable string?

 

CALL MOVES sets the string length of the string when it makes a new string as it calls a XB GPL ROM routine to make the string with that length.

If you want a set length that is not defined by RXB as normally you would have to pad the length yourself in your program.

Example you can pad each string with a space or some other character in front or at end of that string.

I have done this by using CALL MOVES to make a set of padded string before I put stuff in them:

FOR X=1 TO 20 :: Y$=RPT$(".",10) :: CALL MOVES("$$",20,Y$,T$(X)) :: NEXT X

This would make 20 strings 10 characters long with periods in T$(array)

 

By the way currently working on RXB SAMS that only works with RAM and removes most VDP access slower routines.

Down the line all strings and VDP routines not graphics will be in SAMS RAM.

[MikeV]

18 hours ago, RXB said:

By the way currently working on RXB SAMS that only works with RAM and removes most VDP access slower routines.

Down the line all strings and VDP routines not graphics will be in SAMS RAM.

That will be great!