This article is under construction and needs to be completed. You can help by expanding it.
The Basmic Campaign is dedicated to giving TI-BASIC programmers the credit they deserve for their programs.
URL: http://sicode.ticalc.org/basmic/
founded November 25, 1999
ended March 20, 2000
ticalc.org news article
http://www.ticalc.org/archives/news/articles/2/21/21502.html
SiCoDe Software Establishes Basmic
Posted by Nick on 25 November 1999, 21:12 GMT
SiCoDe Software has created a campaign to raise awareness about the high quality of many BASIC programs called Basmic. Its aim is "to spread the belief of [its] views through widespread support of [its] views by all major TI-related groups." Basmic would like to ask everyone in the TI community to support the fact that BASIC programs can be created of equal caliber and entertainment value to assembly. We wish both SiCoDe and Basmic well in their future endeavors.
in memory of
the campaign for TI-BASIC equality
1999 - 2000
On Monday 20th March 2000 the Basmic Campaign was officially disbanded.
It was felt by SiCoDe and many of Basmic's supporters that
the campaign failed to accurately convey its views, and did
not have a chance of meeting any of its objectives.
We apologize to those TI-BASIC programmers and users who put
their faith in our campaign's ability to bring about a change of attitude
in the TI Community towards TI-BASIC programming.
The battle may have been lost but the war is not yet over.
Have faith in TI-BASIC, and by programming only the best,
prove that it can be valid as a language.
Good luck and thanks to those who supported us.
We are sorry that Basmic couldn't make the difference.
— SiCoDe Software, on behalf of The Basmic Campaign
For those who want to know the actual performance of TI-BASIC programs, I (Patrick Davidson) have made a web page giving details on a performance test that I recently made. Even though the Basmic campaign does admit that BASIC is slower, they don't tell how much slower it is. That's what I have decided to do. The results I obtained are basically this:
For simply calculations/control structures, Z80 assembly is approximately 2100 times as fast as TI-BASIC on the TI-85.
http://pad.calc.org/basic.html
The Truth About TI-BASIC
Posted November 1999
By Patrick Davdson
Table of Contents:
Purpose of this page
Introduction to calculator languages
Test 1 - Simple Computations on TI-85 Result: Assembly is 2100 times as fast as BASIC
Purpose of This Page
This page is written to provide information on the various programming languages that can be used to program TI calculators. The performance test is done on the TI-85, but everything else should be useful towards all calculators. It was originally written to counter some false claims made in favor of TI-BASIC, but that's not the main point anymore.
Even though the performance test may suggest it, this page is not really intended to be a BASIC-bashing page at all. However, I do think that some people believe TI-BASIC is much better than it really is, so I will argue against these beliefs. Read the introduction for my complete analysis of each language.
In the future, this page may really serve a more valuable purpose, which is to raise awareness of the various compilers that exist for TI calculators, as I truly believe they don't get the attention they deserve.
Introduction to Calculator Programming Languages
Before I describe each language in detail, I think I need to point out that I am comparing languages, not programs. If you want to start programming, this is the very information you need (well, at least some of the information you need) to make your decisions. If you only want to use programs that already exist, this information is still of some use, but not the whole of it. To really decide which programs to use, you will need to try out all of the available ones, and judge each program on its own merit. If you follow these guidelines, you'll probably end up deciding to use more than one language with your calculator. For example, I use TI-BASIC whenever I want to write a math utility (however, I have only done very simple ones), but I almost always use only assembly for games (though there are 3 TI-BASIC games that I use occasionally).
TI-BASIC. This is the built-in programming language of the calculator. This language is easy to use, and is explained in detail in the calculator's manual. It can be programmed directly on the calculator. Programs written in TI-BASIC are interpreted by the code in the calculator's ROM. If you are trying to write a simple math program, this language is probably your best choice. Unfortunately, it is extremely slow and thus not useful for most types of games. Simple tunnel games, and some games such as "Tron" can, however, be done fairly well in BASIC (though I would recommend using the assembly versions instead, if available, as they would probably be better). However, games that are performance-intensive, such as all but the simplest Pong games, platform games, shoot-em-ups, Pac-Man imitations, and anything involving real-time 3D graphics will be much too slow written in BASIC. I also think that BASIC may be useful for turn-based RPGs, though I haven't looked into this in a great deal. Puzzle games might also be acceptable in BASIC.
Assembly Language. Programs can also be written in assembly language. These programs have to be assembled into machine code before they can run. Since they are run directly by the CPU instead of interpreted, they are much faster than BASIC programs can be. The speed difference can be anywhere from dozens to thousands of times. The TI-82, TI-83, TI-83 Plus, TI-85 and TI-86 have Zilog Z80 processors, and the TI-89, TI-92, and TI-92 Plus have Motorola 68000 processors. (Side note: These might actually be different processors, but with the same instruction sets and timings)
The capability to run custom machine code on TI calculators was first discovered on the TI-85 around the end of 1994. It was not supported by TI, and could not be run without installing a backup file containing modified data structures. Methods to run custom machine code were later discovered on the TI-92 and TI-82, also requiring the installation of modified backups. Later TI calculators (TI-83, TI-83 Plus, TI-83, TI-89, and TI-92 Plus) have built-in assembly support supplied by TI. This language cannot usually be programmed directly on the calculator (there are many exceptions to this, but generally such programs are written on computers). The Z80 and 68000 assembly languages are very different from each other, and both are more difficult than TI-BASIC.
Compilers. There are also several compilers for the calculators, some of which I will describe below. These compilers aren't very widely used. They appear to deserve much more recognition than they get. Even though people who already program in assembly have little need for them, they can be very useful for people who don't want to learn assembly, or don't like programming in assembly, as they have most of the benefits of assembly.
TI-GCC. This is a C compiler which produces 68K machine code programs. It is based on the GCC compiler ("GNU Compiler Collection", formerly "GNU C Compiler") which is a high-quality free compiler that produces well-optimized code for many processors. It was adapted by the developers of DoorsOS, and uses a specialized linker for producing executable files for the TI-89 and TI-92 Plus calculators. It does produce assembly sources during an intermediate stage, which can be preserved. These soruces are not in the same format as those for the A68K assembler that is normally used to assemble programs for these calculators.
GCC optimizes code very well, so there is little need to use assembly instead for performance. I have not yet examined it's 68000 code generation in detail, but I was quite amazed by the quality I've seen in its code for Intel x86 processors. It's very unlikely that anything more than a 25% performance increase would be gained over GCC code by hand-written assembly, if even that much. In fact, some people have made a strong case that GCC's code is better than assembly written by a human.
TI-GCC is based on the very same GCC that is widely used on computers. For example, GCC is the standard compiler on GNU/Linux systems. It is also the compiler that's at the core of DJGPP, which was used to make the DOS versions of Doom and Quake. Needless to say this makes it a full-featured C compiler, with the same syntax C programmers are accustomed to. However, you don't get a standard run-time library on the calculator.
UltraPascal. This is a Pascal compiler written by MXM Projects. It produces assembly source files for A68K, and can be used for the TI-89, TI-92, and TI-92 Plus. I haven't looked at this compiler in detail myself, but if you're a Pascal programmer it's probably something you should take a close look at.
Small C. This is a C compiler available for the TI-83, TI-85, and TI-86. This is only a subset of the full C language, so it won't give everything you expect from a full C compiler. In addition, I looked at the code it generates on the TI-85, and found it to be very inefficient. The TI-83 and TI-86 versions do include a peephole optimizer to run on the assembly source it generates, so things may be improved somewhat on those calculators (however, it still looks rather poor to me). These compilers will generate Z80 assembly source for the regular assemblers used on these calculators.
Test 1: Computation test for simple object movement
This test involves only very simple calculation and control structures, since these are what I think is the most serious performance problem with TI-BASIC; even if some of the TI-BASIC/Assembly combinations that some have suggested for things like sprites, it won't alleviat the core slowness of the simple stuff.
This test is designed to simulate a small part of a game. The program takes a list of the Y-coordinates of 20 objects, and decreases each of them by one if it's not already zero. This is similar to bullets in a shoot-em-up game, which would go up or down the screen until being off-screen, in which case they shouldn't be moved any more. Of course, this is a very simplified version, as it lacks collision-detection and assumes that all bullets are the same type, and considered non-existent when their coordinate is zero.
The speed was tested by calling the routines over and over on the same data. The same data set was used for both TI-BASIC and assembly. In both tests, the "overhead" (time to just set up each test but not do it) was measured separately and subtracted from the total to determine the running time of the routine. And now here are the results :
Program type Overhead Total time Test routine time Number of calls Time per call
Assembly 43 seconds 110 seconds 67 seconds 400,000 0.1675 milliseconds
TI-BASIC 12 seconds 154 seconds 142 seconds 400 355 milliseconds
Summary : Z80 Assembly is 2100 times as fast as TI-BASIC
This is the truth when it comes to testing the performance of these languages for simple computations, such as are often needed in games. In other tests I've done in the past (but don't have detailed information on anymore) the factor has come out as 900 times, or 2700 times, so it does seem that the difference varies depending on which calculations you're doing. However, it's clear that TI-BASIC is hundreds, if not thousands, of times slower than assembly for the simple calculations.
This will also differ between calculators. TI-BASIC may do better on some other calculators, but it will actually do worse on the TI-86. Some TI-BASIC advocates may think that I cheated by writing a low-quality TI-BASIC program. If that's the case, they're welcome to write their own better one and I will test that as well. It may be possible that they can improve on it somewhat, though I doubt it will make up for the observed difference.
Some people may also notice that the total overhead is lower for the TI-BASIC program. That is true, but remember that the assembly one was also called a thousand times as many times as the TI-BASIC one. Taking out the progress indicator, the TI-BASIC program's overhead is down to about 4 seconds. This would indicate that TI-BASIC is actually only about 90 times slower than assembly in the overhead needed to test the code, which is better than it did in the main test. This is to be expected, since that part is largely based on copying data, rather than doing any significant work.
And here is the complete assembly source code:
.include "usgard.h"
.db "Test program",0
call CLEARLCD
ld bc,40000
main_loop:
call &test_routine
call &test_routine
call &test_routine
call &test_routine
call &test_routine
call &test_routine
call &test_routine
call &test_routine
call &test_routine
call &test_routine
dec bc
ld a,b
or c
jr nz,main_loop
ret
test_routine:
push bc
ld hl,&initial_data
ld de,TEXT_MEM
ld bc,20
ldir
;-Actual routine being timed starts here
LD hl,TEXT_MEM
ld b,20
test_loop:
ld a,(hl)
dec a
jr c,already_zero
ld (hl),a
already_zero:
djnz test_loop
;-Actual routine being timed ends here
pop bc
ret
initial_data:
.db 5,8,0,0,45,32,0,0,15,0
.db 28,0,35,63,22,65,0,0,0,0
.end
And now for the TI-BASIC code:
PROGRAM:TEST
:ClLCD
:[5,8,0,0,45,32,0,0,15,0,28,0,35,63,22,65,0,0,0,0]->A
:For(X,1,400)
:A->B
:Outpt(1,1,X)
:For(Y,1,20)
:B(Y)-sign (B(Y))->B(Y)
:End
:end
Some TI-BASIC advocates might object that this is "unfair" testing, since the TI-BASIC program uses real numbers, while the assembly one uses 8-bit integers. This is somewhat true, but it also reflects the facts of game programming: assembly games can use integers, but TI-BASIC games use real numbers. I actually tried to make the TI-BASIC code being tested as fast as possible; I tried several ways, and found that subtracting the sign of the number is the fastest way to decrement it when not zero, slightly faster than using an If.
With regard to size, the TI-BASIC program actually takes up slightly more memory than the assembly one, even though it's source code is much shorter. Of course, it's quite a bit larger if you consider the size of its variables as well.
On a final note with regard to this BASIC program, I suppose I need to point out that there actually is a way to make it run faster than this. If you store the data as a list instead of a vector, you can run the necessary calculations on the whole list at once. That is, use "B-sign B->B" in place of the loop. However, the point of the test was to determine how fast things run when each object is processed separately. It just happens that this isn't necessary in this case, but it is necessary in actual practice, as this trick doesn't extend to testing for collisions, checking for the presence of walls, drawing objects, etc.
Even if we give TI-BASIC the benefit of the doubt and assume that it is fair to use that trick, it only speeds up the program 9 times. Therefore, TI-BASIC still comes out 240 times slower than assembly when this trick is used, so it can't really make up for the shortcomings of TI-BASIC.