That's why TI BASIC is so slow!

[RXB]

It takes 15 seconds to assemble the complete RXB2012 source code with ralphb's xga99 assembler on my 9 years old intel atom PC.

 

And you don't have to load the objects to GRAM to run it. The generated file is a cartridge binary.

 

Check this post for more details

 

Impressive, but when attempting to use this tool with Windows it wants to load a crap load of stuff normally only found in Linux or Unix.

If I was using OX X instead of Windows running Classic99 I would be interested more.

But ease of use using MESS does not exist, I have used Classic99 for that reason.

 

Also you can not GPOKE a GPL byte in GROM and see the change result using xga99 Assembler which is a tool you lose using a BIN file that is UNCHANGEABLE in Classsic99.

Now in MESS you can do this but than again I am not using MESS on Linux or OS X yet.

Maybe in the future at Fest West someone can catch me up, due to all past attempts resulted in failure and total frustration.

[RXB]

 

Why is TI Basic so slow?

 

 

Again VDP speed is the issue and lack of any RAM in the TI Console a TI self imposed stupid choice built from cost of chips in the market.

TI opted for VDP instead of RAM and this is the main reason why TI Basic is SLOOOOOOOW!

 

Now XB has 12 of ROM ASSEMBLY LANGUAGE SUPPORT, which is why XB is FASTER THAN TI BASIC.

 

Why does no one get this fact?

(Yes Floating Point is slow, yes GPL is slower then Assembly, BUT NO GPL is not the problem as proven by XB using ROMs!)

[RXB]

I also want point out GPL is 640K of GROM/GRAM in a TI Console built into the design of the TI Console with NO MEMORY EXPANSION NEEDED!

 

This was a huge selling point of the TI over every other computer as no other computer on the market could possible at that time have a 640K cartridge and to bad TI did not make any.

 

Think of the impact if TI had put 16 Carts in a single Cartridge and sold it?

Editor Assembler

XB

Logo

Pascal

TI Writer

Multiplan

various other games configurations.....it would have been huge for selling the TI99/4A

[gfreige]

Again VDP speed is the issue and lack of any RAM in the TI Console a TI self imposed stupid choice built from cost of chips in the market.

TI opted for VDP instead of RAM and this is the main reason why TI Basic is SLOOOOOOOW!

 

Now XB has 12 of ROM ASSEMBLY LANGUAGE SUPPORT, which is why XB is FASTER THAN TI BASIC.

 

Why does no one get this fact?

(Yes Floating Point is slow, yes GPL is slower then Assembly, BUT NO GPL is not the problem as proven by XB using ROMs!)

 

Because it´s not true. XB is really slow too. Doing a simple loop like printing from 1 to 1000 in both machines, the C64 is 2-3x faster (depending of the screen output formatting), using an 1Mhz clock, than the TI using a 3MHz clock. The 9900 doesn't help using more cycles than the 6502 for the same instruction, but GPL is part of the problem.

[JamesD]

Keep in mind I have not seen a disassembly of TI BASIC. This is just based on my observations of the VDP, what I've read, and what I've seen in Microsoft BASIC.

I'm not sure I'd say the VDP is slow so much as the interface to the VDP wasn't designed for jumping around in memory out of sequence.
You set the address in video RAM you want to access and then the VDP steps merrily along sequentially through video RAM as you write or read from it.
I looked at porting my 64 column graphics text code to the ADAM and this actually works out to be pretty fast. Especially due to the order the bytes appear on the screen.
The problem comes in when you try to run an interpreter running a program out of video RAM.
If you look at an interpreter, it often reads sequentially through program lines looking for tokens, variables, or constants.
That happens fairly fast. It's when it finds a variable reference, constant, or branch where things start to get ugly.
Every time it has to access one of these, it has to change the VDP pointer to a different address.
And when it looks for a line number, it scans through a linked list looking for that line number, so that pointer has to change every few instructions.
It's AT LEAST an additional instruction for every single step of the search compared to Microsoft BASIC.
The CPU is probably doing 10% more work do to having to constantly change that pointer.
If you can place recently accessed stuff in regular RAM like the BASIC stack, you can save a lot of time since it saves things like the start address of FOR loops and it's variables,, RETURN addresses, etc... but if that is in VDP RAM... just that gets ugly in a hurry.
Had TI even included 2K of 16 bit RAM, it could have made a noticeable difference.
Caching addresses of recently used line numbers would drastically cut search times for line numbers.
That speeds up enhanced versions of other BASICs a lot, so with the TI's VDP overhead that has to offer a huge improvement.

Since GPL is in 16 bit ROM and it uses scratchpad RAM a lot, it isn't your biggest bottleneck.
GPL itself would run much faster if it were using 16 bit RAM for code..
If you do away with having to use VDP RAM, then GPL would be the next bottleneck.

*edit*
Just another thought here.
Parts of the interpreter aren't in GPL.
If I remember right, the floating point library is in regular 9900 assembly.
If the overhead of the math library is anything like Microsoft BASIC, that might worse than GPL
The thing is, you are stuck with the math. GPL didn't have to be there.

Edited April 24, 2017 by JamesD

[senior_falcon]

Again VDP speed is the issue and lack of any RAM in the TI Console a TI self imposed stupid choice built from cost of chips in the market.

TI opted for VDP instead of RAM and this is the main reason why TI Basic is SLOOOOOOOW!

 

Now XB has 12 of ROM ASSEMBLY LANGUAGE SUPPORT, which is why XB is FASTER THAN TI BASIC.

 

Why does no one get this fact?

(Yes Floating Point is slow, yes GPL is slower then Assembly, BUT NO GPL is not the problem as proven by XB using ROMs!)

TI Extended BASIC can be run without the 32K memory expansion. Therefore it follows that on a system without the 32K memory expansion, all memory accesses must be to/from VDP RAM. Speed tests show that there is virtually no speed difference when running XB from VDP vs running from the 32K expansion.

For many operations, XB is considerably faster than BASIC. In your own words, "Now XB has 12 (sic) of ROM ASSEMBLY LANGUAGE SUPPORT, which is why XB is FASTER THAN TI BASIC." So XB uses assembly routines in places where BASIC would use GPL, and the result of using less GPL is that it runs faster. It seems obvious to me that GPL is the problem. Why can you not get this fact?

[Omega-TI]

[JamesD]

TI Extended BASIC can be run without the 32K memory expansion. Therefore it follows that on a system without the 32K memory expansion, all memory accesses must be to/from VDP RAM. Speed tests show that there is virtually no speed difference when running XB from VDP vs running from the 32K expansion.

For many operations, XB is considerably faster than BASIC. In your own words, "Now XB has 12 (sic) of ROM ASSEMBLY LANGUAGE SUPPORT, which is why XB is FASTER THAN TI BASIC." So XB uses assembly routines in places where BASIC would use GPL, and the result of using less GPL is that it runs faster. It seems obvious to me that GPL is the problem. Why can you not get this fact?

Microsoft BASIC parses some things through a central charget routine which mostly looks for certain characters or a character passed as a parameter.

But a lot of stuff is parsed inline which is much faster.

 

To use the two types of RAM, I'm guessing the TI uses a standard routine(s) similar to charget where all characters are dealt with rather than parsing any inline.

(this is also how some Microsoft BASICs address banked RAM)

The routine has to test which mode it's in each time it's called, or you have to copy a different routine to RAM for which mode it's in and call it there.

charget normally steps through RAM sequentially until it finds what it's looking for, which is just as fast on the VDP as it is on regular RAM once the address has been set.

So you shouldn't expect a lot of difference there.

It's when you have a big program with a lot of GO TO / SUB statements that you should start to see a real difference.

The line number search should have been optimized to work much faster with CPU RAM.

If not, I'd say that's an Extended BASIC issue.

But hey... I haven't see the code.

[JamesD]

 

 

You just did.

[Omega-TI]

I remember Shamus well. I wanted to see the higher levels and did not have the skill to get there. So I did some poking around inside the program. After I found where the number of lives was kept it was simple to write an interrupt based program that kept a constant number of lives. Boy, that highest level is hard!

 

Sometimes, due to time constraints, I like simplicity in games. Simply clearing the screen to go on to the next level is preferable. Shamus is nice, but having to go through the maze, finding the keys and stuff is just an added component that most times I don't want to deal with.

 

When it comes to cheats.. HECK YEAH! For a guy like me that's the only way I'll ever live long enough in a game to examine the upper levels or improve my 'skillz'. If you ask me, EVERY new game coming out these days should have a 'god mode'

[RXB]

 

Because it´s not true. XB is really slow too. Doing a simple loop like printing from 1 to 1000 in both machines, the C64 is 2-3x faster (depending of the screen output formatting), using an 1Mhz clock, than the TI using a 3MHz clock. The 9900 doesn't help using more cycles than the 6502 for the same instruction, but GPL is part of the problem.

WRONG! Which is faster XB or TI Basic using the same program?

Also the C64 is not 16 bit but 8 bit, yes faster but Basic and XB also still run from VDP, which I am going to change in the future to SAMS RAM.

And honestly the C64 Disk Drive is a freaking joke! While you are waiting for a C64 to load a program the TI is already running it.

 

And if you want to write a XB for the TI go for it not using GPL and let us know when you finish.

[RXB]

TI Extended BASIC can be run without the 32K memory expansion. Therefore it follows that on a system without the 32K memory expansion, all memory accesses must be to/from VDP RAM. Speed tests show that there is virtually no speed difference when running XB from VDP vs running from the 32K expansion.

For many operations, XB is considerably faster than BASIC. In your own words, "Now XB has 12 (sic) of ROM ASSEMBLY LANGUAGE SUPPORT, which is why XB is FASTER THAN TI BASIC." So XB uses assembly routines in places where BASIC would use GPL, and the result of using less GPL is that it runs faster. It seems obvious to me that GPL is the problem. Why can you not get this fact?

So just ignore the history of the TI99/4A and facts so you can make a point that Assembly is faster?

I have EVER said otherwise, Assembly is faster than GPL. WHEN HAVE I EVER SAID OTHERWISE??????

 

Why do you guys have to be dicks about it?

 

GPL does one thing really really better than any other language made for the TI99/4A, it is more compact taking less space, runs from a separate memory area so not needing to be switched out like ROM or RAM.

And GPL can access Assembly seamlessly that allows all types of devices, unlike Assembly that requires huge space and huge code to do exactly the same thing, but the TI99/4A NEVER HAD ROOM FOR AT THAT TIME.

 

If you like Assembly fine, but quit being jerks about me and GPL as I have told no lies. Also I have not twisted any facts or been TROLLING anyone which I suspect this has become.

Edited April 24, 2017 by RXB

[RXB]

Microsoft BASIC parses some things through a central charget routine which mostly looks for certain characters or a character passed as a parameter.

But a lot of stuff is parsed inline which is much faster.

 

To use the two types of RAM, I'm guessing the TI uses a standard routine(s) similar to charget where all characters are dealt with rather than parsing any inline.

(this is also how some Microsoft BASICs address banked RAM)

The routine has to test which mode it's in each time it's called, or you have to copy a different routine to RAM for which mode it's in and call it there.

charget normally steps through RAM sequentially until it finds what it's looking for, which is just as fast on the VDP as it is on regular RAM once the address has been set.

So you shouldn't expect a lot of difference there.

It's when you have a big program with a lot of GO TO / SUB statements that you should start to see a real difference.

The line number search should have been optimized to work much faster with CPU RAM.

If not, I'd say that's an Extended BASIC issue.

But hey... I haven't see the code.

RXB is the XB code and I kept all of it just commented with * to indicate changes and explain all changes in the RXB Source Code.

RXB TEXT.zip

[RXB]

Microsoft BASIC parses some things through a central charget routine which mostly looks for certain characters or a character passed as a parameter.

But a lot of stuff is parsed inline which is much faster.

 

To use the two types of RAM, I'm guessing the TI uses a standard routine(s) similar to charget where all characters are dealt with rather than parsing any inline.

(this is also how some Microsoft BASICs address banked RAM)

The routine has to test which mode it's in each time it's called, or you have to copy a different routine to RAM for which mode it's in and call it there.

charget normally steps through RAM sequentially until it finds what it's looking for, which is just as fast on the VDP as it is on regular RAM once the address has been set.

So you shouldn't expect a lot of difference there.

It's when you have a big program with a lot of GO TO / SUB statements that you should start to see a real difference.

The line number search should have been optimized to work much faster with CPU RAM.

If not, I'd say that's an Extended BASIC issue.

But hey... I haven't see the code.

Actually IT DOES when XB detects that you load a XB program and have a 32K

it moves the XB program from VDP to 24K RAM

It moves the Numeric Symbol Table to upper 24K RAM

It moves the Line Number Table to upper 24K RAM

Storing all of this in reverse order from >FFE6 to >A000 in upper 24K RAM

 

This is all laid out in Miller Graphics Smart Programmer and the XB source code.

 

And here is the Source Code:

RXB TEXT.zip

[gfreige]

WRONG! Which is faster XB or TI Basic using the same program?

Also the C64 is not 16 bit but 8 bit, yes faster but Basic and XB also still run from VDP, which I am going to change in the future to SAMS RAM.

And honestly the C64 Disk Drive is a freaking joke! While you are waiting for a C64 to load a program the TI is already running it.

 

And if you want to write a XB for the TI go for it not using GPL and let us know when you finish.

First, why are you so intense? The universe isn't against you. Chill out man ?

Second, you are mixing things, again. Nobody is talking about disk access speed, we are talking about basic execution times.

And you contradict yourself, you are saying GPL has nothing to do with a slow basic, and you are saying the XB is faster because it has some functions implemented in assembler.

Regarding assembly basic, isn't cortex basic exactly that. I'll make the same test with it later

[Omega-TI]

...isn't cortex basic exactly that. I'll make the same test with it later

 

I like the 80 column capability of Cortex BASIC, even if it's a little light in presentation ability. Man, if that program was tweaked to take advantage of the SAMS card....

[RXB]

First, why are you so intense? The universe isn't against you. Chill out man

Second, you are mixing things, again. Nobody is talking about disk access speed, we are talking about basic execution times.

And you contradict yourself, you are saying GPL has nothing to do with a slow basic, and you are saying the XB is faster because it has some functions implemented in assembler.

Regarding assembly basic, isn't cortex basic exactly that. I'll make the same test with it later

No argument Assembly is faster, but factually Assembly needs SOMEPLACE TO RESIDE!

There is NO CONSOLE BUILT IN FACILITY TO DO THIS unlike GPL that was built in.

 

Now if this is a argument of what you think the TI should be designed like, but that is not the real world of what we have now.

And is this just shooting for what you would like this is not the reason Basic is slower then XB, I have laid out exactly why and know it better than anyone.

The problem is VDP and GPL combined with Assembly increases the speed, but Texas Instruments did not want a major speed difference between TI Basic and XB,

thus why they did not move ALL OF XB including STRINGS to RAM. This would force a chance in all XB programs to not work the same as TI Basic. Texas Instruments

opted for compatibility over speed. This is why the odd way they added Assembly to XB.

 

I mean how often have you looked at the TI Basic and XB source code?

(I have been doing it for 30 years I am not a idiot!)

Edited April 24, 2017 by RXB

[+Lee Stewart]

No argument Assembly is faster,

 

Thank you, Rich. This is what we have all been saying.

 

... but factually Assembly needs SOMEPLACE TO RESIDE!

There is NO CONSOLE BUILT IN FACILITY TO DO THIS unlike GPL that was built in.

 

This speaks only to design constraints about why TI could/would not go the faster route. It does not explain the speed differences.

 

...lee

[RXB]

 

Thank you, Rich. This is what we have all been saying.

 

 

This speaks only to design constraints about why TI could/would not go the faster route. It does not explain the speed differences.

 

...lee

You mean between TI Basic and XB?

 

Why is it no one listens to me on this? Who the hell else has spent so much time looking at the GPL code and XB code? REALLY WHO?

[senior_falcon]

GPL is not the problem as proven by XB using ROMs!)

Lemme get this straight. XB runs faster because it uses more ROMs, meaning more of XB is written in assembly. But somehow GPL isn't the problem. How does your statement even make sense? And why am I a dick for pointing this out?

 

[RXB]

Lemme get this straight. XB runs faster because it uses more ROMs, meaning more of XB is written in assembly. But somehow GPL isn't the problem. How does your statement even make sense? And why am I a dick for pointing this out?

 

Yes and XB is not written exclusively in Assembly as XB2 is written in Assembly. And why is GPL a problem it worked great for over 30 years so far.

 

Here is a question you need to answer:

 

If XB2 written in Assembly is so great why are so few using it?

[senior_falcon]

Where would I find XB2? If I had it I would certainly try it out.

 

You are getting away from the question, which asked why TI BASIC was so slow. The answer is mostly because it is written in GPL. By your own words you agree that GPL is slower than assembly. So it should be clear to anyone that the performance issues with TI BASIC are due to GPL. If you want to think otherwise, feel free to do so, but you are in a minority of one.

 

This is a total waste of time, so I will return to working on making a loader for compiled code that uses the EA cartridge instead of XB. In EA BASIC. With the EA cartridge the loader will load a long compiled program in 8 seconds vs 135 seconds for the GPL written loader in XB. But hey, at least GPL isn't the problem.

[RXB]

Ok

 

Where would I find XB2? If I had it I would certainly try it out.

 

You are getting away from the question, which asked why TI BASIC was so slow. The answer is mostly because it is written in GPL. By your own words you agree that GPL is slower than assembly. So it should be clear to anyone that the performance issues with TI BASIC are due to GPL. If you want to think otherwise, feel free to do so, but you are in a minority of one.

 

This is a total waste of time, so I will return to working on making a loader for compiled code that uses the EA cartridge instead of XB. In EA BASIC. With the EA cartridge the loader will load a long compiled program in 8 seconds vs 135 seconds for the GPL written loader in XB. But hey, at least GPL isn't the problem.

Ok so WHERE is this magical memory coming from to make TI Basic all Assembly?

 

I mean the original post is WHY IS TI BASIC SO SLOW and I have laid out all the problems many times, including many times admitting that GPL is slower than Assembly, but then so is C or Cobol or Pascal or Fortram.

 

As you can take a section of C or Cobol or Pascal or Fortram and recompile it better then that language and get a speed increase. This is just a fact.

 

You seem to be stuck in a loop of picking on GPL when other problems are just as much a issue.

 

Suggesting Trolling me simply to attack GPL over and over.

[Omega-TI]

 

Here is a question you need to answer:

 

If XB2 written in Assembly is so great why are so few using it?

 

Rich, you have to know that is not a fair question. Most people use what was obtainable at the time, what they are used to or what is compatible with other software. In short, there are many reasons people choose things. Very few people use RXB and we are not calling into question it's merits. If we did, I think you might find that a little negative...right? There are lots of GREAT programs out there, but not enough time in our lives to adopt and use them all, so people make their choice and usually stick with it.

[Airshack]

I'd like to thank EVERYONE on this thread for providing answers and helping the less esteemed members understand BASIC's issues on this wonderfully mysterious mess of a computer. Wow!

The experienced and most knowledgeable members of the TI AtariAge group are doing a fabulous job of educating and entertaining the rest of us.

 

THANK YOU! Peace and Love!

 

 

Sent from my iPhone using Tapatalk