Jump to content
Bones-69

RXB - Rich Extended Basic

Recommended Posts

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.

  • Like 2

Share this post


Link to post
Share on other sites
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.

  • Like 1

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites
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

 

Share this post


Link to post
Share on other sites

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. 

 

 

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

 

Share this post


Link to post
Share on other sites
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.

  • Like 1

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

 

  • Like 3

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...