I got a bit stuck at the end of chapter 4 of Tom Pittman’s book “A Short Course in Programming“. Some of the concepts of registers become a bit hard to track but I think I have those fairly well figured out. Now onto a new tougher section; section 5. One nice thing about this section is the fact there is only one program to enter. Unfortunately it’s a bit of a monster compared to the previous programs. It spans almost 50 bytes! This program is one of the coolest so far though. It allows you to put in any opcode and then two bytes of data and see what the outcome is. The inner workings of the program (5.1) aren’t important here. The important thing to grasp is what all of these logic and arithmetic opcodes are actually doing. I will attempt to explain what I think the computer is doing as I figure that out myself.

One interesting note is that the 1802 is computing in binary but you are going to enter everything in hex and get all of your results back in hex. Follow this link if you need help converting between binary, decimal and hex.

**OR** – The first opcode that Tom refers to is OR. OR falls into the logic category. When I plug into the program *F1, 33, 55*, I get a value back of *77*. Same goes for *F1, 55, 33*. So what is the computer actually doing? 55+33 would be 88 so it’s not adding the numbers together, or is it?

It sort of is. If you break the numbers back out to binary, this is a little easier to follow:

55 = 0101 0101

33 = 0011 0011

77 = 0111 0111

If you look at the table above, you’ll see that OR is saying that if either of the bits is set to 1, then set to a 1. If both bits are set to 1, it’s still one. If both bits are 0, then it’s still 0. It’s comparing the numbers moreso than adding them together.

If you enter *F1, 33, 33,* you’ll get *33* because the bits are identical in both bytes so nothing will change.

Let’s test the theory on bigger numbers:

A9 = 1010 1001

DE = 1101 1110

Look at the table. You should easily see the answer if you understand this concept. The A byte corresponds with the D byte. There is a 1 for every spot so ORing them together nets a result of F or 1111. Now looking at the 9 byte and the E byte, there is also a 1 for every bit there so the result is F as well.

**AND** – The opcode for AND is F2. If OR made sense to you, AND should be a piece of cake. Let’s try our example of *F2, 33, 55*. The result is a very perplexing 11. Putting in *F2, 55, 33* will net the same result. Why? Let’s look at the binary for the answer:

33 = 0011 0011

55 = 0101 0101

11 = 0001 0001

AHA! The binary bits BOTH have to be set high in the same locations. 5 and 3 only share one common bit that is set high. That is the 1 bit. For the bonus round, how do you get a result returned of FF? It’s pretty easy when you think about it. FF has ALL bits set high. AND only returns a high bit if all corresponding bits are set high. So *F2, FF, FF = FF*. There is only one right answer for that question unlike the OR operations.

**XOR** – This only sounds scary and confusing because XOR (zor or x-or) is not a familiar word in the English language. The concept is really fairly simple when you look at it in binary. Once again, let’s pull up our trusty pair 33 & 55. *F3, 33, 55*:

33 = 0011 0011

55 = 0101 0101

66 = 0110 0110

HUH?!? Where did this 66 come from you say? Look closer. If one OR the other bit was set to 1, a 1 is returned. If both bits were set to 1, you get a 0 back. If both bits were set to 0, you get a 0 back. Make sense? Let’s test the theory on some more interesting numbers:

E9 =1110 1001

3A = 0011 1010

D3 = 1101 0011

FF = 1111 1111

00 = 0000 0000

FF = 1111 1111

This concludes part 1 of my post. In my next post, I will dissect the ORI, ANI & XRI operators. Should be interesting…