RXB - Rich Extended Basic

[+Lee Stewart]

...

Why are you even writing in XB if your goal is Assembly?

I mean talk about doing something totally unnecessary to end up someplace else.

Why not just write it in Assembly in the first place?

Or for that matter C that is 100% designed around that idea in the first place. ...

 

C'mon, Rich. The reason, obviously, is to get it to Assembly Language without having to go through the very difficult process of learning it!

 

...lee

[senior_falcon]

I have used ALL of the XB compilers and not a single one can you convert and compile with any speed, it is even slower than Assembly to do that as all the extra steps.

 

XB is good for what it is designed for which is quickly type in a program and test as you go with the interpreter.

 

Why are you even writing in XB if your goal is Assembly?

I mean talk about doing something totally unnecessary to end up someplace else.

Why not just write it in Assembly in the first place?

Or for that matter C that is 100% designed around that idea in the first place.

 

Also I am a GPL programmer and like it, so am I telling you to abandon what you like to do?

You can see how this would rub me the wrong way.

Which is why I asked for Assembly Language Programmers to help out.

I am not attempting to convert anyone to my thinking, but give me a break for my goals.

 

Am I poo pooing on yours?

No disrespect to RXB which is a wonderful package or to your skills as a GPL programmer. The problem I have is when you talk about getting a 3x to 16x speed increase by putting strings in RAM. This is wishful thinking. There is no way this change will give such a huge boost in performance. I like to fantasize that changing the spark plugs and air filter on my 1996 Saturn station wagon will make it possible to go 250 mph, but I'm pretty sure that would not actually be the case. The only way to get XB to perform that much faster would be to rewrite it entirely in assembly. Who's going to do it - not you, not me, not Rasmus, not anyone. And so we are stuck with a GPL based XB. So please, continue to fine tune RXB. 5% faster here and 10% faster there, along with all the extra features is worthwhile progress. Just lay off the claims for impossible speed increases.

[RXB]

No disrespect to RXB which is a wonderful package or to your skills as a GPL programmer. The problem I have is when you talk about getting a 3x to 16x speed increase by putting strings in RAM. This is wishful thinking. There is no way this change will give such a huge boost in performance. I like to fantasize that changing the spark plugs and air filter on my 1996 Saturn station wagon will make it possible to go 250 mph, but I'm pretty sure that would not actually be the case. The only way to get XB to perform that much faster would be to rewrite it entirely in assembly. Who's going to do it - not you, not me, not Rasmus, not anyone. And so we are stuck with a GPL based XB. So please, continue to fine tune RXB. 5% faster here and 10% faster there, along with all the extra features is worthwhile progress. Just lay off the claims for impossible speed increases.

Let me ask you a question:

 

Which is much faster VDP Stack or RAM Stack?

 

Another question is every time XB execute a statement in XB it puts that line into VDP ROLLOUT at >03C0 or >0820 for crunching the line of code or Temporary storage.

So if all of these VDP only routines are in RAM how much of a speed increase do you think this would be?

(Consider every single line of XB code is put in VDP instead of RAM.)

 

Saying conversion from VDP to RAM is only a 10% speed increase strikes me as pretty outlandish.

According to you VDP is only 10% slower than RAM?

Edited April 12, 2017 by RXB

[senior_falcon]

In the grand scheme of things there won't be that much difference. There is virtually no difference in XB speed when running totally from VDP on an unexpanded TI and when running with the program in 32K RAM. Look, I've been wrong many times so far in my life, and will be wrong many times in the future. And if you can somehow pull a rabbit out of your hat and make XB run 10x faster with this change then I will be the first to eat a large helping of crow. But the proof of any pudding is in the eating and so far the pickings are pretty slim.

[RXB]

In the grand scheme of things there won't be that much difference. There is virtually no difference in XB speed when running totally from VDP on an unexpanded TI and when running with the program in 32K RAM. Look, I've been wrong many times so far in my life, and will be wrong many times in the future. And if you can somehow pull a rabbit out of your hat and make XB run 10x faster with this change then I will be the first to eat a large helping of crow. But the proof of any pudding is in the eating and so far the pickings are pretty slim.

 

Ok just to explain the only difference in XB running from Console and 32K is Numeric Variables along with the XB Program are in upper 24K.

Ti did this so we would not have huge issue with speed of programs written for the TI running from 32K or Console, you could see a huge PR nightmare if you needed to change programs each time?

 

What I am going to do is dump VDP Stack (Every subroutine in XB gets pushed on the Stack in RAM or VDP stack depending on routine) and use only RAM Stack in SAMS.

Also VDP rollout area >03C0 and >0820 Crunch Buffer along with many pointers or temp buffers are all in VDP memory to be also moved to RAM in SAMS.

 

I mean if you take a look at RXB source code and XB ROM's you will see VDP Memory is used for a crazy amount of buffers and temp storage.

[senior_falcon]

Here's a simple example that will explain my skepticism. I decide to take my beloved black and silver 1984 Lotus Excelle bicycle on a cross country trip. (No carbon fiber in this baby - one of the students dubbed it "The Iron Horse") I can ride 15 miles per hour and the trip is 3000 miles. How long will the trip take?

3000 miles/15 mph=200 hours.

Let's say these old legs of mine get a little tired up in the mountains. I get a ride in a car for 100 miles going at 60mph. (4 times faster) How long will the trip take?

2900/15+100/60=195 hours.

Let's say I get sick of the whole thing at the 2000 mile mark. I get a ride in a car for 1000 miles going at 60 mph. (4 times faster) How long will the trip take?

2000/15+1000/60=150 hours

At the 2000 mile mark, let's say I encounter a friendly ET in a UFO that can warp time and space. It takes me the final 1000 miles instantaneously. How long will the trip take?

2000/15=133.3 hours

 

Now let's pretend my cross country trek is a program running in RXB. If 1/30 of the program is 4x faster the speed increase is only 2.5%. Even if you are running 1/3 the program 4x faster, the program as a whole still takes 75% of the time to finish. And in the UFO example it still takes 66.6% of the time. Those are the kind of numbers you are up against.

Edited April 13, 2017 by senior_falcon

[Asmusr]

I believe the main objective for adding SAMS support to BASIC should be to allow for (much) longer programs. Any speed improvement would just be an added benefit.

[RXB]

I believe the main objective for adding SAMS support to BASIC should be to allow for (much) longer programs. Any speed improvement would just be an added benefit.

Yes, but to do that the XB ROMs need to be changed to use SAMS instead of VDP for Strings and Stack, also temp storage areas normally in XB.

Also I should add I can in the future add in more XML Assembly routines for XB replacing slower GPL routines.

This is just a few in GROM 3 and XB ROMs using VDP address.

***********************************************************
*    VDP addresses
NLNADD EQU  >02E2             New LiNe ADDress
ENDSCR EQU  >02FE             END of SCReen address
LODFLG EQU  >0371             Auto-boot needed flag
START  EQU  >0372             Line to start execution at
SYMBOL EQU  >0376             Saved symbol table pointer
SPGMPT EQU  >0382             Saved PGMPTR for continue
SBUFLV EQU  >0384             Saved BUFLEV for contiue
SEXTRM EQU  >0386             Saved EXTRAM for continue
* SAVEVP EQU  >0388           Saved VSPRT for continue
* ERRLN  EQU  >038A           On-error line pointer
BUFSRT EQU  >038C             Edit recall start addr (VARW)
BUFEND EQU  >038E             Edit recall end addr (VARA)
TABSAV EQU  >0392             Saved main symbol table ponte
SLSUBP EQU  >0396             Saved LSUBP for continue
SFLAG  EQU  >0398             Saved on-warning/break bits
SSTEMP EQU  >039A             To save subprogram program ta
SSTMP2 EQU  >039C             Same as above. Used in SUBPRO
MRGPAB EQU  >039E             MERGEd temporary for pab ptr
*----------------------------------------------------------
* Added 6/8/81 for NOPSCAN feature
PSCFG  EQU  >03B7
*----------------------------------------------------------
* RXB PATCH CODE SWAP CONFLG & >35D7 FOR cONSOLE MENU FLAG
*    Flag 0:  99/4  console, 5/29/81
*         1:  99/4A console
CONFLG EQU  >03BB
*----------------------------------------------------------
* Temporary
NOTONE EQU  >0374             NO-TONE for SIZE in ACCEPT us
*                              in FLMGRS (4 bytes used)
SAVEVP EQU  >0388
ERRLN  EQU  >038A
ACCVRW EQU  >03AC             Temoporary used in ERRZZ, als
*                              used in FLMGRS
VALIDP EQU  >03B0             Use as two values passing fro
VALIDL EQU  >03B2             VALIDATE code to READL1
OLDTOP EQU  >03BC             Temporary used in ERRZZ, also
CRNBUF EQU  >0820             CRuNch BUFfer address
CRNEND EQU  >08BE             CRuNch buffer END
RECBUF EQU  >08C0             Edit RECall BUFfer
VRAMVS EQU  >0958             Default base of value stack
CNSTMP EQU  >0390             Use as temporary stored place
VROAZ  EQU  >03C0             Temporary VDP Roll Out Are
***********************************************************

Edited April 13, 2017 by RXB

[RXB]

Here's a simple example that will explain my skepticism. I decide to take my beloved black and silver 1984 Lotus Excelle bicycle on a cross country trip. (No carbon fiber in this baby - one of the students dubbed it "The Iron Horse") I can ride 15 miles per hour and the trip is 3000 miles. How long will the trip take?

3000 miles/15 mph=200 hours.

Let's say these old legs of mine get a little tired up in the mountains. I get a ride in a car for 100 miles going at 60mph. (4 times faster) How long will the trip take?

2900/15+100/60=195 hours.

Let's say I get sick of the whole thing at the 2000 mile mark. I get a ride in a car for 1000 miles going at 60 mph. (4 times faster) How long will the trip take?

2000/15+1000/60=150 hours

At the 2000 mile mark, let's say I encounter a friendly ET in a UFO that can warp time and space. It takes me the final 1000 miles instantaneously. How long will the trip take?

2000/15=133.3 hours

 

Now let's pretend my cross country trek is a program running in RXB. If 1/30 of the program is 4x faster the speed increase is only 2.5%. Even if you are running 1/3 the program 4x faster, the program as a whole still takes 75% of the time to finish. And in the UFO example it still takes 66.6% of the time. Those are the kind of numbers you are up against.

 

Fine you win it will be 1% faster, happy?

Edited April 14, 2017 by RXB

[Opry99er]

LOL @ the UFO example.

 

Fun way to look at the subject.

[+InsaneMultitasker]

For what its worth, there would be some areas that will improve much more than others.

 

For example, if I compare string operations between TI Extended BASIC and Myarc Advanced BASIC, both running on a Geneve, there is generally a 15x to 20x speed increase in the latter. I've done the timing. The primary difference? Myarc Advanced BASIC is written in 100% assembly language.

 

I'd say keep working at it, Rich. It certainly is not a futile effort, daunting as it may seem.

[senior_falcon]

 

Fine you will it will be 1% faster, happy?

No, I would be much happier if it would run 10x faster. I just don't see how it can.

[+Ksarul]

There is already a 100% Assembly alternative that runs on a regular TI: Myarc Extended BASIC II. That does gain a lot on the speed side due to residing in the 128K of the Myarc Memory cards--but most of the time, it is nothing world-shattering. Adding SAMS support to increase program size and complexity is a good thing--and any speed increases are a serious bonus. Just don't expect too much until you've been able to see it in action, as then the proof will be in the benchmarks.

[RXB]

For what its worth, there would be some areas that will improve much more than others.

 

For example, if I compare string operations between TI Extended BASIC and Myarc Advanced BASIC, both running on a Geneve, there is generally a 15x to 20x speed increase in the latter. I've done the timing. The primary difference? Myarc Advanced BASIC is written in 100% assembly language.

 

I'd say keep working at it, Rich. It certainly is not a futile effort, daunting as it may seem.

 

Myarc Advance Basic has no compatibility with SAMS, does not have Editor Assembler built in, will not run many TI Basic programs, and requires special hardware to even function.

(This makes it incompatible with many other hardware including the 1 Meg or larger SAMS)

And it can not run the same size programs as normal XB can run with restricted memory size being a major issue.

Also who is making more Myarc Memory Expansion Cards today?

Is anyone updating Myarc XB 2 today to debug or fix issues?

 

RXB can run from just a Console and can do things Myarc Advaced Basic can not do.

 

Getting a little sick of being under attack all the time.

[+InsaneMultitasker]

 

Myarc Advance Basic has no compatibility with SAMS, does not have Editor Assembler built in, will not run many TI Basic programs, and requires special hardware to even function.

(This makes it incompatible with many other hardware including the 1 Meg or larger SAMS)

And it can not run the same size programs as normal XB can run with restricted memory size being a major issue.

Also who is making more Myarc Memory Expansion Cards today?

Is anyone updating Myarc XB 2 today to debug or fix issues?

 

RXB can run from just a Console and can do things Myarc Advaced Basic can not do.

 

Getting a little sick of being under attack all the time.

My comments were written solely to share an example of some speed gains that could be possible as you redo pieces of RXB, and to show that some areas /can/ be improved significantly.

 

It was neither meant as an attack nor to compare the two feature sets. Your work with RXB has been promising and I think you should continue to enhance it and share as you have been doing.

[+Ksarul]

That was my point as well, Rich. No slams intended here at all. Myarc XB-II isn't an RXB replacement--but it is a version of XB written entirely in Assembly, so it can realistically show how much of a speed increase is likely to come out of such modifications on a /4A. As it uses the additional space of the Myarc memory cards, it also increases the flexibility of BASIC, especially since it works entirely out of the expanded memory space--not the VDP.

 

I still think the SAMS support and the path you've outlined for RXB are good ideas--and Myarc XB-II is good to show how much of an increase in speed can be implemented along that path. It just gives you credible comparison benchmarks with a full-Assembly BASIC interpreter, as a lot of standard TI Extended BASIC programs will generally run without modification.

[RXB]

RXB will have two versions.

1. Normal RXB with standard support like today but some added features so it will run from standalone console with no memory expansion.

2. SAMS RXB will only work with the SAMS card and free up 457 bytes of VDP RAM not to mention no stack or string or symbol table space used from VDP RAM.

(This would allow for multiple screen, color, and pattern tables in VDP for XB programs to use. Even more than one Sprite attribute and velocity table for XB programs.)

 

Imagine a XB program that has multiple Screens and patterns for each screen along with multiple Sprite tables for each screen all controlled from a single XB program.

Edited April 14, 2017 by RXB

[Opry99er]

Reminds me of XB256.

[RXB]

Reminds me of XB256.

I thought XB256 was compiled?

[Omega-TI]

FYI - Extended BASIC 2.5 is now in the FR99/FG99 repository << Message #798 >>

[senior_falcon]

I thought XB256 was compiled?

Nope, runs in standard TI Extended BASIC so there are no compatibility issues. You can compile it for more speed, but that is optional.

[Opry99er]

XB256=Amazing Sauce

[RXB]

Nope, runs in standard TI Extended BASIC so there are no compatibility issues. You can compile it for more speed, but that is optional.

Can you use it with SAMS or does it reside in Lower 8K so not possible to swap out that location?

[senior_falcon]

Standard XB layout - 24K high memory for program, 8K low memory for XB256 subroutines.

[Omega-TI]

RXB will have two versions.

 

2. SAMS RXB will only work with the SAMS card and free up 457 bytes of VDP RAM not to mention no stack or string or symbol table space used from VDP RAM.

 

Am I correct in assuming this will all be transparent to the program and that ANY pre-existing TI Extended BASIC program will work in it?