Part One:
Representing a Byte

    A few things must be known about numbers before you are able to program anything that you have not cut and pasted, or if you are to learn anything about how microprocessors work.  I have tried to make this section of the tutorial as to the point as possible because although this information is essential towards gaining basic knowledge of any assembly language, it is not central to the themes this tutorial.  If you don't understand this section 100%, please read it a second time, or as many times as it takes, before you continue on with the next sections.
    You probably know already that all a microprocessor consists of are binary digits, controlled by buses and gates.  Binary is the base 2 number system by which the microprocessor calculates, represented by either one (on) or zero (off); this information of on and off digits is contained in what is called a bit, each bit being capable of holding one unit of binary data.  Binary digits can be expanded (you can’t do much with one 1 or 0) so that when you put multiple bits together, you are able to store a very large range of numbers.  For example, 2 bits can store 4 numbers: 00, 01, 10, 11; and 3 bits can store 8 numbers: 000, 001, 010, 011, 100, 101, 110, 111.
    The most common way to store bits is in bytes, or in groups of eight; one byte can hold a value between 0 and 255.  To represent a number in binary, or in bits, we either precede the number with a % or follow it with a “b”.  %00000000, 00000000b and 0 all represent the same number -- zero.  Binary numbers are incremented by increasing bit 0 (each bit is numbered zero through seven starting with the bit on the right -- also referred to as the “lowest” bit; bit 7 is the “highest” bit); if bit 0 becomes zero after incrementing, then bit 1 is incremented, and if bit 2 becomes zero, bit 3 is incremented.  After incrementing %10011111 we will have %10100000, and %10100001 if it’s incremented a second time.
    There’s only one more scrap of important knowledge for you to procure in respect to the binary system of numbers, that is: how to store negative numbers.  A number always really constitutes the value you want it to, so if you view %11111111 as 0, that’s fine as long as all your numbers respect that view.  So if we want to treat the numbers 0 to 255 as -128 to +127, we will remain perfectly within walls of number system legality, assuming that we remain consistent.  The names for these two methods of representing 8 binary digits are signed and unsigned; signed denoting the system in which it is possible to represent negative values (-128 to +127), and unsigned denoting the system in which all values are positive (0 to 255).  Negative numbers decrement in the same way positive numbers decrement, with the only exception that they begin with all bits set: %11111111 is equivalent to both -1 and 255 in decimal; %11111110 is both -2 and 254 (from here forward, if a number is not preceded or followed by a special character referencing number system type, you can assume that it refers to a decimal number).  And one final aspect of signed numbers that you might wish to note is that a value can always be identified as positive or negative depending on whether or not the highest bit is set.  When bit 7 is 1, the number will be negative.

    Hexadecimal, also called “hex”, is another common number system, this time with a base of 16.  This means that a hex number will have to be incremented 16 times for each digit place before the number to the left of that place is incremented.  256 values can be stored in two hex digits -- rather nice when dealing with bytes.  It may strike you, however, that our Arabic numbers only cover a distance of 10 values: zero through nine; a problem which is fundamentally resolved by using the alphabet characters A through F in the place of the numbers 10 through 15.  A hex number’s semantics is also not yet complete without either a “$” before or a “h” behind the number.  Some examples are:  $a, ah = 10; $10, 10h = 16; $3b, 3bh = 59; $ff, ffh = 255;  $2d2, 2d2h = 722; $2d08, 2d08h = 11528; $ffff, ffffh = 65535.  Hexadecimal is the most prevalent number syntax you will see when programming assembly; review the examples and make sure you know this stuff fully well.  But, as always, if you get into a jam, your calculator can help you out with the conversions.

    Because numbers have little meaning to most programmers, something called an equate was introduced, assigning a name to number.  This is especially important when dealing with addresses, because while it’s difficult to remember many numeric addresses, you’ll always remember what is at a certain address.  For instance, _clrLCD (a routine to clear the LCD) tells you a lot more about a what’s at $4a7e than $4a7e alone will tell you.  An equate is defined in the following manner:

_clrLCD    equ    $4a7e
linkport     equ    7

    Even though equates are not an integral part of assembly language, they help to improve the readability of your code.  I strongly recommend the use of equates.

 The final representation of a byte that you will come across in assembly, is a character.  256 of the most used characters have been collected and standardized in what is known as the American Standardized Code for Information Interchange -- ASCII for short.  A character can be used in two ways: 1) a single character surrounded by single quotes: ‘A’, ‘!’, ‘7’, ‘w’, ‘@’, etc. 2) a string of characters surrounded by double quotes: “Hello!”, “How much money will you wager?”, “Created by Moon Unit Zappa”, etc.  Each one of the characters in a string is one byte in length ... even the spaces.  The characters are just another way of representing numbers, for example, ‘a’ is equal to $61 and ‘ ’ (space) is equal to $24.  TI’s ASCII is just a little different than standard PC ASCII.  TI needed to use characters that weren’t in the regular ASCII set, so they took out the lesser used characters and replaced them with things like the sto and conversion arrows.  All in all, though, the two are interchangeable and the important characters have the same hex equivalents in both sets.