In discussing "BCD compliant numbers" you need to make clear that for ANY number greater than nine, the result of adding to score will not be the "normal" result. For examle, if a=50, then saying "score=score+a" will add 32 to the score.

BTW, one thing that might be helpful would be an "add to score" function which could add or subtract a variable to the ones, tens, hundreds, thousands, ten-thousands, and maybe even hundred-thousands place.

I meant to reply, but I forgot until now. I still don't understand BCD compliant numbers, so it's hard for me to convert the info into something a little more understandable. I don't even understand what you posted there yet.

I've been using your page today and really like it. Since you did so much work, I thought maybe I would take a quick swing at BCD numbers for you.

Basically BCD numbers are 8 bit hexadecimal numbers, but only the ones that look like ordinary base 10 numbers are used. The CPU has a special mode that works with these numbers, as if they were actually base 10 numbers.

So lets take the number 15. In base 10, each digit is powers of 10. In binary it's powers of 2 and you know that looks like this: %0000 1111. And in hex, it looks like this: $0f. To understand BCD numbers, you need to know how hex numbers are represented in a byte. The bits of a byte can be divided evenly into nibbles, each nibble being 4 bits. Those 4 bits represent one of sixteen hexadecimal digits 0 - f.

BCD numbers are the hex numbers whose digits are only numbers, not letters. Getting back to the number 15 in BCD, it looks like this: $15.

If the cpu is not in bcd mode, and the program adds $5 to $15, the result would be $1f. If the cpu is in bcd mode, then the answer would be $20.

I put the '$' on the numbers to show they are hex numbers, representing the upper and lower nibbles of a byte in memory. --and they are, with the difference being how the CPU handles addition and subtraction operations.

Binary Decimal Hex BCD
0000 0000 0 $00 00
0000 0001 1 $01 01
.
.
.
0000 1001 9 $09 09
0000 1010 10 $0A 10 = 0001 0000
0000 1011 11 $0B 11 = 0001 0001
0000 1100 12 $0C 12 = 0001 0010
.
.
.
0001 0011 19 $13 19 = 0001 1001
0001 0100 20 $14 20 = 0010 0000

The number 10, in the little chart above is instructive because it shows the difference between ordinary hex, decimal and binary numbers. When the CPU is in BCD mode, adding 1 to the BCD number $09, results in the BCD number $10. The actual value of the bits, equal 16 however.

Counting up, works in the normal fashion until we again reach a number with a 9 for it's lower digit. Looking at the actual value of the bits for 19 BCD and 20 BCD shows a large jump that skips over all the other numbers that would have hex letter digits. ( $0a, $b0, etc...)

Looking at it another way, in hex only:

Hex Bcd
00 00
01 01
.
.
.
09 09
0a 10
0b 11

The whole point of this is to create a simple way for the CPU to be able to represent base 10 numbers and allow math operations to be done on them. It's wasteful because a byte can only hold numbers between 0 and 99 instead of the larger 0-255 range the binary and hex representations allow.

When working with large integer numbers, such as the scores in our games, BCD makes a lot of things really easy. When the program says score = score + 10, the CPU can easily add 10 to the score, without conversion.

Lets say the score is stored in two bytes. That would give us a score between 0 and 65535. Adding 10 means, converting the decimal number 10 to a binary/hex representation useable by the CPU. That number would be, $0a or 0000 1010. The add is then done, then the result needs to be shown on screen. Since the 2600 depends on shapes stored in the ROM, mapping each graphical, on screen image to the actual numerical digits is complex, without BCD. This means more math to convert the binary numbers into decimal ones and their pointers to the onscreen images.

With BCD, this whole process is simple because the digits useable by the CPU are easily mapped to the pointers necessary to graphically display the score. So adding 10 to the score really is just an add, with no other major steps being required. When the score is displayed on screen, the computer can read each digit of the score directly from the bytes it is contained in, while using them as pointers at the same time. Those same two bytes would hold a score range of 0000 - 9999, by comparison. Wasteful, but easy to work with from both a mathmatical and display point of view.

Wow, this got long. To sum this up, BCD numbers are used only when the CPU is in BCD arithmatic mode. The whole point of BCD is to allow easy binary representations of decimal numbers without having to do conversions back and forth. BCD wastes a lot of storage space however, because a lot of bits go unused. Bytes hold two digit BCD numbers 00 - 99, instead of the normal 0 - 255 ($00 - $ff) range they are capable of.

**Edited by potatohead, Mon Aug 8, 2005 4:26 AM.**