By Robert M (adapted by Duane Alan Hahn)
Table of Contents
Original Lesson
In lesson one we learned what a bit is. In lesson 2 we learned how to use bits to enumerate lists of items. In this lesson we are going to learn how to use bits to encode information.
Before we study codes, however, we need to take a detour and learn some new terminology. When we enumerated, we saw that with 1 bit we can enumerate 2 items 0 and 1. With 2 bits we can enumerate up to 4 items 00, 01, 10 and 11. So on and so on, such that given N bits we can enumerate up to 2^N items. As you can guess, it is a very common practice to combine bits together for the purpose of enumeration. Some combinations are used so frequently in programming that they have been given special names:
1 bit = a bit
3 bits = an Octet > Since it can enumerate 8 items.
4 bits = a nybble
8 bits = a byte
16 bits = a word
I will be using these terms in all future lessons so get comfortable with them now. For example the Atari 2600 has 128 bytes of RAM. How many bits is that? ANSWER: 128 bytes * 8 bits/byte = 1024 bits. What is RAM? Don't worry I will explain that in a later lesson.
If you are sharp eyed you may have noticed something about the naming of the bit strings above. Except for the octet each one is a power of 2! 2^0=1 (bit), 2^1=2(no name), 2^2=4(nybble), 2^3=8(byte), 2^4=16(word). This is no accident. Computers are based on bits and manipulate bits hence powers of two are a natural occurrence in digital computers. So these numbers appear very often in programming. As a programmer you will find there are advantages to using powers of 2 in your programming. The odd Octet will become clear in Lesson 4.
All enumerations are codes, but not all codes are enumerations. What does that mean? It means that enumerations are one type of binary code. In lesson 2, we enCODEd the type of fruit (Apple, orange, banana, cherry) using bits. What makes enumerations special codes is that they exactly match the binary numbering system used in computers for arithmetic so: Apple = 00 = zero, orange = 01 = one, banana = 10 = two, cherry = 11 = three. We don't have to encode our types of fruit that way we could encode them as Apple = 10110, Orange = 10000, bandana = 10111, cherry = 11000, but this is now a code and not an enumeration.
One of the most important codes you will become familiar with is Operation Codes. Every microprocessor (CPU) has what is called an instruction set or a set of operation codes. Operation codes is often abbreviated as opcodes. Operation codes are the executable (as opposed to pure information) part of your program. The hardware of the microprocessor reads each opcode in the sequence of the program and performs the action demanded. Later in this course we will explore all of the opcodes in the 6507 microprocessor (the processor in the Atari 2600) in detail. In the 6507 instruction set each opcode is 8bits long, or 1 byte. The opcodes are not an enumeration, they take all sorts of values using 8 bits within a byte often skipping many bit combinations that would make the code an enumeration. The bits set in each opcode were chosen because they simplified the work of the engineers to build the logic circuits in the microprocessor.
A gray code is a special kind of binary code of N bits. Gray codes are used for counting 0, 1, 2, 3, etc. Gray codes are special in that each time you add or subtract 1 from the code, only 1 bit will change. Here is an example of a 2bit gray code:
00 = zero
01 = one
11 = two
10 = three
00 = zero (pattern is repeating...)
You can see that only one bit changes as you count up or down through the 4 combinations. Gray codes are handy in situations where you want to minimize the amount of hardware needed to implement a counting circuit in a computer. In the Atari 2600, the driving controllers (Indy 500) use a 2 bit gray code to encode the direction the paddle is being turned, the speed at which the code changes indicates the speed the paddle is turning at.
Binary Coded Decimal or BCD is a method for storing decimal numbers in an easy (sometimes) to use format within a computer. You are already aware of decimal numbers you use them to count all the time: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, etc. In BCD each decimal digit is encoded into a separate nybble = 4 bits.
decimal = binary
0 = 0000
1 = 0001
2 = 0010
3 = 0011
4 = 0100
5 = 0101
6 = 0110
7 = 0111
8 = 1000
9 = 1001
Each byte contains 2 nybbles, so each byte can hold 2 BCD digits (00 to 99 decimal). This is an important code for you as a programmer because the 6507 processor has built in support for adding and subtracting BCD numbers. The big advantage for BCD numbers is that each digit is confined to its own nybble. It is therefore easier to isolate the individual digits for drawing them onto the screen. So scores are good candidates for being stored in BCD since you want to draw them on the screen as decimal digits. The big disadvantage for BCD is that you are wasting bits each BCD digit takes 4 bits which if used completely could store 16 values, 6 more than the 10 that it is being used for.
Programmers use alphanumeric codes to store text information used by their programs. Each letter, digit, and punctuation symbol is assigned a binary code. The minimum number of bits in the code is dependent on the desired number of characters used in your text strings. If you only want capital letters, numbers and the punctuation marks . Then you need 26+10+4 = 40 symbols, which requires 6 bits (from Lesson 2) per character in the string. Text manipulation is not a frequent activity for Atari 2600 games since the resources are so limited. Some games do display text. If your game will, then you need to decide between storing the strings as characters and then expanding them into the graphics to display on the screen, or store them in the cartridge already expanded and ready to display. Its a trade off between speed and storage space. We will explore such tradeoffs much, much later in the class.
There are 2 commonly used Alphanumeric codes for all computers. The first one is called ASCII. ASCII codes are 7 bits long. Therefore there are 128 symbols in the ASCII codes. Many documents on the Internet contain ASCII codes. You can recognize these files in Windows as the files with a .txt file type extension. When you write your assembly code programs the program you used to store your code files will most likely store them as ASCII codes. The other common alphanumeric code is the Unicode. Unicode is a 16bit code. It contains all the letters and symbols needed to display any known language in the world. ASCII has only the letters needed for English.
The examples above are just a few codes. An infinite number of codes is possible because as we learned in Lesson 1, the meaning of the bits is entirely up to the programmer writing the program. Please try the exercises below to cement these new ideas home
Here's a way to make a gray code of any length of bits. Start with a gray code for 1 bit =
0
1
To get a gray code of n+1 bits from a gray code of n bits simply repeat the n code followed (or preceded) by a single zero, then repeat the n code again in reverse followed by a single 1.
So from the above one bit code we get a two bit code as
0+0 = 00
1+0 = 10
Repeat 1 bit code in reverse.
1+1 = 11
0+1 = 01
Simply repeat this process to get a 3 bit gray code:
00+0 = 000
10+0 = 100
11+0 = 110
01+0 = 010
Repeat 2 bit code in reverse...
01+1 = 011
11+1 = 111
10+1 = 101
00+1 = 001
We know how many bits are in nybble and a word so we can convert from one to the other by converting words to bits and then bits to nybbles.
1 word = 16 bits
1 nybble = 4 bits
nybbles per word = 16/4 = 4 nybbles.
By our definitions there are 8 bits in a byte. So there will be:
512 * 8 = 4096 bits in 512 bytes.
Again we will convert from one unit to bits, and then from bits to the other unit.
72 nybbles * 4 (bits per nybble) = 288 bits
288 bits / 3 bits per octet = 96 octets.
First we count the total number of symbols possible for each character. AZ is 26 symbols. Space, period, question mark, and termination are 4 more symbols. 26 + 4 = 30 total possible symbols.
We can enumerate the symbols as we learned in lesson 2. The number of bits needed is
log(base2) 30 rounded up = 5 bits are needed per symbol in the string!
Now the second part of the question asked how many symbols will fit into 8 bytes worth of bits.
total bits = 8 bits per byte * 8 bytes = 64 bits.
Number of symbols in 8 bytes = 64 bits / 5 bits per symbol = 12.8 symbols
Not quite 13 symbols will fit into 8 bytes of space.
Other Assembly Language Tutorials
Be sure to check out the other assembly language tutorials and the general programming pages on this web site.


Lesson 3: Codes
How to get started writing 6502 assembly language. Includes a JavaScript 6502 assembler and simulator.
Atari Roots by Mark Andrews (Online Book)
This book was written in English, not computerese. It's written for Atari users, not for professional programmers (though they might find it useful).
Machine Language For Beginners by Richard Mansfield (Online Book)
This book only assumes a working knowledge of BASIC. It was designed to speak directly to the amateur programmer, the parttime computerist. It should help you make the transition from BASIC to machine language with relative ease.
The 6502 Instruction Set broken down into 6 groups.
Nice, simple instruction set in little boxes (not made out of tickytacky).
The Second Book Of Machine Language by Richard Mansfield (Online Book)
This book shows how to put together a large machine language program. All of the fundamentals were covered in Machine Language for Beginners. What remains is to put the rules to use by constructing a working program, to take the theory into the field and show how machine language is done.
An easytoread page from The Second Book Of Machine Language.
6502 Instruction Set with Examples
A useful page from Assembly Language Programming for the Atari Computers.
Continually strives to remain the largest and most complete source for 6502related information in the world.
By John Pickens. Updated by Bruce Clark.
Guide to 6502 Assembly Language Programming by Andrew Jacobs
Below are direct links to the most important pages.
Goes over each of the internal registers and their use.
Gives a summary of whole instruction set.
Describes each of the 6502 memory addressing modes.
Describes the complete instruction set in detail.
HTMLified version.
Nick Bensema's Guide to Cycle Counting on the Atari 2600
Cycle counting is an important aspect of Atari 2600 programming. It makes possible the positioning of sprites, the drawing of sixdigit scores, nonmirrored playfield graphics and many other cool TIA tricks that keep every game from looking like Combat.
How to Draw A Playfield by Nick Bensema
Atari 2600 programming is different from any other kind of programming in many ways. Just one of these ways is the flow of the program.
Cart Sizes and Bankswitching Methods by Kevin Horton
The "bankswitching bible." Also check out the Atari 2600 Fun Facts and Information Guide and this post about bankswitching by SeaGtGruff at AtariAge.
Atari 2600 programming specs (HTML version).
Atari 2600 Programming Page (AtariAge)
Links to useful information, tools, source code, and documentation.
Atari 2600 programming site based on Garon's "The Dig," which is now dead.
Includes interactive color charts, an NTSC/PAL color conversion tool, and Atari 2600 color compatibility tools that can help you quickly find colors that go great together.
The Atari 2600 Music and Sound Page
Adapted information and charts related to Atari 2600 music and sound.
A guide and a check list for finished carts.
A multiplatform Atari 2600 VCS emulator. It has a builtin debugger to help you with your works in progress or you can use it to study classic games.
A very good emulator that can also be embedded on your own web site so people can play the games you make online. It's much better than JStella.
If assembly language seems a little too hard, don't worry. You can always try to make Atari 2600 games the faster, easier way with batari Basic.
Disclaimer
View this page and any external web sites at your own risk. I am not responsible for any possible spiritual, emotional, physical, financial or any other damage to you, your friends, family, ancestors, or descendants in the past, present, or future, living or dead, in this dimension or any other.
Use any example programs at your own risk. I am not responsible if they blow up your computer or melt your Atari 2600. Use assembly language at your own risk. I am not responsible if assembly language makes you cry or gives you brain damage.