Jump to content
IGNORED

RXB - Rich Extended Basic


Bones-69

Recommended Posts

In keeping with the retro tenor of this conversation, I ran the original seven Rugg/Feldman benchmarks (Kilobaud Magazine) on a standard console, with and without memory expansion. I used TI Extended BASIC v. 110 from a cartridge. 

 

https://en.wikipedia.org/wiki/Rugg/Feldman_benchmarks

 

For the first three benchmarks I increased the loop from 1000 to 2000 to make timing easier. The remaining four were run as published.

 

The results were:

 

Benchmark           With Expansion        Without Expansion

1)                         7.9”                         8.3”

2)                         22.1                        24.3

3)                         59.1                        60.3

4)                         29.3                        30.5

5)                         31.7                        33.3

6)                         60.0                        63.1

7)                         90.7                        93.9

 

The expanded console ran these small benchmarks between 2% and 8% more quickly than the unexpanded console, with an average speed advantage of about 5%. That lies at the border of "barely perceptible" (although the differences when expressed as percentages are slightly greater than I expected). 

Edited by Reciprocating Bill
added "from a cartridge"
  • Like 3
Link to comment
Share on other sites

My old boss used to say, if the computer is slow I'm sure we can find a slow person to put on it. as he was talking about our telecom department at the time.  he would always expect me to give him a hardware status and what complaints we have as he arrived to work. Lol.

Link to comment
Share on other sites

15 hours ago, Reciprocating Bill said:

In keeping with the retro tenor of this conversation, I ran the original seven Rugg/Feldman benchmarks (Kilobaud Magazine) on a standard console, with and without memory expansion. I used TI Extended BASIC v. 110 from a cartridge. 

https://en.wikipedia.org/wiki/Rugg/Feldman_benchmarks

For the first three benchmarks I increased the loop from 1000 to 2000 to make timing easier. The remaining four were run as published.

The results were:

Benchmark           With Expansion        Without Expansion

1)                         7.9”                         8.3”

2)                         22.1                        24.3

3)                         59.1                        60.3

4)                         29.3                        30.5

5)                         31.7                        33.3

6)                         60.0                        63.1

7)                         90.7                        93.9

The expanded console ran these small benchmarks between 2% and 8% more quickly than the unexpanded console, with an average speed advantage of about 5%. That lies at the border of "barely perceptible" (although the differences when expressed as percentages are slightly greater than I expected). 

In the past, I remember seeing roughly 1 second faster per 60 seconds.

These benchmarks really do not reflect how programming is usually done. i.e. in the benchmarks numbers are usually single digits, variables are single characters, etc. I would be interested in seeing the performance of something like this running in VDP vs CPU ram:

10 RAD=2.5

20 AREA=RAD*RAD*3.14159

30 GOTO 10

 

Edited by senior_falcon
  • Like 1
Link to comment
Share on other sites

So I did this in XB with PEB and without PEB. Timed with second hand they are clearly different by a second.

 

10 FOR INDEX = 1 TO 1000
20 RAD=2.5
30 AREA=RAD*RAD*3.14159
40 NEXT INDEX 
 

21 seconds from VDP

20 seconds from RAM

 

So we are back to ~5% again.

 

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

After thinking about this I realized that my memory was faulty. Back in the day I would not have been able to compare XB performance using VDP only vs XB with 32K. The reason is that my 32K has always been soldered in, so disabling was not an option. (I did not know about CALL LOAD(-31860,0,0,0,0) trick to turn memory off.)

What I did test was 32K on the 16 bit bus and with the wait states restored to give the same performance as the 8 bit bus. I found a disappointing gain in performance - 1% or less. I just checked this with Win994a, which lets you turn off the memory expansion or use 8 bit or 16 bit memory. I saw about 3% increase going from XB in  VDP to XB in RAM, and way less than 1% going from 8 bit bus to 16 bit bus.

  • Like 1
Link to comment
Share on other sites

One last datapoint on the issue of XB, expansion RAM and speed.

 

To test the impact of expansion RAM of a more complex program I ran a maze generation program. This I had adapted from Commodore BASIC to TI Extended BASIC in preparation for writing my assembly version, and uses the same algorithm that is displayed in the maze portion of the demo posted in the "Something a little different" thread (The BASIC maze has smaller dimensions, however). I generated three mazes with expansion on - in this instance on my 16-bit console, and three mazes with expansion off on a stock console with no memory expansion. The runs on each platform didn't vary at all in execution time (a concern because a different maze is generated each run). Note that because the RAM expansion used is 16-bit with no wait states, this would actually tend to amplify any difference arising from the use of RAM versus VRAM.

 

However, the average of the runs in RAM was 46.08 seconds, while the average of runs in VRAM was 47.42 seconds.  

Edited by Reciprocating Bill
  • Like 1
Link to comment
Share on other sites

  • 1 month later...

Been working on a real pain of a routine CALL VAR(numberic-variable,address)

What it does is you put in the variable like say X or TEMP or YODA and it returns the RAM or VDP address of that 8 byte Floating Point value.

So how is this useful?

 

Game plan involved SAMS RAM as the idea is to increase variables and not suck it out of 24K memory.

Here is the issue.

Any variable in XB like say you type X=9 in VDP whether in console with or 32K memory here is what happens:

 

>0001 >0000 >37D7 >FE00 >58 in VDP RAM

Length Word of variable in this case >0001 for X 

Pointer to next variable in list but in this case only one so is >0000

Pointer to variable symbols in this case >37D7 points to >58 this is the X symbol

Pointer to Floating Point address of 8 byte value >4009000000000000 this is in 9 in Floating Point format at address >FFE0 in RAM

Finally >58 is X symbol you typed in X=9 in XB

 

But wait there is the >4009000000000000 at either VDP RAM or RAM also.

This means a single X=9 takes 9 bytes of VDP RAM and 8 bytes of CPU or VDP RAM.

That is 17 bytes of memory for a single 9 in X?

Yes sounds insane to me too! 

You are screwed, unless we have CALL VAR(X,address)

 

So what if you want something like say DIM X(8000) well that is impossible as XB could only manage X(3000) and leave 10 bytes for your program!

Well back to X=9 you have that address so everything can be in X but you can use SAMS  8 bytes to save as many as you want by stepping 8 bytes each time.

This would make it possible to have a DIM X(40000) using SAMS memory instead, of course you have to switch SAMS pages but again look at the advantage.

 

Oh also CALL VAR(string-variable,address) also shows string address so looking at SAMS again for more ideas...

 

P.S. Think of using less variables as 2 variables in program can be used over and over without using program space for more.

       Instead of 17 bytes, just 8 each time.

 

 

  • Like 2
Link to comment
Share on other sites

  • 1 month later...

I am rewriting CALL CHAR(character#,pattern) into assembly to speed up VDP access:

 

Here is the program I used:

100 CALL CLEAR
110 OPEN #1:"CLOCK"
120 INPUT #1:A$,B$,C$
130 FOR C=1 TO 10000
140 CALL CHAR(32,"FF00FF00FF00FF00")
150 NEXT C
160 INPUT #1:D$,E$,F$
170 PRINT A$,D$:B$,E$,C$,F$
180 END

TIMES:

RXB          4 minutes 36 seconds

XB 2.9     15 minutes 16 seconds

TI Basic   24 minutes   8 seconds

XB 110    45 minutes 44 seconds

 

Now the reason why these are so slow is the pattern must be checked for 0 to F values before the pattern can be used.

Thus in GPL vs Assembly checking these is apparent.

  • Like 3
Link to comment
Share on other sites

4 hours ago, RXB said:

Now the reason why these are so slow is the pattern must be checked for 0 to F values before the pattern can be used.

Thus in GPL vs Assembly checking these is apparent.

Where I come from 3X to 10X improvement is real good. :) 

  • Like 3
  • Thanks 1
Link to comment
Share on other sites

  • 2 months later...

OMG finally I can make a post!!!!!

 

Just finished new CALL VGET(row,column,length,string-variable) written in assembly instead of GPL like XB or previous RXB versions.

Running a 10,000 loop for timing I get:

RXB 2020E 3 hours 17 minutes 5 seconds

RXB 2022D 2 hours 26 minutes 24 seconds

RXB 2022G 14 minutes 12 seconds (Assembly is just so fast!)

 

This is the program:

Spoiler

100 CALL CLEAR
110 OPEN #1:"CLOCK"
120 INPUT #1:A$,B$,C$
130 FOR C=1 TO 10000
140 CALL VGET(1,1,255,X$)
150 NEXT C
160 INPUT #1:D$,E$,F$
170 PRINT A$,D$:B$,E$,C$,F$
180 END

Of course, it just loads 255 spaces into X$ but tested with stuff on screen gets same exact results.

  • Like 3
Link to comment
Share on other sites

On 11/21/2022 at 6:51 AM, TheBF said:

What does the third parameter do? (255)

 

CALL VGET works like a loop using CALL GCHAR

100 R=10:: C=11 :: X$=""
110 FOR L=1 TO 8
120 CALL GCHAR(R,C,G)
130 R=R+1 :: C=C+1 :: X$=X$&CHR$(G)
140 NEXT L

Now X$ has 8 characters fetched off screen in a string instead of only getting 1 at a time off screen like GCHAR does.

So VGET is faster than the above loop and much easier to deal with.

CALL VGET(10,11,8,X$) is one single line that does exactly what XB program above does.

  • Like 2
  • Thanks 1
Link to comment
Share on other sites

  • 2 weeks later...
5 hours ago, apersson850 said:

Is VGET incrementing both row and colum simultaneously, thus collecting characters diagonally across the screen? Why would you want to do that?

I am going to guess that the x,y coordinates are used to compute the VDP address of the cursor and x,y is the way to specify this in BASIC. 

 

Link to comment
Share on other sites

  • 2 weeks later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

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...