A worse programmers questions

[Sid1968]

14 minutes ago, RXB said:

Working on it for years.

Good News! Would it be possible to rewrite the mathematic functions for addition and multiplicaton maybe with the help and knowlege of Lee and Assemblerpro`s of this forum? Sometimes a view on the problem of someone from outside is usefull.

Edited September 23, 2019 by Sid1968

[RXB]

21 minutes ago, Sid1968 said:

Good News! Would it be possible to rewrite the mathematic functions for addition and multiplicaton maybe with the help and knowlege of Lee and Assemblerpro`s of this forum? Sometimes a view on the problem of someone from outside is usefull.

Most of the math slowdown is in XB are in the XB ROMs, and I have repeatably asked for help to rewrite the ROMs for over 2 years, not a single reply yet.

I am a GPL programmer but not that good at Assembly.

 

XB ROM 1 use >6010:

*************************************************************
* XML table number 7 for Extended Basic - must have         *
*     it's origin at >6010                                  *
*************************************************************
*           0      1      2      3      4      5     6
       DATA COMPCG,GETSTG,MEMCHG,CNSSEL,PARSEG,CONTG,EXECG
*           7      8    9     A    B    C      D
       DATA VPUSHG,VPOP,PGMCH,SYMB,SMBB,ASSGNV,FBSYMB
*             E     F
       DATA SPEED,CRNSEL
*************************************************************
* XML table number 8 for Extended Basic - must have         *
*     it's origin at >6030                                  *
*************************************************************
*           0   1      2    3      4  5     6      7
       DATA CIF,CONTIN,RTNG,SCROLL,IO,GREAD,GWRITE,DELREP
*           8    9    A      B      C      D      E
       DATA MVDN,MVUP,VGWITE,GVWITE,GREAD1,GWITE1,GDTECT
*           F
       DATA PSCAN
 

XB ROM 2 use >6030:

 

*************************************************************
* XML table number 7 for Extended Basic - must have         *
*     it's origin at >6010                                  *
*************************************************************
*           0      1      2      3      4      5     6
       DATA COMPCG,GETSTG,MEMCHG,CNSSEL,PARSEG,CONTG,EXECG
*           7      8    9     A    B    C      D
       DATA VPUSHG,VPOP,PGMCH,SYMB,SMBB,ASSGNV,FBSYMB
*             E     F
       DATA SPEED,CRNSEL
*************************************************************
* XML table number 8 for Extended Basic - must have         *
*     it's origin at >6030                                  *
*************************************************************
*           0   1      2    3      4  5     6      7
       DATA CIF,CONTIN,RTNG,SCROLL,IO,GREAD,GWRITE,DELREP
*           8    9    A      B      C      D      E
       DATA MVDN,MVUP,VGWITE,GVWITE,GREAD1,GWITE1,GDTECT
*           F
       DATA PSCAN
 

One of the most interesting routines is SPEED and CIF that is much different then TI Basic in ROM 0.

[+Lee Stewart]

1 hour ago, RXB said:

As stated by Tursi no this is not true GPL does not execute at different speeds in a Cart or GROM in console.

As I have explained on another posts and other times, the reason some routines in TI Basic are faster then TI Extended Basic (or RXB or SuperXB or XB2.7) is that 

Extended Basic has DISPLAY and DISPLAY AT(row,col)  added to the routines of PRINT, thus as more options are checked this slows the XB version of PRINT.

It is like your boat the more weight you add the slower you can row it.

 

Seeing as how there is NO DISPLAY AT in TI Basic it has a hell of a shorter list to scan for in total and each command has many fewer options that it needs to look for...

For 20 years I have written GPL for TI Basic and XB (RXB) along with other GPL projects like ET at Sea where I created the first usable GPL code and released it.

(Thanks to Tursi and some others for refining that code to be much more usable we see today.)

 

A perfect example is RND in TI Basic and XB and RXB. I put the simple less complicated RND from TI Basic into RXB.

Extended Basic had this huge complicated RND generator that used Floating Point up to 9 digits so RND in XB was just so freaking slow.

XB suffers from much of this as a problem, but then it also has sprites and other features that make TI Basic look so primitive and bad.

 

I did not say that GPL (accessed from GROM) was the problem. I said I did not know whether GROM speed added to the problem and @Tursi cleared that up. What I said was that the different ROM speeds were likely the culprit. Also, I might add that different logic in those ROMs could further exacerbate the speed difference.

 

The discussion about PRINT speeds is totally irrelevant to the speed problem in this problem because there is no printing inside the loop. There is only one print statement outside the loop and that can not possibly account any significant portion of the 14-second speed difference.

 

...lee

[Sid1968]

4 minutes ago, RXB said:

Most of the math slowdown is in XB are in the XB ROMs, and I have repeatably asked for help to rewrite the ROMs for over 2 years, not a single reply yet.

I am a GPL programmer but not that good at Assembly.

That answer is a sign of great, Richard that impresses me!

 

Like in real life, ask an "anonymous mass" for help and nobody feels adressed. Ask some people directly should lead to success.

So i want to ask you Lee, Tursi and Asmusr to offer your help to Richard.

 

RXB is in my opinion a very important language, not only for beginners, that deserves improvement.

 

 

Kind Regards

Sid1968

 

 

PS.: Help of other forummates is certainly welcome, too.

 

[Sid1968]

5 minutes ago, Lee Stewart said:

 

I did not say that GPL (accessed from GROM) was the problem. I said I did not know whether GROM speed added to the problem and @Tursi cleared that up. What I said was that the different ROM speeds were likely the culprit. Also, I might add that different logic in those ROMs could further exacerbate the speed difference.

 

The discussion about PRINT speeds is totally irrelevant to the speed problem in this problem because there is no printing inside the loop. There is only one print statement outside the loop and that can not possibly account any significant portion of the 14-second speed difference.

 

...lee

You said it right!

Would be kind if you would offer Richard your help, Lee. ?

Edited September 23, 2019 by Sid1968

[Sid1968]

21 hours ago, Tursi said:

Nah, all GROMs in the system run at the speed of the slowest GROM on the bus.

 

Would be kind if you would offer Richard your help too, Tursi.

Edited September 23, 2019 by Sid1968

[Sid1968]

5 hours ago, Asmusr said:

I once made this, as a joke. It's written in 100% assembly, and it's actually scrolling the entire screen. I think the version on the video is waiting for vertical sync, so it's 'only' scrolling the screen 60 times per second. My point is that this test is really about how fast the screen can be scrolled. Counting the variable from 1 to 1000 is insignificant compared to the time it takes to scroll the screen in any language. Printing a number takes longer than counting, but it's only displaying 4 characters (max) compared to moving 768 when it scrolls.  

 

Would be kind if you would offer Richard your help too, Asmusr. ?

Edited September 23, 2019 by Sid1968

[Tursi]

11 hours ago, Sid1968 said:

I guess nobody would say that assembler would solve that problems slower than the others. Maybe another misunderstandig of my bad english.

My statement was meant to say that they are both assembly language, but one is in 16-bit ROM and one is in 8-bit ROM. The 16-bit ROM code executes faster due to no wait states.

 

I don't know if that's why.

 

Reading the ROMs showed that is not so

 

Edited September 23, 2019 by Tursi

[Sid1968]

Just now, Tursi said:

My statement was meant to say that they are both assembly language, but one is in 16-bit ROM and one is in 8-bit ROM. The 16-bit ROM code executes faster due to no wait states.

 

I don't know if that's why.

 

Tursi, i only quoted you to get your attention. Please read Richards posting above. I ask you to help.

[Asmusr]

3 minutes ago, Sid1968 said:

 

Would be kind if you would offer Richard your help too, Asmusr. ?

What's good would it do to rewrite the ROMs? You cannot replace them without soldering.

What makes you think that the math routines could be improved and that it would make any difference? Maybe the bottleneck is somewhere else?

If you want faster programs written in BASIC you should look at the XB Games Developer Package (did I mention that before? )

[Tursi]

1 hour ago, RXB said:

 

You show me in the XB ROMs where this interpreter is please?

What I see is routines to deal with a OS ROM that is designed for TI Basic and EA not XB.

Thus what I see is the XB ROMs deal with a different way to get results but must use different EQUATES to pull this off.

And proof is what you see in the EA manual using TI Basic vs XB.

Cool.. I never had a good look before. I think my confusion was that more of the parsing happens here in the ROM instead of in GPL like TI BASIC does. The linkage is a little more clear to me now.

 

And yeah, it does use the console ROM for math functions, so that theory of mine can be shredded.

 

[RXB]

9 minutes ago, Asmusr said:

What's good would it do to rewrite the ROMs? You cannot replace them without soldering.

What makes you think that the math routines could be improved and that it would make any difference? Maybe the bottleneck is somewhere else?

If you want faster programs written in BASIC you should look at the XB Games Developer Package (did I mention that before? )

Hmm MESS, Classic99 and other Emulators do not need soldering?

And many people have burned RXB carts so I do not see your problem with newer XB ROMs?

 

And the XB Games Developer Package is not XB in any sense easy to use, people need Assembly understanding to use it.

You can BS all you want on how easy it is to use but it does require understanding of Assembly or frustration just increases.

(I have seen many give up using it due to this simple fact.)

XB and Basic are true beginners languages and there are many more programs written in them then you will ever see in XB Games Developer Package.

Yes it is a good idea and I applaud your developments.  But quit ragging on something that you need to get programs for in order for your product to exist.

It is both kinda crazy and self defeating ragging on the one thing your product is based on in the first place. Baffling!

 

Continue to push XB256 it is a great product but not in any sense a beginners product as it requires an assembly learning process.

To steep of gradiante to call it a beginners package. 

Edited September 23, 2019 by RXB
spelling errors

[Tursi]

27 minutes ago, Sid1968 said:

So i want to ask you Lee, Tursi and Asmusr to offer your help to Richard.

I've already sat with Rich.

 

When people help me get through MY todo list, then I'll be able to help other projects again.

 

[Sid1968]

33 minutes ago, Asmusr said:

What's good would it do to rewrite the ROMs? You cannot replace them without soldering.

What makes you think that the math routines could be improved and that it would make any difference? Maybe the bottleneck is somewhere else?

If you want faster programs written in BASIC you should look at the XB Games Developer Package (did I mention that before? )

Where is the problem???

 

Look here... AmigaOS 3.1.4

Last year the Amiga got the new OS 3.1.4 with new roms, because the Amigascene developed it. Much off it happened in forum.

 

I think the TI-Community has very good programmers too, to rewrite the roms. Its only a matter of good will. So please buddies think positiv. ?

Edited September 23, 2019 by Sid1968

[Sid1968]

3 minutes ago, Tursi said:

I've already sat with Rich.

 

When people help me get through MY todo list, then I'll be able to help other projects again. 

 

Is his name Rich or Richard... Ups did i made a mistake calling him Richard?

 

If your todo list contains eating chocolate iam your man... but maybe i can help you in other ways too

[Tursi]

15 minutes ago, Asmusr said:

What's good would it do to rewrite the ROMs? You cannot replace them without soldering.

What makes you think that the math routines could be improved and that it would make any difference? Maybe the bottleneck is somewhere else?

If you want faster programs written in BASIC you should look at the XB Games Developer Package (did I mention that before? )

There is value for RXB, not so much for original Extended BASIC (though I guess it'd automatically help). RXB is a living piece of software, though.

 

[Tursi]

2 minutes ago, Sid1968 said:

If your todo list contains eating chocolate iam your man... but maybe i can help you in other ways too

You can always help me sort it.  http://harmlesslion.com/cgi-bin/walrusquery.cgi

 

[Sid1968]

2 minutes ago, Tursi said:

There is value for RXB, not so much for original Extended BASIC (though I guess it'd automatically help). RXB is a living piece of software, though.

 

Tursi and with your help you will be a part of TI-99/4A Computerhistory!!!

[Sid1968]

5 minutes ago, Tursi said:

You can always help me sort it.  http://harmlesslion.com/cgi-bin/walrusquery.cgi

 

I would add a line at first position: Rewriting ROMS.

If you would share this work with others the task would be smaller. You know the scene better than me. Would be a good idea if you ask others to help. ?

Edited September 23, 2019 by Sid1968

[Asmusr]

3 hours ago, RXB said:

But quit ragging on something that you need to get programs for in order for your product to exist.

It is both kinda crazy and self defeating ragging on the one thing your product is based on in the first place. Baffling!

Oh sure, I will stop ragging. Now I really want to help [irony].

[RXB]

5 hours ago, Sid1968 said:

Thank you Richard. Is there no way to fix the speedproblems in RXB?

Many of the "speedproblems" are actually same as in TI Basic, just badly desiged or lacking forethought.

 

RXB has been my attempt at fixing issues, thus instead of just putting one same character on screen RXB allows mulitple times to be used:

i.e. XB =

100 CALL HCHAR(row,col,char,repetition) :: CALL HCHAR(row,col,char,repetition) ! see you have to restart with :: CALL HCHAR again????

 

RXB =

100 CALL HCHAR(row,col,char,repetition,row,col,char,repetition) ! now this makes more sense as you just only have to always include repetition.

 

But you never need to do this for last use of HCHAR:

100 CALL HCHAR(row,col,char,repetition,row,col,char) ! see last one does not need repetition only previous ones require it.

 

Another example is DISPLAY AT(row,col) has some problems as it does not use column 1 and 2 and also 31 and 32, so only 28 characters per line.

So RXB has CALL HPUT(row,col,string or char or variable) of couse you can also continue CALL HPUT(row,col,variable,row,col,variable)

 

These do speed up XB as it takes less code to do same thing and spares the interpreter from going to find name of routines over and over.

 

[GDMike]

If I knew the"How's" I'd put a TB Forth Bios in place of the system ROMs. But just don't Know enuff yet. But I stay focused on learning TF. Takes time.

[Tursi]

17 minutes ago, GDMike said:

If I knew the"How's" I'd put a TB Forth Bios in place of the system ROMs. But just don't Know enuff yet. But I stay focused on learning TF. Takes time.

Unfortunately you lose a lot doing that.. without the GPL interpreter most cartridges won't work. Some programs also rely on the ROMs for routines and data. Even scanning the keyboard usually is done via the ROM routine. Of course if you ONLY want to run TurboForth, it could be done.

 

[GDMike]

I have another console just for that. Haha

 

[senior_falcon]

8 hours ago, RXB said:

 

If you use Classic99 try this tests:

 

10 A=RND

20 C=C+1

30 GOTO 10

 

Run this in TI Basic for 1 hour, then XB for 1 hour and then RXB for 1 hour.

You will find XB is the very slowest, TI Basic second and RXB just eats both for breakfast.

 

Incorrect. I ran each for 1 minute (you may have 3 hours to spare - I don't) The results:

TI XB         774

RXB         2990

TI BASIC  3329

 

TI BASIC is faster here, so RXB is only dining on a 1 course meal.