RXB - Rich Extended Basic

[senior_falcon]

6 hours ago, RXB said:

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.

 

I don't understand your fixation on CALL INIT. True, RXB is 12% faster when doing a CALL INIT. I suppose whether this qualifies as "smoking" XB is a matter of semantics. 

In any case, CALL INIT is normally only done once in an XB program. In RXB it would take .106 seconds. In XB it would take .1206 seconds. The difference is 1/50 second. I am quite sure my gin addled reflexes could not detect the difference. 

[RXB]

53 minutes ago, senior_falcon said:

I don't understand your fixation on CALL INIT. True, RXB is 12% faster when doing a CALL INIT. I suppose whether this qualifies as "smoking" XB is a matter of semantics. 

In any case, CALL INIT is normally only done once in an XB program. In RXB it would take .106 seconds. In XB it would take .1206 seconds. The difference is 1/50 second. I am quite sure my gin addled reflexes could not detect the difference. 

Do I go attack you on any new improvement you make? What is it with you raining on my parade? This seems to be a habit with you!

Edited September 11, 2020 by RXB
missing text

[senior_falcon]

Sorry - that was meant as an observation, not an attack. Nonetheless, your preoccupation with CALL INIT (mentioned in several other posts as well) seems odd. Especially when there are other improvements in RXB that (at least in my opinion) would be much more interesting to focus on. For example, your GCHAR can combine multiple GCHARs in a single statement.  Every CALL GCHAR that is eliminated saves about 1/50 of a second. Some programs use GCHAR a lot and it would be interesting to do a test  showing how much of a speed increase this could lead to. As I remember, you have combined KSCAN with JOYST, and a speed test of that change might be of use. And a bunch of others....

[RXB]

3 hours ago, senior_falcon said:

Sorry - that was meant as an observation, not an attack. Nonetheless, your preoccupation with CALL INIT (mentioned in several other posts as well) seems odd. Especially when there are other improvements in RXB that (at least in my opinion) would be much more interesting to focus on. For example, your GCHAR can combine multiple GCHARs in a single statement.  Every CALL GCHAR that is eliminated saves about 1/50 of a second. Some programs use GCHAR a lot and it would be interesting to do a test  showing how much of a speed increase this could lead to. As I remember, you have combined KSCAN with JOYST, and a speed test of that change might be of use. And a bunch of others....

Thanks. Guess my interest in CALL INIT is based on what ever I can do to improve Assembly support.

[GDMike]

I guess I'll put my treehouse back behind my back.... 

 

[RXB]

Ok I have given up on SIZE for SAMS cards.

Just like Floppy drives or Hard Drives or size of you SD Drives or USB drives the USER knows and making a program to figure out SAMS was just a waste of GPL space and time.

RXB does show what SAMS pages are being used and where everything is in memory.

          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. SAMS size is
           not reported just like Foppy size or hard drive is'nt!

 

[RXB]

Ok new RXB 2020 Memory Manager Routines built right into RXB

 

 

[oddemann]

1 Clean Logo
2 Logo and "anim"

3 Logo, name and "anim"

4 Full logo

5 TI color Full logo

Just having fun!

Edited September 29, 2020 by oddemann

[oddemann]

Black and White

[RXB]

Interesting! You mean LOGO built in graphics into RXB similar to SuperXB had something like it.

[oddemann]

35 minutes ago, RXB said:

Interesting! You mean LOGO built in graphics into RXB similar to SuperXB had something like it.

I am just playing around, if you find it OK. Your free to use  If you have a wish, I can see if I can make it happen... Logo wise ? hehehe

[RXB]

RXB 2020 DOCUMENTS ARE DONE, HERE IS PREVIEW:

 

 

RXBDOCS.pdf

[senior_falcon]

Per Omega's suggestion I have moved this over to the RXB thread.

 

8 hours ago, senior_falcon said:

That fails for two reasons.

1-It is no better than XB. The asterisks are erased when PRINT forces the scroll.

2-Even if it worked it cannot be compiled.

1-What asterisks? There was no mention of them? Just replace character 31 with 42 in that case.

Asterisks were in the original 3 line program and I assumed you had included them in your suggestion:

10  CALL HCHAR(24,1,31,2,24,3,32,28,24,31,31,2) 

20 PRINT 

30 GOTO 30

This actually shows nothing because the characters (31 and 32) are invisible.

XB PRINT does not ERASE anything it just scrolls the screen up the prints a blank line of 32 characters space character.

XB PRINT does erase the bottom line as you would know if you had run my 3 line program.

Before you fire off a reply try out this program in XB and see if you still think XB PRINT does not erase anything:

 

10 FOR I=65 TO 75

20 CALL HCHAR(24,1,I,32)

30 PRINT

40 NEXT I

 

[RXB]

10 hours ago, senior_falcon said:

Per Omega's suggestion I have moved this over to the RXB thread.

 

1-What asterisks? There was no mention of them? Just replace character 31 with 42 in that case.

Asterisks were in the original 3 line program and I assumed you had included them in your suggestion:

10  CALL HCHAR(24,1,31,2,24,3,32,28,24,31,31,2) 

20 PRINT 

30 GOTO 30

This actually shows nothing because the characters (31 and 32) are invisible.

XB PRINT does not ERASE anything it just scrolls the screen up the prints a blank line of 32 characters space character.

XB PRINT does erase the bottom line as you would know if you had run my 3 line program.

Before you fire off a reply try out this program in XB and see if you still think XB PRINT does not erase anything:

 

10 FOR I=65 TO 75

20 CALL HCHAR(24,1,I,32)

30 PRINT

40 NEXT I

 

 

RXB solution:

10 FOR I=65 TO 75

30 CALL HCHAR(24,1,I,32)

40 CALL HGET(24,1,32,A$)

50 PRINT

60 CALL HPUT(24,1,A$)

70 NEXT I

 

Seems to fix the issue when you have the proper tools.

 

How come you do not just switch 20 and 30 so PRINT comes first in your example?

(Yes PRINT does erase the line in XB, but as it is faster then Basic seems it is a trade off.)

 

Edited October 22, 2020 by RXB

[senior_falcon]

Does NOT seem to fix the issue!!! It is obvious that you never bothered testing your "fix".

This whole discussion is totally unnecessary. Let's go back to the beginning. The thread was called "TI BASIC/TI EXTENDED BASIC Games that are worth to be compiled..."

From the title the average reader would naturally come to the conclusion that the original poster, tmop69, was compiling BASIC and XB games.

In post #100 of that thread, tmop reports: "So, I've found another game in the 0.1% percent...  It's Skier 99 (in attachment). It works fine in TI BASIC, but not in RXB and of course also after the compilation. It simply does not update the screen with the updated graphics, but only draws the bottom line. I was not able the find what is the offending code, so help is welcome!"

In post #102 I described the problem and provided two possible solutions, one requiring XB256 and one for standard XB. Tmop69 wisely chose the fix that uses standard XB, was able to compile the program, and found that it worked correctly. Mission accomplished, time to move on to the next cow, as they say on the farm. 

Five days later you come up with a "fix" that doesn't fix anything and that uses RXB, which cannot be compiled. Please explain how this addresses the OP's problem?

 

(Edit) Turns out that your line 60 should be 60 CALL HPUT(23,1,A$). Then it works properly, but of course it still cannot be compiled so it is a useless fix.

Edited October 22, 2020 by senior_falcon

[HOME AUTOMATION]

...

 

I might be willing to pay admission to see this show.

[GDMike]

1 minute ago, HOME AUTOMATION said:

...

 

I might be willing to pay admission to see this show.

Nothing to see folks, stop rubber necking and let's move on.

[GDMike]

It won't delete

Edited October 22, 2020 by GDMike
Sorry, wrong video..I tried deleting and insertion of my basic code

[RXB]

5 hours ago, senior_falcon said:

Does NOT seem to fix the issue!!! It is obvious that you never bothered testing your "fix".

This whole discussion is totally unnecessary. Let's go back to the beginning. The thread was called "TI BASIC/TI EXTENDED BASIC Games that are worth to be compiled..."

From the title the average reader would naturally come to the conclusion that the original poster, tmop69, was compiling BASIC and XB games.

In post #100 of that thread, tmop reports: "So, I've found another game in the 0.1% percent...  It's Skier 99 (in attachment). It works fine in TI BASIC, but not in RXB and of course also after the compilation. It simply does not update the screen with the updated graphics, but only draws the bottom line. I was not able the find what is the offending code, so help is welcome!"

In post #102 I described the problem and provided two possible solutions, one requiring XB256 and one for standard XB. Tmop69 wisely chose the fix that uses standard XB, was able to compile the program, and found that it worked correctly. Mission accomplished, time to move on to the next cow, as they say on the farm. 

Five days later you come up with a "fix" that doesn't fix anything and that uses RXB, which cannot be compiled. Please explain how this addresses the OP's problem?

 

(Edit) Turns out that your line 60 should be 60 CALL HPUT(23,1,A$). Then it works properly, but of course it still cannot be compiled so it is a useless fix.

I did run your test and you never replied to why you do not put PRINT before CALL HCHAR in demo as this would make much more sense.

And yea you do not support RXB so yea can not be compiled we have already both said this over and over.

 

By the way this same exact problem was discussed on this thread for RXB vs TI Basic way back in 2015 and my solution was the same one in RXB but of course XB has no solution.

So factually I knew about this before you, hell in my note book for RXB fixes the sticky for it is right here in front of me.

[RXB]

5 hours ago, HOME AUTOMATION said:

...

 

I might be willing to pay admission to see this show.

Go back in RXB thread you will see this problem way back in 2015 and I already addressed it back then....

 

[RXB]

4 hours ago, GDMike said:

 

So this is like Facebook and you troll peoples threads?

You do know there is not other reason for this right?

 

As for the issue I already addressed this problem on this thread back in 2015 if you want to check.

Edited October 22, 2020 by RXB

[senior_falcon]

"you never replied to why you do not put PRINT before CALL HCHAR in demo as this would make much more sense"

The problem was that XB was behaving differently when running an already written BASIC program. Doing what you suggest might work better in that program and it might not. I neither know nor care. I found a way to make PRINT behave the same in that program in both XB and BASIC and saw no reason for further effort on my part.

"my solution was the same one in RXB but of course XB has no solution."

Actually XB does have a solution which tmop69 put to good use.

 

Speaking of not responding, I notice my query: "you come up with a "fix" that doesn't fix anything and that uses RXB, which cannot be compiled. Please explain how this addresses the OP's problem?" has yet to be answered.

 

Much as I like Martha and the Vanellas, that particular post does not further the discussion and so was not appropriate.

[RXB]

3 hours ago, senior_falcon said:

"you never replied to why you do not put PRINT before CALL HCHAR in demo as this would make much more sense"

The problem was that XB was behaving differently when running an already written BASIC program. Doing what you suggest might work better in that program and it might not. I neither know nor care. I found a way to make PRINT behave the same in that program in both XB and BASIC and saw no reason for further effort on my part.

"my solution was the same one in RXB but of course XB has no solution."

Actually XB does have a solution which tmop69 put to good use.

 

Speaking of not responding, I notice my query: "you come up with a "fix" that doesn't fix anything and that uses RXB, which cannot be compiled. Please explain how this addresses the OP's problem?" has yet to be answered.

 

Much as I like Martha and the Vanellas, that particular post does not further the discussion and so was not appropriate.

QUOTE: "I neither know nor care." then why are you even here saying this? Are you upset I even post anything as you are always on the attack.

 

LOL wow again you ignored that in this thread I already addressed this issue in 2015, some reason you ignored that fact?

 

Also I was only 11 in 1965 and at time was only listening to Country Western Music at that time so Martha and the Vanellas I know little or nothing about.

Currently I listen to New Age, Alternative, pop and current new music (even some new Country.). No classic stations by the way.

Edited October 22, 2020 by RXB

[senior_falcon]

This whole s**t storm got started when tmop69 was trying to compile a BASIC program. He reported that it didn't work. I found a way to deal with the problem and he then was able to make it work. Case closed. Five days later you come up with a solution that doesn't work for two reasons. I point that out and now I am on the attack? You replied and then I moved the subject to the RXB thread per Omega's wise suggestion. In post #1089 above you post a solution that doesn't work. I point this out and once again I am on the attack. I explain that the reason I did not try putting PRINT before CALL HCHAR is because the problem had already been solved to the OP's satisfaction, but somehow that answer does not satisfy you. As far as addressing the issue in 2015 (which I wasn't able to find) a more timely post could have set us on the right path quicker, although if it involves RXB then it wouldn't have addressed the OP's problem.  (Edit) - found it. It was the first post for 2016. As suspected, it uses RXB and so would not have helped the OP.

 

The code below shows your RXB solution using HGET and HPUT and my solution using normal XB  with a semicolon in the print statement. The XB version runs 2.5x faster than the RXB version. Please don't take this as another attack - it's just a statement of facts.

10 FOR I=33 TO 127
30 CALL HCHAR(24,1,I,32)
40 CALL HGET(24,1,32,A$)
50 PRINT
60 CALL HPUT(23,1,A$)
70 NEXT I


5 A$=RPT$(" ",28)
6 PRINT A$;
10 FOR I=33 TO 127
20 CALL HCHAR(24,1,I,32)
30 PRINT A$;
40 NEXT I

 

 

Edited October 23, 2020 by senior_falcon

[RXB]

RXB ENDLESS SIZE OF RXB PROGRAMS.

Imagine making a 4 meg XB program with both assembly and endless lines.

(Well endless to the point of SAMS or Hard Drive space.)