Jump to content

Photo

That's why TI BASIC is so slow!


177 replies to this topic

#51 sometimes99er OFFLINE  

sometimes99er

    River Patroller

  • 3,907 posts
  • Location:Denmark

Posted Thu Apr 20, 2017 12:29 PM

I was speaking mostly about program development in BASIC on the TI, not old programs.

 

I didn't say anything about old programs. Any program in TI BASIC is a TI BASIC program, old, new or future one.
 

Old School Rule: "In order to write a really good graphic based game you need to code it in something other than BASIC or Extended BASIC because they're too slow on the TI."

Harry's compiler shatters that rule!

 

More or less. A matter of taste. Some may still enjoy making a TI BASIC or XB graphic game (non-compiled old style) and some may fine it really good.
 

The BASIC compiler significantly empowers the less advanced coders is all!'

 

Absolutely. Hope to see some really good graphic based games.

 

I maintain....GAME OVER!

 

Okay, I guess that means we will see no more TI BASIC and XB games. It's GAME OVER. You said it.

And then I hope the compiled games really are that good.

 

TI BASIC and XB compilers has been around for long, and I guess there must be tons of BASIC coders here. MAJOR game changer ?

face-savouring-delicious-food.png


Edited by sometimes99er, Thu Apr 20, 2017 12:31 PM.


#52 --- Ω --- OFFLINE  

--- Ω ---

    .....................

  • 10,360 posts
  • TI-99/4A Fanatic
  • Location:In the den playing with my FinalGROM 99!

Posted Thu Apr 20, 2017 1:26 PM

 

TI BASIC and XB compilers has been around for long, and I guess there must be tons of BASIC coders here. MAJOR game changer ?

 

If I could make one small observation here.  Sometimes people are so busy with life, they don't have the time to take on major projects or devote time to something that at first look glance 'appears' to be too time consuming or too difficult to fit into their schedules.

 

Sometimes all it takes is for someone to 'show them the way' by 'connecting the dots' while 'holding their hand' before they realize, "DAMN, THAT WAS EASY!"  One example I'll use is the set of instructions made by Gazoo that showed people how to program the 1284P.  To a person who has never done it before, or who has just gotten his first burner, it's new and 'unknown territory'.  Gazoo's directions were so simple, newbies could even do it. 

 

The near  future has things in store and proof on the way...



#53 Airshack ONLINE  

Airshack

    Dragonstomper

  • Topic Starter
  • 508 posts
  • Location:Phoenix, AZ

Posted Thu Apr 20, 2017 3:32 PM

"You may compile, but many programs won't compile, and those that do often fail or misbehave."

^^^^^ Sounded like you were referencing legacy code.

I haven't found the compiler unable to compile or noticed any misbehaving at all?

If a programmer writes with the compiler as part of his/her workflow the process is as smooth as silk.

Additionally, the compiler solves more problems than it creates. Example: I recently wrote a 24k program which compiled down to about 22k. I was able to unexpectedly "over-code" some features into the program near the end of development. My code was too large for XB, yet Compiled and ran with room to spare!

I believe there's some misunderstanding here as well. The compiler does compile TI BASIC as well as XB programs. XB256 extensions are not required. I'm not claiming BASIC and XB are dead.

That's silly!

GAME OVER is more a snarky comment about the 35+ year old BASIC programming workflow.

The compiler injects new life into the process by lowering the cost of entry for game programmers especially.

So, things aren't going away as much as they're changing.




Sent from my iPhone using Tapatalk

Edited by Airshack, Thu Apr 20, 2017 3:34 PM.

  • RXB likes this

#54 Airshack ONLINE  

Airshack

    Dragonstomper

  • Topic Starter
  • 508 posts
  • Location:Phoenix, AZ

Posted Thu Apr 20, 2017 4:08 PM

If you XB or TI BASIC game is "really good" without being compiled...well, it'll be better (way faster) once compiled. Think 20-50X faster!


Sent from my iPhone using Tapatalk

#55 senior_falcon OFFLINE  

senior_falcon

    Dragonstomper

  • 908 posts
  • Location:Lansing, NY, USA

Posted Thu Apr 20, 2017 9:31 PM

Here's kind of a goofy idea for speeding up BASIC or XB.  How about redoing the routines that use floating point numbers so that they use integers instead.  All the math routines would be lightweight and fast; there would be no CFI with HCHAR.  And so on.  This would be pretty specialized and many would find it of limited interest, though it might find use when programming games.  There would be a speed increase, but how much is hard to say.  I would guess no more than a factor of two and maybe not even that, but even that would still seem peppy compared to normal XB.  



#56 InsaneMultitasker OFFLINE  

InsaneMultitasker

    Stargunner

  • 1,690 posts

Posted Thu Apr 20, 2017 10:58 PM

Here's kind of a goofy idea for speeding up BASIC or XB.  How about redoing the routines that use floating point numbers so that they use integers instead.  All the math routines would be lightweight and fast; there would be no CFI with HCHAR.  And so on.  This would be pretty specialized and many would find it of limited interest, though it might find use when programming games.  There would be a speed increase, but how much is hard to say.  I would guess no more than a factor of two and maybe not even that, but even that would still seem peppy compared to normal XB.  

This sounds like a great idea.  There are quite a few subprograms and functions that use numeric values and only require a relatively small integer.  It seems the floating point numbers would be the exception in many cases.


  • RXB likes this

#57 sometimes99er OFFLINE  

sometimes99er

    River Patroller

  • 3,907 posts
  • Location:Denmark

Posted Fri Apr 21, 2017 12:04 AM

I haven't found the compiler unable to compile or noticed any misbehaving at all?

 

If you XB or TI BASIC game is "really good" without being compiled...well, it'll be better (way faster) once compiled. Think 20-50X faster!

 
I've been around and had my share. I was commenting on the experience of average TI BASIC and XB coders, like myself, Opry99er, Retrospect and Sinphaltimus.
 
I wasn't commenting on someone with foreknowledge and developing specifically for compilation - which is what you suggest.
 
The average TI BASIC and XB coders will see that his new game, that unfortunately is slow, and who's going for compilation, will need to do a lot of adjustments to make the game work. Just going faster is not always better.
 
Besides the IF THEN fall pit, there are standard issues with variables not being floating point and things moving too fast. Luxury perhaps, but still issues to be dealt with. The compilation process for larger programs is somewhat tedious, though I used the WinAsm99 cross-assembler. Debugging is also somewhat tedious and a longer learning process (to get comfortable and optimal). I hope senior_falcon (XB256 developer) and the others above will tend to agree.
 
And I still agree. The XB Game Developers Package (XB256) is absolutely godsend for TI BASIC and XB coders.
 
MAJOR game changer and GAME OVER for TI BASIC and XB ? I hope not. We've had some good fun and competitions over the years. Seeing something done good in the plain and slow TI BASIC environment is still nice. Seeing something else done good is also nice. To me.
 

I'm not claiming BASIC and XB are dead.

That's silly!

GAME OVER is more a snarky comment about the 35+ year old BASIC programming workflow.


Snarky. Witty. Humorous. Tongue-in-cheek. With that in hindsight, I think we can work ourselves out of any situation.  :-D


Edited by sometimes99er, Fri Apr 21, 2017 12:15 AM.


#58 RXB OFFLINE  

RXB

    River Patroller

  • 2,721 posts
  • Location:Vancouver, Washington, USA

Posted Fri Apr 21, 2017 12:10 AM

One of the things I have mentioned many times is TI when they created TI Basic and XB mostly exclusively opted for Floating Point in all operations.

I guess the idea was to use the INT(FP) as a way to reduce them to integer, but when looking at XB programs it gets pretty insane the number of times you see INT(FP) used.

This just slows TI Basic much further then XB as doing a test I found that INT(FP) 10,000 times takes 2 minutes for XB and over 4 minutes with TI Basic.

I think the reason is INT in TI Basic is in 100% GPL using VDP vs XB that uses Assembly in ROMs combined with GPL, thus the Assembly really speeds up the results as it should.

 

A rewrite of XB and TI Basic to remove all the heavy emphasis on Floating Point would speed up both considerably.



#59 sometimes99er OFFLINE  

sometimes99er

    River Patroller

  • 3,907 posts
  • Location:Denmark

Posted Fri Apr 21, 2017 2:00 AM

Yes, XB256 has been on my radar lately... and will probably be on quite a few other peoples too after the 29th... but I probably should not have even said that...  stay tuned.  

 

It better be "a really good graphic based game" to try and ease the GAME OVER claims. Still hope to see the odd impressive or casual game from time to time written in good old plain TI BASIC and XB.



#60 Ksarul OFFLINE  

Ksarul

    River Patroller

  • 4,126 posts

Posted Fri Apr 21, 2017 5:20 AM

On the massive use of floating point math, you have to look at the origins of the 99/4. I've read that a lot of the original team members came out of the calculator division--and that had a number of design consequences. Chiclet keys were pretty much standard in their minds, as was wringing the maximum mathematical precision possible out of their products. The TI calculators of the day had 12-digit precision (but only displayed the first 10 digits), so their goal would likely have been influenced by that. At this point it is just speculation on my part, but it seems to fit with the known data.



#61 mizapf OFFLINE  

mizapf

    River Patroller

  • 2,502 posts
  • Location:Germany

Posted Fri Apr 21, 2017 6:59 AM

I remember well those challenges like "try PRINT SQR(49)-7". The TI was the only one to return 0.

#62 Ksarul OFFLINE  

Ksarul

    River Patroller

  • 4,126 posts

Posted Fri Apr 21, 2017 7:42 AM

I remember that challenge too. I had a girlfriend back then that stated that "all" calculators would give the wrong answer to that problem. The look on her face when I pulled out my TI calculator and it gave the correct answer was priceless. . .and then she pillaged it to use for her own needs, as she knew that it would always be right. I never saw that calculator again. . .


  • RXB likes this

#63 carlsson OFFLINE  

carlsson

    River Patroller

  • 4,679 posts
  • Location:Västerås, Sweden

Posted Fri Apr 21, 2017 7:52 AM

For being a virtual machine, I would believe TI BASIC is rather efficiently programmed. Yes, it is slower than most other micros (in the segment with Atari 8-bit and ZX Spectrum IIRC) but those had possibly more efficient CPUs, access to real RAM and being programmed in the native processor's language instead of being GPL, and still dragged behind other competitors.

 

I compared with the VTech Creativision, which has TI's VDP bunded with a 2 MHz 6502. It has BASIC on a cartridge that in its original form is far slower than TI BASIC is. Thus it shares two of the mentioned bottlenecks being low on CPU RAM and going through the VDP to access program RAM, but implements the language in 6502 directly without an extra layer. There were hacked versions bypassing part of the scanning routine I think to make it faster, breaking RND support along the way. I don't know about the SVI-318/328 (Z80), if those have a decent amount of CPU RAM so their BASIC doesn't have to use the VDP for storage. A computer like the Sord M5 (also Z80) on the other hand comes with near zero CPU RAM and its three different BASIC cartridges have onboard RAM, meaning the CPU will have to access the cartridge both for reading the interpreter ROM and storing the program and variables in RAM. I don't have figures nearby on its relative speed in benchmarks.

 

Generally I wonder if not routines for scanning the keyboard X number per second, possibly also other I/O is what dragged down many of those systems, so if one could turn off the display and input, the core functionality perhaps isn't that different between implementations.



#64 RXB OFFLINE  

RXB

    River Patroller

  • 2,721 posts
  • Location:Vancouver, Washington, USA

Posted Fri Apr 21, 2017 8:15 AM

For being a virtual machine, I would believe TI BASIC is rather efficiently programmed. Yes, it is slower than most other micros (in the segment with Atari 8-bit and ZX Spectrum IIRC) but those had possibly more efficient CPUs, access to real RAM and being programmed in the native processor's language instead of being GPL, and still dragged behind other competitors.

 

I compared with the VTech Creativision, which has TI's VDP bunded with a 2 MHz 6502. It has BASIC on a cartridge that in its original form is far slower than TI BASIC is. Thus it shares two of the mentioned bottlenecks being low on CPU RAM and going through the VDP to access program RAM, but implements the language in 6502 directly without an extra layer. There were hacked versions bypassing part of the scanning routine I think to make it faster, breaking RND support along the way. I don't know about the SVI-318/328 (Z80), if those have a decent amount of CPU RAM so their BASIC doesn't have to use the VDP for storage. A computer like the Sord M5 (also Z80) on the other hand comes with near zero CPU RAM and its three different BASIC cartridges have onboard RAM, meaning the CPU will have to access the cartridge both for reading the interpreter ROM and storing the program and variables in RAM. I don't have figures nearby on its relative speed in benchmarks.

 

Generally I wonder if not routines for scanning the keyboard X number per second, possibly also other I/O is what dragged down many of those systems, so if one could turn off the display and input, the core functionality perhaps isn't that different between implementations.

I have explained this over and over you did it elegantly for me.

Problems with TI99/4A  BASIC:

1. No RAM all run from Slow VDP under GPL.

2. GPL is not that slow compared to other languages but running from VDP mostly is a double whammy.

3. GPL runs from a very small compact amount of space many commands take up less space than the Assembly Language equivalent. Example: SCAN is a 1 byte command, XML Assembly is a 3 byte command.

4 TI BASIC only runs from VDP not RAM like XB can do.

 

(I think if GPL ran from RAM like C, or Forth it would give them a damn good run for the money.)



#65 Opry99er OFFLINE  

Opry99er

    Quadrunner

  • 8,246 posts
  • Location:Cookeville, TN

Posted Fri Apr 21, 2017 12:22 PM

The only reason I have not used the compiler as much as I would like is the IF THEN nuance. I use a ton of fairly involved IF-THEN statements in my code for variable manipulation, and to go back and re-write it for the compiler has been challenging.

I have contemplated developing specifically with the compiler in mind, but I usually end up just coding in regular XB.

I began coding a game called "Vector Hyperdrive" with the compiler in mind. Without being able to use the extended IF THEN statements became a problem for me. Not because the compiler is flawed, but because I have limitations as a coder. Stuck in a mindset, I guess.

The things I have seen done with the GDP from seniorfalcon are incredible, and I continue to be amazed by XB256. Retrospect is showing what can be done with some care and imagination, and I am blown away.


When I get my development environment set back up, I plan to get back to some game programming... I think I will start by trying to make a small XB demo with a scrolling window, using XB256 and the compiler. Just to see what is possible. :)

#66 Retrospect OFFLINE  

Retrospect

    Dragonstomper

  • 866 posts
  • Location:Wakefield, England

Posted Fri Apr 21, 2017 1:47 PM

I have a couple of points to add to this one ...

 

Why is TI Basic so slow?

 

Well, it just is.  It's been made by  a bunch of wizards that liked big numbers, you go to work out numbers to the power of, on a c64, speccy, atari and then the TI.  The TI will show you TWO further calculations before any "too large a number" errors occur.  

 

But you can help it along a little ...

 

By coding it all a certain way.  Imagine if you would, we have a TI-Basic "Bomber" game, with the plane and the city .... the plane moves 1 char at a time and moves down a row at the end , right? ... well I've seen one or two that are terrible.  Why so ... because after the plane moves, the bomb moves .... and it's a very noticeable pause too ... so instead, programmers should bare in mind to do all the calculations first, including conditions for IF there is a bomb present or not, and THEN draw all the characters in one hit.  Also putting a score display on the screen slows any TI Basic game down by at least 20 percent if not more, I'm probably being kind there!

 

Certain games don't help themselves.  I take my examples from stuff that came out in the UK during the 80s from little cottage-companies.  Bad coding means people look at it and think TI Basic and the TI on the whole are worse than they should be.  

 

And on Karsten's point that he hopes to see more TI Basic games being released, well, I've gotten it into my head that I want to make something for TI Basic.  I don't know what, but it'll happen, soonish. :)



#67 lucien2 OFFLINE  

lucien2

    Moonsweeper

  • 282 posts
  • Location:Switzerland

Posted Sun Apr 23, 2017 7:59 AM

Problem was it took hours to assemble even in Classic99.


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
 



#68 --- Ω --- OFFLINE  

--- Ω ---

    .....................

  • 10,360 posts
  • TI-99/4A Fanatic
  • Location:In the den playing with my FinalGROM 99!

Posted Sun Apr 23, 2017 6:10 PM

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.

 

 



#69 digdugnate OFFLINE  

digdugnate

    Moonsweeper

  • 488 posts
  • Location:SW Missouri

Posted Sun Apr 23, 2017 6:59 PM

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.

 

 

 

oh that's neat!  it kinda reminds me of a cross between Shamus and Robotron.   I remember messing with the CoCos at Radio Shack, but we never had any Tandy/Radio Shack stuff in our house until the late 80s (I think) with the Tandy 1000 EX.



#70 matthew180 OFFLINE  

matthew180

    River Patroller

  • 2,383 posts
  • Location:Castaic, California

Posted Sun Apr 23, 2017 7:04 PM

Let's say you're writing a new game and you haven't yet learned Assembly Language.

...

The days of having to climb Mount Assembler ...


The biggest problem with assembly language is the *idea and stigma* that it is somehow hard. A little more tedious, yes, but not harder.  The main difference between programming languages is how they abstract the mechanics of the computer and the details of the system.  In the case of assembly language there is no abstraction layer, so you need to know the details of the computer, how computers really work, and how the CPU interacts with the rest of the system.  That is the hard part really, and information you should know anyway (especially if you are writing games).

 

One of the nice things about learning to program the raw computer (aside from the speed and total control of the system) is that you then have an understanding of how higher level languages abstract things from you.  You can use that knowledge in higher level languages, making you a better programmer all around.

 

Also, since all stored-program computers fundamentally work the same, learning any computer system and assembly language will help you on other systems that have different CPUs and system architectures.  When I learned 9900 assembly back in the 80's, I learned skills that I still use today on modern computers and other classic systems.
 

Sure, one can always do better with Assembly Language programming. The BASIC compiler significantly empowers the less advanced coders is all!'


I don't disagree that the compiler will help make programs written in BASIC/XB faster, but I do disagree that assembly programmers are somehow more advanced than other programmers. The complexity of a program is the same no matter what language you write in, and games can be some of the most complex kinds of programs.

 

You can solve many programming problems using many different languages, and typically people pick what they already know rather than the right tool for the job.  On modern computers the actual language is becoming less and less important (even interpreted scripting languages are fast enough for most tasks), but IMO on old classic computers with limited memory and speed, assembly is the right tool for games.  Another nice advantage of old classic computers is that you can understand the whole system, and even maintain a mental model of the whole system.
 

The return on your investment here is significant!
...


As is the return on investment for learning to use assembly.  And the feeling you get when your assembly program runs and works is fantastic.  I remember being absolutely giddy watching my programs run when I was learning assembly.  It was great.



#71 --- Ω --- OFFLINE  

--- Ω ---

    .....................

  • 10,360 posts
  • TI-99/4A Fanatic
  • Location:In the den playing with my FinalGROM 99!

Posted Sun Apr 23, 2017 7:15 PM

 

oh that's neat!  it kinda reminds me of a cross between Shamus and Robotron.

 

YEP!   You know, looking back all those years, decades ago now, Robot Attack had to be my ABSOLUTE FAVORITE  game to play on the TRS-80... even with it's minimal graphics.



#72 Opry99er OFFLINE  

Opry99er

    Quadrunner

  • 8,246 posts
  • Location:Cookeville, TN

Posted Sun Apr 23, 2017 7:25 PM

Basically "Berzerk" isn't it?

#73 --- Ω --- OFFLINE  

--- Ω ---

    .....................

  • 10,360 posts
  • TI-99/4A Fanatic
  • Location:In the den playing with my FinalGROM 99!

Posted Sun Apr 23, 2017 7:43 PM

Basically "Berzerk" isn't it?

 

Yes, it is, but for some strange reason I like playing Robot Attack more on my TRS-80 emulator than on I do on my Atari 5200... which I bought in part just to play Berzerk.   I still have hope that 'someday' it will come to pass.

 

gallery_35324_1027_35966.jpg



#74 sometimes99er OFFLINE  

sometimes99er

    River Patroller

  • 3,907 posts
  • Location:Denmark

Posted Sun Apr 23, 2017 10:49 PM

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.

 
Yes, that looks like the TI game Shamus. Both Shamus and Robot Attack are inspired by the Berzerk arcade game. Ref. interview.
 
shamus5.png


Edited by sometimes99er, Sun Apr 23, 2017 10:59 PM.


#75 senior_falcon OFFLINE  

senior_falcon

    Dragonstomper

  • 908 posts
  • Location:Lansing, NY, USA

Posted Mon Apr 24, 2017 5:05 AM

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!






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users