Lets talk about goals. If TI seriously plans on releasing this, they are advertising the Nspire. It is more expensive than the 84+ or the other z80 calcs. With this OS, TI would be forcing people to consider the Nspire and move away from the 84+ models.

Boycotting the Nspire would hurt TI and force them to give up their war with us. With people abandoning the 84 because of TI's antics, and people abandoning the Nspire because of the boycott, TI would see a staggering loss, since their z80 models are their highest selling models and the Nspire is the most expensive model. If we gathered enough support, it could be very effective.

If TI publishes this OS, we should definitely organize a boycott of TI hardware, telling people to not buy the Nspire. If they're trying to get Nspire sales, we hit them where it hurts--in the Nspire sales.

Perhaps this was TI's idea of an April Fools joke?

Perhaps a command to check a certain block of memory for variable bytes.

Search(PTR to start search,bytes to search for (more than one byte),number of bytes forward to search)

return 0 if not found, or offset of first result.

Ex: to clarify

in the block 013450AE2345FF000F ,

Search(PTR,[AE23],9)  returns 3

Also, if anyone would like to assist in writing sections in their area of specialty, like AI or collision detect, or interrupts, I welcome it and you will be cited as the author of the section.

I am working on a tutorial for Axe, with focus on game design, just like my TI-Basic one, which is now up on my website. Please read the sections of the tutorial as I post them below. Correct any technical mistakes, factual inaccuracies, and propose any add-ins. Thanks to the community.



Table of Contents


Chapter 1: Introduction to Axe Parser

   1.1: Using Axe
   1.2: Setup of an Axe program
   1.3: Memory Structure, with Respect to Axe

Chapter 2: Using Memory in Axe

   1.1: Variables
   1.2: Name Strings
   1.3: SafeRam areas
   1.4: Pointers
   1.5: Data Storage and Manipulation
   1.6: Archive memory and files
   1.7: Commands that deal with memory

Chapter 2: Axe, the Basics

   2.1: Text Display
   2.2: Drawing
   2.3: Using Jumps and Subroutines
   2.4: Control Blocks
   2.5: Mathematical Operations
   2.6: Commands for Basic Axe

Chapter 3: Constructing an Interface

   3.1: Saving Data
   3.2: Sprites
   3.3: Tiles and Tilemaps
   3.4: Collision Detect
   3.5: Key press/Input Detection
   3.6: Screen v. Buffer v. Back buffer
   3.7: Commands for Interface design

Chapter 4: Advanced Game Mechanics

   3.1: Real-time programming
   3.2: Artificial Intelligence
   3.3: Interrupts
   3.4: I/O linking in Axe
   3.5: CALCnet2.2 as a linking protocol



1.1:  Using Axe


Axe is a programming platform designed by Quigibo . It is currently in late beta stages. It is a Flash Application, compatible with the z80 line of calculators (TI-83+/84+). It allows you to compile your programs into z80 executables, much like true assembly is. Axe has a command syntax similar to TI-Basic, but it is much more powerful. Have a look at the Commands list, provided on the tutorials page, to see specific instructions that Axe currently supports.

What sets Axe aside from its programming counterparts? It’s ease of use, and its power, for a language so easy to use. This tutorial will delve into using Axe to design games. Then, it will explore using CALCnet2.2, the robust calculator network designed by Kerm Martian, to achieve multiplayer linking.




1.2: Setup of an Axe Program


Every Axe program must have a name, at it is written using the program editor provided by the TI-OS. It is important to give this program, called your “source program”, a name that is different than the name you want your executable to have. Let us first deal with the setup of an Axe program.

Every Axe source program needs a header that tells the Parser what to name the output file. This is done using the comment denoting character, “.”.

PROGRAM:AXSRC
.SOURCE

This causes the Parser to output the executable to a program named SOURCE. If you wish, you can include a description after the name. For example:

PROGRAM:AXSRC
.SOURCE an example program

This has the same result as the program above, but the second one has a small description. Henceforth, the Parser will completely ignore lines of code preceded by a period (.).

Axe Parser also has the capacity to compile programs for certain shells by including a specific header: DoorsCS, MirageOS, and ION. This may be set in the Options menu. If you choose not to compile for a shell, you may simply set the Parser to the “No Shell” option. Finally, the Parser gives one more option. For those who wish to be daring, the Parser can compile your code into an application. This code is very hackish, and is therefore inefficient. However, Quigibo has assured me that this compiling mechanism is stable, meaning it does not endanger sensitive parts of your calculator. However, this option should be avoided if it can be.

Programming in Axe has elements of both TI-Basic programming and assembly programming. Axe provides the ease of use of TI-Basic-like commands, making the language easy to learn and easier to code in. However, data in Axe functions like data in assembly. This means you must be familiar with the usage of pointers, referencing memory by bytes, and sometimes by bits. It means that you can do math with variables, because they are, in fact, simply numbers. All of this will be discussed later.



1.3: Memory Structure, with Respect to Axe


In Axe, none of the variables you regularly program with exist. All that exists is your code. You use the variables as pointers to data in your code, and thenceforth use those variables to reference the data. You have several variable sets available to you in Axe. These are listed below, by how they are named on calculator.

GDB0-9
Pic0-9
Str0-9

Furthermore, Axe supports longer names for these variables. You may annex up to two letters (A-Z) to the end of any one of the above to form a variable name. So, this means that all of the following are examples of valid names:

GDB0
GDB1A
GDB3CA
Pic4
Pic6N
Pic9AZ
Str6
Str9A
Str2VA

While these names look a lot like TI-Basic variables, they are not. They are simply pointers, used by the programmer to reference large segments of data. We will discuss the importance and usage of them later.

The memory of your calculator consists of a series of bits, utilizing binary numerals. There are eight ( bits in one (1) byte of memory. Similarly, there are two (2) hexadecimal numerals in one (1) byte of memory. Using Axe, you will need to know how to use and manipulate data in hexadecimal, especially if you are making tile-maps for an RPG. However, most of Axe’s commands accept input in standard decimal and Axe does provide conversionary tokens for input in hex and binary.

There are a few key things you need to know, going forward. You must read and write data directly to bytes either one byte at a time or two bytes at a time. This is because, in assembly, there are two types of numbers. There are one-byte numbers (0-255) and there are two-byte numbers (0-65536). These are positive numbers. If you underflow the stack of numbers, you move to the top and if you overflow it, you move to the bottom. There are ways to use negative numbers, and Axe makes it fairly trivial to do so. This will be discussed later.

Now, remember, as it is with assembly, there is a non-trivial difference between addresses and data. Each byte in memory has an address, starting at zero and continuing until the device runs out of memory. The offset from zero of a byte is its address. Thus, a byte at offset 200 would have an address of 200. This is not the same as the value of byte 200. Axe makes the difference easy to see. Let us assume that you have already stored the number 7 to the byte at 200. Well, you must store the value to a pointer.

200→C
C            ;   returns the address of the byte, 200.
{C}        ;   returns the value of the byte, 7.

In Axe, the curly brackets indicate that we are reading or writing data, not getting an address. They are very important.



Current Footnotes:

1  Kevin Horowitz, aka Quigibo is the designer of Axe Parser, and its programming platform. This tutorial borrows some material from the Official Documentation.

I don't think so, but you could talk to Kerm about how to implement it yourself On that note, I might try to put together a tutorial on linking if I can figure it out myself...

Kerm told me to nag you guys about it. 

Thank you. Are you sure this works?

Also, How would you construct a send/receive routine that exchanges a minimum of five bytes with another calc every time it runs, but makes sure that all data is successfully transferred? I have some ideas on this, but they all seem to fall apart when I think about the fact that the other calc may not actually receive the data.

Can someone give me some Axe code that causes a calculator to check for another calculator, if it finds one, it jumps to one label, if it doesn't it jumps to another. This must work even if the two calcs run the same code at the same time, because, in the final product, they will. You can then assign master/slave, but this is not a necessity.

Thanks.