Reciprocating Bill Posted June 1, 2022 Share Posted June 1, 2022 (edited) 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 June 1, 2022 by Reciprocating Bill added "from a cartridge" 3 Quote Link to comment Share on other sites More sharing options...
GDMike Posted June 1, 2022 Share Posted June 1, 2022 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. Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted June 1, 2022 Share Posted June 1, 2022 (edited) 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 June 1, 2022 by senior_falcon 1 Quote Link to comment Share on other sites More sharing options...
+TheBF Posted June 1, 2022 Share Posted June 1, 2022 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. 1 1 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted June 2, 2022 Share Posted June 2, 2022 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. 1 Quote Link to comment Share on other sites More sharing options...
Reciprocating Bill Posted June 2, 2022 Share Posted June 2, 2022 (edited) 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 June 2, 2022 by Reciprocating Bill 1 Quote Link to comment Share on other sites More sharing options...
RXB Posted July 22, 2022 Share Posted July 22, 2022 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. 2 Quote Link to comment Share on other sites More sharing options...
RXB Posted September 3, 2022 Share Posted September 3, 2022 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. 3 Quote Link to comment Share on other sites More sharing options...
+TheBF Posted September 4, 2022 Share Posted September 4, 2022 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. 3 1 Quote Link to comment Share on other sites More sharing options...
RXB Posted November 21, 2022 Share Posted November 21, 2022 On 5/31/2022 at 1:46 PM, TheBF said: It should be noted that I have no idea what this stupid AtariAge does not allow me to post a new post but instead keep forcing this over and over on me? Quote Link to comment Share on other sites More sharing options...
RXB Posted November 21, 2022 Share Posted November 21, 2022 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. 3 Quote Link to comment Share on other sites More sharing options...
+TheBF Posted November 21, 2022 Share Posted November 21, 2022 What does the third parameter do? (255) 1 Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted November 21, 2022 Share Posted November 21, 2022 3 hours ago, TheBF said: What does the third parameter do? (255) It dictates how many characters to jam into the fourth parameter (X$ in @RXB’s example program). ...lee 1 2 Quote Link to comment Share on other sites More sharing options...
RXB Posted November 22, 2022 Share Posted November 22, 2022 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. 2 1 Quote Link to comment Share on other sites More sharing options...
apersson850 Posted December 7, 2022 Share Posted December 7, 2022 (edited) Is VGET incrementing both row and colum simultaneously, thus collecting characters diagonally across the screen? Why would you want to do that? Edited December 7, 2022 by apersson850 1 Quote Link to comment Share on other sites More sharing options...
+TheBF Posted December 7, 2022 Share Posted December 7, 2022 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. Quote Link to comment Share on other sites More sharing options...
Willsy Posted December 7, 2022 Share Posted December 7, 2022 I think the VGET parameters are just row, column, and number of repeats, like HCHAR & VCHAR. Quote Link to comment Share on other sites More sharing options...
apersson850 Posted December 7, 2022 Share Posted December 7, 2022 I looked at the BASIC equivalent (or it's supposed to be) code, where both row and column are incremented between each character read. Quote Link to comment Share on other sites More sharing options...
RXB Posted December 10, 2022 Share Posted December 10, 2022 RXB 2022G is very close to release this week. This is a demo of RXB 2022 G using CALL ROLL and CALL SCROLL routines written in Assembly for speed. 4 Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted December 18, 2022 Share Posted December 18, 2022 (edited) Okay. I'm getting this in Classic99 QI399.058b, RXB 2022C. I understand now, from the posts below, that it must have been an error in the previous version. Edited December 20, 2022 by sometimes99er Quote Link to comment Share on other sites More sharing options...
DavidC Posted December 18, 2022 Share Posted December 18, 2022 (edited) On 5/17/2022 at 1:24 PM, RXB said: No you are correct the RXBC.bin I use in on desktop and I copied the temp one I was working on instead. Edited December 18, 2022 by DavidC Quote Link to comment Share on other sites More sharing options...
DavidC Posted December 18, 2022 Share Posted December 18, 2022 On 5/17/2022 at 1:49 PM, RXB said: RXB 2022D.zip 31.23 MB · 44 downloads Quote Link to comment Share on other sites More sharing options...
RXB Posted December 20, 2022 Share Posted December 20, 2022 Almost done to release RXB 2022G and here is a demo video 2022-12-19 22-59-14.mkv 4 Quote Link to comment Share on other sites More sharing options...
RXB Posted December 21, 2022 Share Posted December 21, 2022 RXB 2022G DEMO EXAMPLES More demo examples shown 4 Quote Link to comment Share on other sites More sharing options...
RXB Posted December 24, 2022 Share Posted December 24, 2022 RELEASE OF RXB 2022G RXB 2022G.zip 5 9 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.