That's why TI BASIC is so slow!

[Opry99er]

I am by no means an expert in the field, but double interpretation seems like the primary reason for the lack of speed. GPL is not necessarily slow, but the fact that TI BASIC is interpreted via GPL rather than compiled into assembly seems to be the biggest crutch.

 

Seniorfalcon's compiler bypasses GPL altogether and does a proper compile of BASIC code into assembly. The resulting program is insanely fast.

 

So, from that perspective, the GPL "middle-man" slows down execution because of the 'interpreted vs. compiled' deal.

 

I think it is an over-simplification to say that TI BASIC is slow because of GPL, but if BASIC had been compiled in assembly vs the way it was actually implemented, it would have certainly been faster... And that is proven with falcon's compiler.

[matthew180]

Correct, BASIC on the 99/4A is slow because the interpreter is not written in assembly, and the programs and data are stored in VRAM. It does not matter what other language it could have been written in (GPL or otherwise), anything other than assembly means it will have a speed penalty. The reason for BASIC being slow is not an attack on GPL. That said, I have heard that the GPL interpreter is not exactly the most efficient either. If that is true then there could be some improvements that would speed up all GPL execution. I don't know if anyone has ever looked into rewriting the GPL interpreter though?

 

There is also the rumor that the CPU in the 99/4A was supposed to execute GPL as native machine code, which in that case would have made BASIC really fast. I don't think there has ever been proof that his is true though.

[majestyx]

May I ask what the IF THEN issue is with the compiler?

[Opry99er]

The compiler treats IF THEN as TI BASIC does.

 

You must branch to a line number out of an IF THEN statements.

 

120 IF X=3 THEN 150
.
.
150 X=0

Additional logic in XB is allowed, but does not compile.

 

120 IF X=3 THEN X=0

It is not an "issue" per se, just a nuance of the compiler that requires code to be written a certain way in order to use the compiler.

[majestyx]

Ah, okay. I forgot that TI BASIC's IF THEN only allows branching to another line instead of additional logic. Haven't worked with it in some time so I'll need to do a refresher course.

[JamesD]

I am by no means an expert in the field, but double interpretation seems like the primary reason for the lack of speed. GPL is not necessarily slow, but the fact that TI BASIC is interpreted via GPL rather than compiled into assembly seems to be the biggest crutch.

 

Seniorfalcon's compiler bypasses GPL altogether and does a proper compile of BASIC code into assembly. The resulting program is insanely fast.

 

So, from that perspective, the GPL "middle-man" slows down execution because of the 'interpreted vs. compiled' deal.

 

I think it is an over-simplification to say that TI BASIC is slow because of GPL, but if BASIC had been compiled in assembly vs the way it was actually implemented, it would have certainly been faster... And that is proven with falcon's compiler.

FWIW, Microsoft BASIC was able to squeeze into a similar space for a few reasons.

1. 8 bit CPUs might be a little more memory efficient than the 9900.

2. Lots and lots of subroutines. For what GPL might do in an instruction or two, Microsoft BASIC might call a couple subroutines.

3. No GPL interpreter required. That has to take some space.

 

The compiled BASIC comparison isn't a fair one. Even BASICs built in assembly are faster when compiled. You eliminate searching for line numbers, looping doesn't have to look things up on the stack, you can do some things with integers instead of floating point, and you don't need to parse and reparse everything as the code is run. And on the TI, the compiler can take better advantage of scratch RAM. Compilers can also performs some optimizations an interpreter can't, and they may not have to deal with garbage collection.

Rewriting TI BASIC in assembly would be possible, but it would still be slower than a compiled version of a program. And a cross compiler can add things like new loop types (DO WHILE) without requiring additional memory.

Edited April 25, 2017 by JamesD

[Tursi]

 

 

I don't know if anyone has ever looked into rewriting the GPL interpreter though?

 

Repeatedly, cause it's the only way to prove my assertion. It doesn't look like I'll ever have time though. Thus my other project...

[RXB]

Another simple question how much faster is RAM vs VDP?

 

I ask this as everything TI Basic does is in VDP vs XB that moves Line Number Table, Numeric Variables and XB program into Upper RAM unlike TI Basic that keeps everything in VDP.

[Airshack]

I've been plugging away at XB256 and the compiler for the past six months and assure y'all (Lubbock talk) that the IF-THEN issue is not a big deal. It may cause a few more lines of code to be written but that's well worth the 25X-plus speed increase.

 

If you plan for it in advance it's absolutely no issue. If you're trying to

compile pre-written code you may have to add some code/logic and tweak a little.

 

More to come on this matter in the near future...needing to talk with the falconator.

 

 

Sent from my iPhone using Tapatalk

[marc.hull]

Quick question for someone who may know. How much of the console ROM contains the gpl interpreter?

[senior_falcon]

the falconator.

 

lol

[+Lee Stewart]

Quick question for someone who may know. How much of the console ROM contains the gpl interpreter?

 

Well...According to Heiner Martin, the bulk of the GPL Interpreter runs from >0024 – >08FF (2268 bytes), with smaller parts elsewhere (lookup tables, routines shared with Basic, ??)—I have not tried to suss out all of them.

 

I started a thread about a year ago (The TI-99/4A Operating System), in which I was trying to make the Console ROM’s source code from Heiner Martin’s TI Intern easier to read. While the thread was in process, I got what is likely the original source code with pretty good comments. I tweaked it a little so I could assemble it with Asm994a and ZIPped it up into ROM-4A_20160317.zip, which is at the bottom of post #1 of the above thread. Maybe comparing the ROM-4A listing and Heiner Martin’s listing would be useful.

 

The first of the ROM-4A source files is entitled “T.I. 99/4A GRAPHICS LANGUAGE INTERPRETER” and covers the first 3354 bytes of the ROM-4A.lst listing in the above reference. Maybe this number is closer to what you are looking for.

 

...lee

[RXB]

Quick question for someone who may know. How much of the console ROM contains the gpl interpreter?

About 60% of the Console ROM is taken up by the GPL interpreter.

ROM 0 is mostly dealing with Device access and control along with menu systems for access to memory and input / output controls.

 

The book TI Intern lays out all of it.

 

To be blunt there is no possible way to make the TI99/4A with Console only run from VDP RAM when it only has 256 bytes of it and 16K of VDP only.

 

So basically everyone is bitching about a design of the original TI99/4A and this is due to chip costs at the time.

 

1. The 16bit CPU was hamstrung by 4 cycles each step using byte accessed on 16 bit words.

2. Using VDP over RAM further slowed the performance.

3. This made GPL line VDP slower by delays in access each step of read before write of a byte in a byte only language and control from VDP/GROM.

4. All interrupts tied into a single line meant very little PC like design.

 

Blaming GPL for being slow in a hamstrung design is not really fair as if GPL had been designed to run from RAM instead of slower GROM/VDP it would be as fast as C.

[Asmusr]

The GPL linker is running GPL from memory expansion RAM. I believe this has been used to convert a number of GROM carts into E/A#5 files. I think they are running at more or less the same speed as the originals.

[RXB]

The GPL linker is running GPL from memory expansion RAM. I believe this has been used to convert a number of GROM carts into E/A#5 files. I think they are running at more or less the same speed as the originals.

Yea the Linker has a delay loop so programs work correctly like they normally would, otherwise joysticks and keys would not work correctly.

[+arcadeshopper]

Even back in the early 80's, I've wanted to see << ROBOT ATTACK >> for the TRS-80 on the TI-99/4A. I'm willing to bet that a compiled XB version could play just as well, but be more colorful and exciting on the TI.

 

 

https://www.youtube.com/watch?v=9IDQa85brpY&list=PLshIznEcyXK4DfQfZjuTK7GuCm4gZLBzc&index=1

 

Bandit By Unknown Author

In this game, a take on the famous arcade game "Frenzy", you are a sneaky bandit trying to collect as much treasure chests as you can find inside a vast labyrinth infested with deadly shooting robots and flying creatures, armed with an effective laser gun. The labyrinth is divided into rooms with multiple exits, each of which leads to other rooms with different layouts and dangers, thus maintaining a high level anticipation as well as dread throughout the game. The animations are silky smooth and your character is very responsive. Good sound effects. Highly enjoyable.

Requirements: Extended Basic cartridge, 32K RAM, disk drive. Joysticks optional.

Executable to run: LOADBAND

 

frenzy is the sequel to berzerk

[Omega-TI]

 

 

Cool, thanks for bringing this one to my attention Greg. It does not appear to have been converted to FlashROM 99 format.

Anyone out there want to convert it?

[Airshack]

While watching that video I really enjoyed the look and feel. Sent me back to my Radio Shack groupie days in 1979...cool!

 

Did the Trash-80 have a sound synth? I'm thinking no and that was all generated in software?

 

If you wanted the voice synth to be part of the game you can't use the compiler. Speech Synth is not supported with the compiler. Again, assembly wins.

 

I'd guess someone clever could probably tackle that game in pure XB.

[JamesD]

About 60% of the Console ROM is taken up by the GPL interpreter.

ROM 0 is mostly dealing with Device access and control along with menu systems for access to memory and input / output controls.

 

The book TI Intern lays out all of it.

 

To be blunt there is no possible way to make the TI99/4A with Console only run from VDP RAM when it only has 256 bytes of it and 16K of VDP only.

 

So basically everyone is bitching about a design of the original TI99/4A and this is due to chip costs at the time.

 

1. The 16bit CPU was hamstrung by 4 cycles each step using byte accessed on 16 bit words.

2. Using VDP over RAM further slowed the performance.

3. This made GPL line VDP slower by delays in access each step of read before write of a byte in a byte only language and control from VDP/GROM.

4. All interrupts tied into a single line meant very little PC like design.

 

Blaming GPL for being slow in a hamstrung design is not really fair as if GPL had been designed to run from RAM instead of slower GROM/VDP it would be as fast as C.

 

I'm not sure the comparison to C is appropriate.

C is not an interpreter so comparing speed of GPL code to compiled C code... even if GPL uses 16 bit CPU RAM, the C code wins hands down.

If you compare a native assembly BASIC interpreter to running one on GPL, the native one wins hands down.

If you write a BASIC interpreter in C with some assembly subroutines, that probably wins hands down as well. It probably won't be as fast as the one completely written in assembly though.

 

People keep calling GPL an interpreter. It is but perhaps it isn't the most precise description.

GPL is a virtual processor/machine, so comparing it to native code or a language compiled to native code really isn't a fair comparison.

 

The problem is that running an interpreter on top of GPL is slower than a native 9900 BASIC interpreter would be even if the native code interpreter had the same restrictions (using VDP RAM). And running any interpreter out of VDP RAM is slower than if they used CPU RAM.

[JamesD]

While watching that video I really enjoyed the look and feel. Sent me back to my Radio Shack groupie days in 1979...cool!

 

Did the Trash-80 have a sound synth? I'm thinking no and that was all generated in software?

 

If you wanted the voice synth to be part of the game you can't use the compiler. Speech Synth is not supported with the compiler. Again, assembly wins.

 

I'd guess someone clever could probably tackle that game in pure XB.

It used the cassette output as a beeper or DAC. I can't remember which design the TRS-80 Model I used for it's cassette port though.

 

[Airshack]

About 60% of the Console ROM is taken up by the GPL interpreter.

ROM 0 is mostly dealing with Device access and control along with menu systems for access to memory and input / output controls.

 

The book TI Intern lays out all of it.

 

To be blunt there is no possible way to make the TI99/4A with Console only run from VDP RAM when it only has 256 bytes of it and 16K of VDP only.

 

So basically everyone is bitching about a design of the original TI99/4A and this is due to chip costs at the time.

 

1. The 16bit CPU was hamstrung by 4 cycles each step using byte accessed on 16 bit words.

2. Using VDP over RAM further slowed the performance.

3. This made GPL line VDP slower by delays in access each step of read before write of a byte in a byte only language and control from VDP/GROM.

4. All interrupts tied into a single line meant very little PC like design.

 

Blaming GPL for being slow in a hamstrung design is not really fair as if GPL had been designed to run from RAM instead of slower GROM/VDP it would be as fast as C.

 

Item1. The competition had 8-bit CPUs (6502 & Z80 mainly) with 8-bit data buses with no speed bumps akin to the 16-to-8 bit multiplexer TI had to use?

 

Item 2. So it's safe to say that money saving hardware design (VDP RAM and only 256bytes conventional CPU RAM) is why the BASIC interpreter HAD TO BE written in GPL, not Assembly; so that's why BASIC is slow. The problem is hardware and GPL is just a symptom of the problem?

 

Question: Just how much cheaper was VDP over conventional RAM and why didn't Commodore/Atari/Tandy/Apple have this design-altering cost problem with their machines?

[Airshack]

So RXB-Rich's point is the problem with BASIC on the TI-99/4A is all in the design of the hardware. Tripping over dollars to pick up the pennies?

 

A complete lack of vision from a team attempting to build: 50% Home Computer + 50% Ultimate Equation Calculator?

 

 

[Asmusr]

Yea the Linker has a delay loop so programs work correctly like they normally would, otherwise joysticks and keys would not work correctly.

 

So by removing that delay loop you could run GPL programs much faster?

[Omega-TI]

Speaking of which, is there a simple calculator program for the TI? I don't recall if there ever was, but one would be nice in FlashROM format.

 

[Airshack]

Speaking of which, is there a simple calculator program for the TI? I don't recall if there ever was, but one would be nice in FlashROM format.

 

Just buy a straight TI-99/4 off eBay and everything is built in via menu option 2.

 

 

Sent from my iPhone using Tapatalk