RXB - Rich Extended Basic

[RXB]

4 hours ago, MikeV said:

What is the latest?

Really time consuming to look for bugs!

Requires to think what stupid thing could be done that will crash RXB.

And example was when a oddball thing done in TI Basic caused an error in RXB, both were entirely outside what was allowed by either but complained were not same.

I can run almost all TI Basic programs as long as EA support is not needed. This was one of those exceptions.

That has been my main focus lately, looking for bugs.

[MikeV]

20 hours ago, RXB said:

Really time consuming to look for bugs!

Requires to think what stupid thing could be done that will crash RXB.

And example was when a oddball thing done in TI Basic caused an error in RXB, both were entirely outside what was allowed by either but complained were not same.

I can run almost all TI Basic programs as long as EA support is not needed. This was one of those exceptions.

That has been my main focus lately, looking for bugs.

I am certain we are going to like the results! Thanks for updating.

[RXB]

Talking to Senior Falcon about CALL INIT in XB and EA I decided to run a test:

100 OPEN #1:"CLOCK"
110 INPUT #1:A$,B$,C$
120 PRINT A$,B$,C$
130 FOR L=1 TO 10000
140 CALL INIT
150 NEXT L
160 INPUT #1:A$,B$,C$
170 PRINT A$,B$,C$

Ran this on RXB and got 15.43 as a result.

Ran this on XB and got 16.06 as a result.

Should be a way to look at EA CALL LOAD("DSK#.FILE") and speed it up some in RXB as TI Basic EA support CALL LOAD is faster.

Need to take a look at EA support and see differences.

[+hloberg]

On 6/30/2020 at 12:22 PM, RXB said:

Talking to Senior Falcon about CALL INIT in XB and EA I decided to run a test:

100 OPEN #1:"CLOCK"
110 INPUT #1:A$,B$,C$
120 PRINT A$,B$,C$
130 FOR L=1 TO 10000
140 CALL INIT
150 NEXT L
160 INPUT #1:A$,B$,C$
170 PRINT A$,B$,C$

Ran this on RXB and got 15.43 as a result.

Ran this on XB and got 16.06 as a result.

Should be a way to look at EA CALL LOAD("DSK#.FILE") and speed it up some in RXB as TI Basic EA support CALL LOAD is faster.

Need to take a look at EA support and see differences.

just for fun I ran your above program on MYARC BASIC XBII. the time was 2.00

 

[senior_falcon]

Rich, your results cannot be correct. I ran this test (only looping 1000 times) and got:

RXB   1:55 or 115 seconds. x10=1150 seconds or 19:10 

TIXB  2:18 or 138 seconds. x10= 1380 seconds or 23:00

RXB moves >04F4 bytes in CALL INIT; TIXB moves >0600 bytes

>600/>4F4 is 1536/1268 which equals 1.211. Although there is some overhead with the call and the loop, most of the time is spent moving bytes out of grom and into ram.

I got 1150 seconds for RXB * 1.211 = 1392 seconds expected for XB which jibes well with what I observed.

You got 943 seconds in RXB *1.211 =1142 seconds expected for XB (19.02) yet you claim it was 16.06, or 966 seconds.

Your ratio is 966/943 = 1.024 which is clearly impossible when you are moving 1.211 times as many bytes using the same routine. 

 

 

[RXB]

1 hour ago, senior_falcon said:

Rich, your results cannot be correct. I ran this test (only looping 1000 times) and got:

RXB   1:55 or 115 seconds. x10=1150 seconds or 19:10 

TIXB  2:18 or 138 seconds. x10= 1380 seconds or 23:00

RXB moves >04F4 bytes in CALL INIT; TIXB moves >0600 bytes

>600/>4F4 is 1536/1268 which equals 1.211. Although there is some overhead with the call and the loop, most of the time is spent moving bytes out of grom and into ram.

I got 1150 seconds for RXB * 1.211 = 1392 seconds expected for XB which jibes well with what I observed.

You got 943 seconds in RXB *1.211 =1142 seconds expected for XB (19.02) yet you claim it was 16.06, or 966 seconds.

Your ratio is 966/943 = 1.024 which is clearly impossible when you are moving 1.211 times as many bytes using the same routine. 

 

 

I ran 2 Classic99 apps at same time it may have been a app share problem in Windows 10 as it also did a update in background. 

I started the XB one first then 1 second later the RXB one.

Now there is a difference in XB uses 4 separate GPL MOVE commands to move GROM to RAM and RXB does just one big move.

The reason is a weird way XB does it just looks stupid, also it moves a ton of ZERO's from GROM to RAM along with more then is used by the USER.

Your timing makes sense, but it was obvious how XB does it would be slower as it is loading more and uses many more commands to do same thing.

[RXB]

14 hours ago, hloberg said:

just for fun I ran your above program on MYARC BASIC XBII. the time was 2.00

 

Yea XBII is fast, but when you try to take XB programs and put them into XBII it is like pulling teeth.

You can take 99% of TI Basic Programs and run them in RXB with no changes.

Same goes for XB programs in RXB, not true of XBII.

[+hloberg]

1 hour ago, RXB said:

Yea XBII is fast, but when you try to take XB programs and put them into XBII it is like pulling teeth.

You can take 99% of TI Basic Programs and run them in RXB with no changes.

Same goes for XB programs in RXB, not true of XBII.

very true. if there is any peek or poke, more likely it won't run on myxbii. I was just wondering why the huge difference in speed. what is myxbii doing that XB isn't? or is it just a head fake that myxbii only runs once then cheeks if needs to run thereafter.

 

[RXB]

4 hours ago, hloberg said:

very true. if there is any peek or poke, more likely it won't run on myxbii. I was just wondering why the huge difference in speed. what is myxbii doing that XB isn't? or is it just a head fake that myxbii only runs once then cheeks if needs to run thereafter.

 

MYXBII is mostly Assembly with a little GPL, XB and RXB and others like XB 2.8 are mostly GPL with some Assembly.

Needless to say also why XBII is so buggy and not backwards compatible with XB.

[senior_falcon]

13 hours ago, RXB said:

MYXBII is mostly Assembly with a little GPL, XB and RXB and others like XB 2.8 are mostly GPL with some Assembly.

Needless to say also why XBII is so buggy and not backwards compatible with XB.

If XBII is buggy and not backwards compatible it is either due to poor programming or perhaps not enough RAM to fully implement all the features of XB. With enough RAM, time, and motivation, there is no reason a skilled programmer could not make an all assembly version of BASIC or XB that was 100 percent compatible.

[RXB]

2 hours ago, senior_falcon said:

If XBII is buggy and not backwards compatible it is either due to poor programming or perhaps not enough RAM to fully implement all the features of XB. With enough RAM, time, and motivation, there is no reason a skilled programmer could not make an all assembly version of BASIC or XB that was 100 percent compatible.

Very True the issue is mostly the scads of RAM needed compared to normal XB as GPL is more compact than FORTH for memory saving commands.

Many commands in GPL are single byte commands like MOVE that with 7 bytes can move any memory of any type to any type of any size. 

i.e. VDP, RAM, ROM, GRAM, and GROM to any VDP, RAM, GRAM

Even though they still made MVUP and MVDWN for XB ROMs.

I do not think it would be ever possible to be 100% compatible only due to so many quirks XB has and the number of 8K ROMs needed.

[+hloberg]

9 minutes ago, RXB said:

Very True the issue is mostly the scads of RAM needed compared to normal XB as GPL is more compact than FORTH for memory saving commands.

Many commands in GPL are single byte commands like MOVE that with 7 bytes can move any memory of any type to any type of any size. 

i.e. VDP, RAM, ROM, GRAM, and GROM to any VDP, RAM, GRAM

Even though they still made MVUP and MVDWN for XB ROMs.

I do not think it would be ever possible to be 100% compatible only due to so many quirks XB has and the number of 8K ROMs needed.

the issue that makes MYXBII incompatible is the upgrades to the graphics capabilities. lots of stuff moved around so that all the capabilities of the VDP is used. so to just enable the TI99 do what it should been able to do from the start, access all the VDP capabilities, makes it myarcII incompatible. Same could be said of the 99/8 which myarcII is loosely based on.

as for bugs in myarcII, really haven't run into any yet other than no peek or poke can be used.

 

[RXB]

Got CALL SAMS to do any memory in SAMS memory entire 32K can be changed!

You can now change 4K in any memory space in TI99/4A equipped with SAMS up to 32 MEGABYTES!

 

Example: CALL SAMS(A,32767) ! will put PAGE 23767 at >A000 

               CALL SAMS(C,23566) ! will put PAGE 23566 at >C000

               CALL SAMS(2,11111,3,11119) ! will put PAGE 11111 at >2000 and will put PAGE 11119 at >3000

 

Currently working on why I can not use pages above 32767????

(Seems to be a problem with XML CFI as it wants to use Negative numbers to get above 32767.)

 

[+Lee Stewart]

1 hour ago, RXB said:

Currently working on why I can not use pages above 32767????

 

I must be missing something. The highest 4 KiB page in 32 MiB SAMS is 8191. Are you anticipating the possibility of 256 MiB SAMS?

 

...lee

[RXB]

14 hours ago, Lee Stewart said:

 

I must be missing something. The highest 4 KiB page in 32 MiB SAMS is 8191. Are you anticipating the possibility of 256 MiB SAMS?

 

...lee

Hmm ok 1 Meg SAMS has 256 pages of 4K, so that would mean 256 pages times 32 banks for total number of pages of 4K in 32 Meg SAMS so correct 8192.

 

Thus 256 pages of 4K and we have 256 banks so 256x256 is 65535 pages of 4K in a 256 Meg SAMS.

 

So I still need 65535 for a 256 Meg SAMS in future. Good news is I can do 8192 right now with ease.

Edited September 9, 2020 by RXB

[RXB]

Just ran this program to test RXB version of CALL INIT vs XB version of CALL INIT

100 OPEN #1:"CLOCK"
110 INPUT #1:A$,B$,C$
120 PRINT A$,B$,C$
130 FOR L=1 TO 10000
140 CALL INIT
150 NEXT L
160 INPUT #1:A$,B$,C$
170 PRINT A$,B$,C$

Results:

RXB      =   17 minutes 42 seconds

XB 2.7   =  17 minutes 50 seconds

XB        =   20 minutes 6 seconds

TI Basic =  28 minutes 7 seconds

 

I was disappointed in only shaving off 8 seconds from XB 2.7 but I did smoke XB and TI Basic.

Then again I only did 10,000 passes to test it.

 

[GDMike]

Maybe ? rxb needs an update?

[wierd_w]

(redact about fonts)

 

Of course, I click on this thing, and atariage shows me a many weeks old stale post as the "last viewed" instead of the "current message".

 

A real annoying feature that. Wish I could turn it off.  Carry on.

Edited September 10, 2020 by wierd_w

[RXB]

24 minutes ago, GDMike said:

Maybe ? rxb needs an update?

Working on RXB 2020 so yea.

Finally got CALL SAMS to work and SIZE command to work with up to 256 Meg SAMS if someone ever comes out with one.

Or if Classic99 ever goes from 32 Meg SAMS to 256 Meg SAMS then RXB 2020 can handles those pages and banks.

[GDMike]

13 minutes ago, RXB said:

Rxb 2020, yeah

Does rxb have the te2 library of words in it? Or an advanced speech engine? Like, importing wav files, etc..Just wondering

Edited September 10, 2020 by GDMike

[wierd_w]

Importing wav files would allow the speech module to be used in some very clever ways.  Since it can be programmed with pitch control, it could be used "cleverly" as a sampler. (a really tinny sounding one, but still.)

 

The speech synth would think it is saying "hello world", but would really be playing some instrument patches in place of the phonemes.

[GDMike]

I mean, just thinking out loud, maybe use some Sam's for wav storage..or and use Sam's space for font space, users already have the power to load file from file, but RXB doesn't have the luxury of add-ons I guess, not yet. Or should it? Or even make a tihtml converter web page reader add on, or a tipi communicator.

Or create a new front end for rxb, and give it a shell appearance, where calls like color or screen can be permanent while it's running like command com structure that doesn't revert while active. Or add a sd card interface to it's cartridge port for saving/loading quick files, but with tipi that's useless probably.

Rxb needs a 4gb Sam's card. Lol

 

Does rxb use call Link as to load assy language programs? I wonder if it could be possible to do  call Link(forth code) somehow? Wow

Edited September 10, 2020 by GDMike

[RXB]

1 hour ago, GDMike said:

Does rxb have the te2 library of words in it? Or an advanced speech engine? Like, importing wav files, etc..Just wondering

Sorry just XB ones. If I get a FinalGrom version I plan to add a bunch of stuff like that to it.

[RXB]

1 hour ago, GDMike said:

I mean, just thinking out loud, maybe use some Sam's for wav storage..or and use Sam's space for font space, users already have the power to load file from file, but RXB doesn't have the luxury of add-ons I guess, not yet. Or should it? Or even make a tihtml converter web page reader add on, or a tipi communicator.

Or create a new front end for rxb, and give it a shell appearance, where calls like color or screen can be permanent while it's running like command com structure that doesn't revert while active. Or add a sd card interface to it's cartridge port for saving/loading quick files, but with tipi that's useless probably.

Rxb needs a 4gb Sam's card. Lol

 

Does rxb use call Link as to load assy language programs? I wonder if it could be possible to do  call Link(forth code) somehow? Wow

 

[RXB]

       

          SAMS           subprogram                            PAGE  S1
          -------------------------------------------------------------
 
          Format         CALL SAMS(address-boundry,page-number[,...])
 
                         CALL SAMS(address-boundry,numeric-variable
                         [,...])
                           
                         CALL SAMS(command [,...])

 
          Description
 
          The SAMS command will only work with a SAMS memory card.
          The address-boundry is a value in Hexadecimal denoted by
          2 is >2000 or 3 is >3000 or A is >A000 or D is >D000  
          SAMS turns on the read/write lines of SAMS mapper registers          
          stores the value into the mapper register chosen. Less wasted 
          pages results in more memory available.Page numbers can be 
          from -32767 to 32767 so it is hard to explain this easy. 
           See -1 would be >FFFF hexidecimal 256 Meg SAMS. Pages 0 to 
          255 would be a 1 Meg SAMS, Pages 256 to 511 would be a 2 Meg 
          SAMS, so on up to page 32512 to 32767 would be 32 Meg SAMS.
           Pages -32767 to -1 would be above 32K Meg SAMS so RXB 2020
          handles 64 Meg SAMS, but not tested above 32 Meg yet.
           A addtional new feature in 2020 RXB SAMS is use of upper 24K
          memory can now be switched, but of course care must be taken
          or will crash XB by removing the program running SAMS from 
          upper 24K. 
           The order of changing 4K pages does not matter thus a
          CALL SAMS(A,55,3,34) example is put 4K page 55 SAMS Memory 
          at >A000 and 4K page 34 at >3000

          Original SAMS commands like ON, OFF, MAP or PASS still work.
          "ON" turns on Mapper Registers. 
          "OFF" turns off Mapper Registers.
          "MAP" turns on Map Mode so pages can be changed.
          "PASS" default mode making the SAMS just like a normal 32K.          

          Example is mixing commands:
          100 CALL SAMS("ON","MAP",2,237,"OFF")
          This turns on SAMS read/write Registers, turns on MAP mode, 
          sets 4K page with page 237 than turns off SAMS read/write 
          Registers. 
         

 

 

  SIZE           command or subprogram                 PAGE  S5
          -------------------------------------------------------------
 
          Format         SIZE
 
                         CALL SIZE
 
          Description
 
          See EXTENDED BASIC MANUAL PAGE 169 for more data. 
          RXB has added many more features to SIZE. RXB shows the
          size and memory address of VDP, RAM and SAMS. Very uselful
          for XB or Assembly progammers. EXAMPLE:
 
          >SIZE                          
             11682 Bytes of Stack Free 
             24364 Bytes of Program    
             8192  Bytes of Assembly   
             * PAGE NUMBER = LOCATION *
             2     Page = >2000 - >2FFF
             3     Page = >3000 - >3FFF
             10    Page = >A000 - >AFFF                                                                                                                                                                    
             11    Page = >B000 - >BFFF
             12    Page = >C000 - >CFFF
             13    Page = >D000 - >DFFF
             14    Page = >E000 - >EFFF
             15    Page = >F000 - >FFFF
             * MEMORY UNUSED and FREE *
             >3739 VDP Free Address    
             >0958 VDP STACK Address   
             >FF6B Program Free Address
             >A040 Program End Address 
             >2000 RAM Free Address    
             >4000 RAM End Address 
 
            This shows normal XB values but also includes more
           useful things like Assembly free and SAMS pages 
           used and where these pages are. Lastly it shows
           VDP STACK location, First free VDP address, XB RAM
           First free address and End address. Lastly first
           free Assembly address and End address used.

 

 

 

 

New documentation including new commands.

Edited September 10, 2020 by RXB