The built-in Basic language of the calculator is explained in thorough detail in the calculator's manual. I see no point in repeating any of the manual's detailed explanations here.
Assembly programs are almost always written on computers. Programs are normally created first as text files on a computer, which are then assembled to produce executable files that can be sent to the calculator and run. It is possible to develop assembly programs on the calculator, but this presents many additional problems.
Since assembly source files are nothing but text files with the assembly program written in them, they can be created and edited with any program that can edit text files: MS-DOS Edit, UltraEdit, PFE, emacs, vi, Windows Notepad, etc. There are various programs that will assemble these files and produce calculator executables. There are also some Windows programs specifically designed for calculator assembly programming which have built-in editors and also allow you to assemble from inside of them.
Note that for the TI-89, TI-89 Titanium, TI-92 Plus, and Voyage 200, high quality C compilers are available, so you can get good results without using assembly language if you know (or learn) C. See the C section for more.
Of course, you can't just write a program once and expect it to work perfectly; it's also necessary to debug the programs. Programs are often tested on computers with emulators before being tried on the calculator. Emulators are programs that simulate the functioning of the calculator on the computer. Since a new, untested assembly program has a much higher chance of failing, testing things on the calculator first is likely to cause your memory to be erased requiring you to re-send everything. However, for emulators on the computer, you can reload a previous copy of the simulated calculator's memory almost instantly. Using emulators also avoids wearing out your link cable by plugging in your link cable every time you want to send a slightly changed version of your program. Finally, most emulators include debuggers, which allow you to simulate each instruction of your program step-by-step to help you understand what is going on. The most up to date emulators are \ TiEmu (for the TI-89 and above) and TilEm (for the TI-86 and below). The most popular emulator is still the somewhat older Virtual TI. You can find information about even more emulators from ticalc.org's page on emulators.
The TI-82 through TI-86 all use the Z80 processor (or a compatible one), so they all have essentially the same assembly language. The only difference between them is the interface you have to use to the operating system and the keyboard and display. Likewise, the TI-89, TI-92, and TI-92+ all have a 68000 processor (or a compatible one) so they have the same level of similarity.
Also, note that assembly programs use so-called "include files" which give definitions of the memory addresses to use to access system variables and functions. These files should be "included" in your program, which means that when the assembly assembles your program, it will act as if the text of the include file were inserted where the include command is, so all the addresses will be defined and you can use them in your program. The include files are different for each calculator (except TI-89 and TI-92+), and standard ones usually are included with the development tools, so you can just use those without worrying about them (the development tools section will have some specific information on this).
The next sections of this document describe which programs are needed for development, how to learn assembly programming, and what documentation you can learn from.
As mentioned above, the first program you will need is a text editor. If you already have a favorite text editor, you should probably continue using it. If not, it doesn't really matter what editor you use, but you might want to consider one of the editors specifically designed for calculator assembly programming.
It is usually not necessary to understand the details of how the building process works; the building tools almost always include one simple program which automates the process.
To actually build assembly programs, you will usually need both an assembler and a linker. The assembler is the program which reads in your assembly source file and outputs binary machine code (and sometimes some other information as well). The linker is a program which converts the binary machine code for a particular program into an executable file usable on the calculator.
Note: the next two paragraphs explain details of the building process which beginning programmers don't need to understand at all. They are only here to explain some inner workings, and the feasibility of using or creating non- standard development tools.
When programming on Z80 calculators, programs are normally written to run at a constant address in memory. The output of an assembler is usually just the raw binary image, which must be copied to that address to work. The linker used in this case does nothing other than adding the header for TI Graph-Link files to this so they can be sent to the calculator. For this reason, you can use any Z80 assembler you want, as long as it outputs a raw binary image. However, it is probably a good idea to stick with the standard assemblers used by the TI community, as others expect slightly different source code formats. When building Usgard programs for the TI-85, the situation is slightly more complex as the programs don't have constant addresses; in this case, relocations must be marked in the source file, and the assembler outputs a list of these which the linker uses to build a relocation table.
For the 68K calculators, assemblers normally produce object modules, which contain not only the binary machine code image, but also relocation and symbol information. This is a more flexible system (allowing programs to be relocated and make a variety of external references), but requries you to use an assembler that supports the right output format, and makes the linkers more complicated.
Note that many of these building tools involve multiple programs, which will need to be able to locate each other. For this reason, you should make sure that all executables are somewhere in your path. Also, the TASM assembler (used in all Z80 calculators) needs a 'TASM80.TAB' file; you should set the TASMTABS environment variable to its location. Finally, it's a very good idea to always enter the directory your source file is in before you try to compile it.
Windows users can use all of the programs programs mentioned above. However, for many calculators, there are special Windows development tools as well, which usually have integrated editors from which you can assemble programs with just a few clicks. Here is a brief list of some of the more useful ones, certainly not complete:
If you are developing for Fargo II for the TI-92, then you can simply get the Fargo II Unix toolkit which includes everything you need to build programs for Fargo II.
There are many other Unix programs you can use. Beware that some of these development tools use assemblers with somewhat different syntaxes than are standard in the TI community, and may also be rather user-unfriendly. In my experience, if you want to assemble Z80 calculator programs under Linux, the easiest solution is probably to run the standard DOS tools with DOSEmu.
Since I don't use a Mac, I can't really say too much here. However, you can look in ticalc.org's Mac archives for some programs. Unfortunately, it doesn't seem as if they have a complete set of development tools for every calculator.
This section is intended to give general advice on how to learn assembly programming. It is not intended to teach you how to program, but only to explain the best way to learn. This is a subject on which different people have very different opinions, so no doubt some people will think this advice is all wrong. However, if you see any "advice" from someone saying stuff like the following:
| Hello, my name is [insert something or other] and I have been trying to learn to program assembly for several months. I'd like a little help with programming. Please don't tell me to do [insert something recommended in this FAQ] because I know it's better to [insert some ideas that this FAQ tells you to avoid]. Anyway I have been working on a [insert description of relatively simply program] and I think I've almost got it but I was wondering [insert a few questions which show the user lacks even a rudimentary understanding of programmin] ... |
you probably should trust this FAQ more, unless you really want to have to spend several months learning only the fundamentals of assembly programming. Keep in mind that I'm actually an experienced assembly programmer, and am advising you to do the things that worked best for me, and telling you to avoid the things that seem to cause the many problems I see beginners complaining about. Of course, even people who actually do know what they are talking about would probably disagree with me on some of these points.
And now onto my list of ideas, in no particular order:
It is probably a very bad idea to try to learn calculator assembly language before learning some other programming language. You will be much better off learning some other programming language first, as that way you will be able to gain some experience in converting ideas into actual programs. If you learn a high-level language first, then you will not need to focus on the details of the machine at the same time as you are learning to program.
It is probably a good idea to learn to program in C (or some very similar language) on the computer before you start trying to program in assembly language on your calculator. I actually didn't do this myself, but I think it is probably a good idea in general, as many concepts important to assembly are involved, such as structures and pointers. Since C is a widely-used programming language, you can find plenty of books on it in your local library or bookstore. You should pay attention to learning how to write your own programs, that is, how to work with variables, control structures, data structures, and pointers, not on learning "frills" like how to use various windowing systems or graphics libraries, as these things are useful only for their specific purpose, and not help you gain general understanding.
It may also help to learn assembly programming on a computer first, as the amount of resources available there will be greater than you have for the calculator. Most calculator assembly programmers didn't do this, but I did, and I think it helped me a lot. After learning assembly programming on computers (68000 and Intel x86), I was able to learn Z80 assembly for the TI-85 very quickly.
Many people try to learn assembly language after knowing only Basic. I am aware of people having done fairly well in this situation, but I am also aware of the problems it can lead to (especially if it is the calculator's version of Basic). If you do choose to try this, please pay attention to the sections I wrote below about the problems that are caused by trying to use basic-programming ideas in assembly so you can avoid them.
I am not aware of any books on programming specifically on calculator programming, but there are numerous books on assembly programming in general that should be helpful. The only book on assembly programming I ever read was Programming the 68000 published by Sybex, which seemed fairly helpful to me when I first started to program. The book Programming the Z80 by Rodney Zaks is considered useful by many people.
There are many sources of information on programming, all of which have their own advantages and disadvantages. The next section of this FAQ describes some of them in detail. In general, reference documents on the Z80 or 68000 instruction sets can be trusted as completely reliable. The hardware documentation for the calculator (describing the access to the screen, keyboard, link port, memory mapping, and interrupt control) is also highly reliable. Documents describing calculator ROM functions or structures in memory are also usually relibable, but may contain some errors. Tutorials are often of a lower quality, so be sure to use them carefully.
If you already know assembly programming on another platform, you probably can learn everything you need to know just from the reference documents I mentioned above, without having to read tutorials at all (I was able to do so). However, if you don't already know assembly programming on any system (or don't know it well) you will probably want to look at so-called tutorials, which don't just give information but try to teach you things.
Many people have reported that tutorials were useful, but you shouldn't expect to suddenly become an expert programmer just by reading a document. Keep in mind that some tutorials expect you to already have some basic understanding of programming, and others contain only descriptions of how to write very simple programs. Also be sure to look at the credentials of the author of the tutorial; if it is written by someone who has never released any significant assembly programs, the author probably is not well-equipped to teach you how to write significant programs yourself.
The next section of this FAQ gives pointers to various tutorials, and has a brief description of each.
Being able to program ultimately requires you to be able to figure out how to do things yourself in whatever programming language you are using. While you will need to read various documents to learn some of the basic information, you will gain skills mainly by programming yourself. While some tutorials describe how to do many different things, it's more important to be able to figure out how to do whatever task is needed for yourself.
Source code is available for many calculator programs, and you can examine it to try to learn some things about assembly programming. However, if you don't understand basic concepts of assembly programming, you may not be able to understand the source code you read.
Beware that much of the source code available is not very good. A sample program to display "Hello World!" may help you learn what header to use, and how to call the string display function, but that is about it. If you are trying to learn to do more complex things, you may run into worse programs, as many example programs for beginners are written by other beginners, who may distribute very low-quality code. These programs may have comments everywhere, but understanding how to write low-quality programs is not useful.
You can also see the source code to many large, complex programs. Unfortunately, these often do not include comments everywhere, and also may use very obscure techniques to improve performance that can make them even more confusing. Be sure to also keep in mind that even some large programs contain poor code.
When you first start learning to program in assembly, you should focus on the core ideas, rather than frills. That is, you should learn how to do calculations, access memory, build data structures, and control program flow first. Then you should start thinking about how to use these capabilities as efficiently as possible. The reason is that these are the main things you have to do to write useful programs.
Learning details about how to access various system functions or use complex routines supplied by others first will only slow down conceptual understanding, as it distracts you from these ideas. Of course, you will want to be able to have some way to interact with the user, probably using text/number display and key reading routines which will be supplied by others, but this should not be your focus.
Whenever you do use such external functions, don't fall into the trap of thinking of them as elementary operations. Displaying a line of text in memory may not take much more code from you than adding two numbers in registers, but you should always remember that displaying the text involves running a function written by someone else, and that it involves a huge number of the basic operations.
A large number of programming difficulties I hear beginning programmers complain about seem to be the result of thinking of assembly as similar to Basic (in particular, the calcultor's version of Basic).
One problem deals with what I mentioned in the last section; if you are used to programming in Basic, you may think of displaying a text string as being of the same level of complexity as adding two numbers, while in reality adding two numbers is many times simpler and faster. Another problem is that many of the ideas some people use to speed up Basic programs involve the exact opposite types of methods as would speed up assembly programs. Also, the data structures in Basic are quite different than you should use in assembly.
Trying to learn assembly equivalents to each operation in Basic is not very useful. The methods of designing assembly programs well are quite different from what is normally used in Basic, and even more different from the most efficient Basic programs.
If you program in the calculator's Basic language, every calculation you do will work with floating point numbers (or TI's expressions on the 68000 calculators) and all data is kept in system variables. These two things are among the main reasons why Basic is so slow, so you should certainly avoid them whenever you can.
In assembly programs, intermediate results of computations should always be kept in registers or memory that is directly accessed. Using the TIOS variable access mechanisms is much slower. If your program is a game, you should never need to use any of the system's variables, only data internal to your program, except possibly to access external level files or saved games and high score tables. In these cases you should just search for the variables to be used once, and once you've found their locations in memory, access data inside them directly using those pointers. If you are writing math programs, more interaction with variables will be needed, but you should still use the OP registers or expression stack as much as possible.
Floating point calculations are also slow, especially since the calculators have no built-in support for floating point calculations. Note that TI uses a BCD format for floating point values, which is even slower than regular binary floating point would be. If you are writing a game, you should never use TI's floating point routines at all. Most games can do everything needed with integers. If you must have fractional values, using fixed-point numbers is usually acceptable, and much faster than floating point. If you must use floating point, try to find some faster floating point libraries instead of using TI's, which probably have much more precision than you need (thus slowing them down) and also have the disadvantage of using BCD. If you are writing a math program, using floating point may be inevitable, but you should still try to limit it. For example, if you are writing a program to do 3D graphs, you may need to use TI's floating point routines to calculate each point on the object you want to draw. But if you want to display and rotate it, it is much better to convert each point's coordinates into fixed point values, as this will be much faster than continuing to use TI's floating point routines which will require you to do all of the slow calculations each time the object is redrawn.
It is actually possible to do assembly programming without this. However, since many operations that are useful are bit operations, understanding binary arithmetic will help a lot and allow you to write more efficient programs.
I consider it very important to understand how to work with bitmapped images, since that's what the calculator's screen is. You will need to understand this to write your own routines to handle the display.
Of course, you can just use the many display routines written by others. There are many programmers who do this. However, this is often a bad idea, as there are many cases where you'd want to do write your own routines to better fit your specific circumstances.
There is a great deal of documentation on ticalc.org of varying quality. For the TI-89, TI-92 Plus, and Voyage 200, the TIGCC documentation is farily thorough.
The TI-GCC SDK (for Windows) is a complete development environment for the TI-89 and TI-92+ in both C and assembly. There is also a Linux version which lacks the graphical IDE but has everything else. It includes both the GCC compiler (a highly optimizing C compiler that is the standard compiler on Linux, and also is the core of DJGPP, which was used to build the DOS versions of Doom and Quake) and GNU assembler, as well as the A68K assembler (which was historically the assembler of choice for most calcuatlor assembly programmers). It also includes an extensive library (including most of the functions of the standard C library as well as many calculator-specific functions and interfaces to system routines), thorough documentation of the library (and the use of TI-GCC for C and assembly programming), and an editor. This is clearly the system of choice for programming for these calculators.
TI-GCC 0.95 is the most recent C compiler for the calcuator that is marked as a release vesrion, but it is quite out of date. The "beta" version of TI-GCC (available on the TIGCC site) is more up-to-date, as is GCC4TI which is a fork of TIGCC.
There is also a Linux version of TI-GCC which also has the same compiler and library available.
There are some programming languages you can use for the calculators that I haven't mentioned here. If you want to try them, you can find the compilers on ticalc.org. However, I recommend against using them.
There are currently several C compilers for the Z80 calculators which are available from ticalc.org. They all have the common feature that they generate extremely inefficient code and most also don't come close to supporting all of the C language correctly.
There is also a Pascal compiler called UltraPascal for the 68K calculators. The code generated is usually of tolerable quality, but not nearly as good as you get from TI-GCC.