15 replies to this topic

[grafixbmp]

Hello all. I thought I would throw in some simple pointer for new, up and comming programers who may have trouble wraping their heads around how base ten number relate to base two and base sixteen.

For many who have learned all their life about base 10, (10 fingers we have) it is sometimes hard to understand how to count with bianry and hexadecimal. I hope to help out where I can in this matter.

For starters, as many of us started out in school, we were tought how to count based upon how many fingers we have. This is the common way to count for many aspects of life ex: money, time, temprature, age, or any form of measurement.

Decimal:

There are some fundamentaly basic rules to how we count that we all were tought as well as to how it all works.

These are: when dealing with base 10 or decimal (same thing).we use 10 digits from 0 to 9

0 1 2 3 4 5 6 7 8 9

We also have place holders starting with the ones place, tens, hundreds, thousands, ten thousands, hundred thousands, and soforth

In order: Hundred Thousands | Ten Thousands | Thousands | Hundreds | Tens | Ones

When we count, we start at the ones place and work our way up. Always remember that the placeholders are always there but when there are no digits in the placeholders, it is implied that that placeholder is a zero.

So, with the ones place we start with 0 then 1 and all the way up to 9. But 9 is the last digit so we must start again but we also need to keep track of how many times we have gone through the cycle from 0 to 9. This is where the tens place comes in. After the 9 cycles back to 0 we place a 1 in the tens place and start the cycle from 0 to 9 all over again. When the second time through is complete, the tens place changes from a 1 to a 2 and soforth.

Once the tens place reaches a 9 itself we must then keep track of how many times we went through the tens place. After a 9 here and a 9 in the ones place we have 99 then the Hundreds place takes charge and becomes a 1 with both the Tens place and the Ones place starting back at 0's again. Which lead us to 100.

This is nothing new and you may feel I am being a idiot for taking everyone back to kindergarden with this but these rules are the same for all other counting bases.

Bianary:

With Binary, we only have 2 digits being 0 and 1

And likewise with decimal having 10 digits, the placeholders are based on multiples of this.
In decimal we satarted with the Ones place and jumped to the tens place because of the fact there are 10 digits to work with. Since there are only 2 digits with bianary, we need to follow a similar scheme.

The first place is the same as with decimal, The One place ( notice I said One and not Ones)

So lets start counting right away. 0 is 0 is 0. Nothing is diffrent here as is a 1 in the one place, but after this there is nomore and we must start over again. But like before we must keep track of how many times we have cycled through it so we have to put a 1 next to it and start the one place over at 0. This new place holder is the two place. This would look like 10. Since there is a 1 in the two place and 0 (nothing, zilch, nota) in the one place then we have the number 2 in bianary.

Well since the one place is a 0 we can count up to a 1 with it now so lets do it.

11

We now have a 1 in the two place and a 1 in the one place. What is 2 + 1 = ... 3
Well now. We now have 1 and 1 which can no longer go any higher so we need a new placeholder. This next one is the four place. And the next instance in our sequence woud be 100. With a 1 occupying the four place and nothing in the two or one place we obviously have '4' !

Yay. Isn't bianary counting fun?

If you can see a trend here it is that the place holders double in value as you go to the next one when viewing it as a decimal number. SO the next placeholder will be 8. We now have (in order) 8 4 2 1
And like before if we count only the placeholders with 1's occupying them, we have the bianary number in decimal. easy as that.

0000 0
0001 1
0010 2
0011 3
0100 4
0101 5
0110 6
0111 7
1000 8
~~~~~
1111 15

On a side note, when working with computers and dealing with the bianary that goes with them, we break down the information with terms that group certain amounts of digits together. A single solitary digit in bianary is a BIT.

On a lesser used term these days, when 4 bits are grouped together it is known as a nibble ane when 2 nibbles are grouped together you have a byte. As all of you know.

Hexadecimal:

Hex is actualy the easiest once you have gone though bianary. Reason being is that bianary and Hex (as is the way to call it for short) are so closely related that all computer these days use both bases to process data.

On another side note that really isn't prudent to this cause it never had a good purpose I guess, was the long forgotten Octal. This is just base 8 and serves nothing any longer as far as I know. I would love for someone who know what this base was used for to step in and discribe it here.

Now to Hex. Hex is known as base 16. However since normal decimal counting only goes as high as 9, new digits needed to be created or just use something we already have. This is where letters came into place when counting.
A B C D E F

which corespond in decimal to 10 11 12 13 14 15

Because of this counting method, Bianary values relate DIRECTLY to HEX.

With a byte we have 2 groups of 4 bits which when counted in bianary by themselves go as high as 15 in decimal. Hence one Hex digit. So we then have a high nibble and a low nibble. And if both of them are 15 then both are F. When they are read together we have FF which is viewed as 1111 1111 in bianary and as 255 in decimal.

In conclusion I hope this help some who may be struggling with understanding how these diffrent bases correspond to each other. I also hope I have not just been a skiping record where many others have done this before. If so, just take it for what it is worth.

As a bonus I will give a breif example of how to convert decimal to bianary by using subtraction.

First you need a decimal number. 87 This one will do.

Then check you placeholders in bianary 1 2 4 8 16 32 64 128 ... Well 128 is too high to accomodate this number so we will start with 64.

Subtract 64 from 87 and we have 23

Now 32 being the next one down will not subtract from 23 so we skip it by placing a zero in that placeholder. The next is 16. Now 16 will subtract from 23 and we then have 7
8 won't work so 0 for that one
4 will and that leaves us with 3
2 works with 1 remainding
and take away the last one with 1

There! Now place ones one each of the placeholders that you could subtract and zeros where you couldn't. You have

1010111

If we wrote this as a full byte it would be 01010111. And converting to HEX would be taking 0101 0111 and we would have 57 which is our HEX value.

Awesome stuff huh? Anyway happy coding!

Edited by grafixbmp, Mon Nov 24, 2008 11:14 PM.

[Omegamatrix]

Learning binary and Hex is critical to programming, absolutely. People might wonder why don’t we just stick with normal counting? Well, when you break down a computer to the simplest level it is has two conditions, yes and no. That can be 1 or 0, on or off, high or low, etc... At a hardware level this is easy to do with transistors. The transistor can act as a switch, and when you configure them in specific sequences you have logic circuits, or you can pile them into a grid to make up memory.

One idea I learned many years ago (and forgotten until school reminded me recently) is that multiplying is “fancy adding” and dividing is “fancy subtracting”. The idea is there is only adding or subtracting, and all you are doing is repeating that so many times. For example 4 x 6 is of course 24, but really it is actually 4 + 4 + 4 + 4 + 4 + 4, or four added six times. If you think it is the same thing then you have missed the point of unlearning what you have learned. A computer can not multiply, and it can not divide. In fact it can only add. When it subtracts it is using a form of addition called “two’s complement”, but that is a discussion for another day.

Binary is 1 and 0. It only has those two possible values. You start from the far right (the least significant bit) and work your way leftward. Each digit is to the power of 2. You simply add up the digits by the sum of weights.

A byte is eight bits. It can be divided into the “high” four bits (the 4 bits most left), and the “low” four bits (the 4 bits most right). A hex value is represented by 4 binary bits so:

bin	hex  dec
0000	0	0
0001	1	1
0010	2	2
0011	3	3
0100	4	4
0101	5	5
0110	6	6
0111	7	7
1000	8	8
1001	9	9
1010	A	10
1011	B	11
1100	C	12
1101	D	13
1110	E	14
1111	F	15

That means to translate a "binary byte", which is eight bits into hex you just split it into two 4 bit chunks. For example:

01101101 is eight bits (or a byte). Splitting it into two 4 bit chunks gives us:

0110 and 1101. Now we can change that into hex as 0110 = 6 and 1101 = D. That gives us:
6D for our byte, instead of writing 01101101. They are the same value, but 6D is just a "fancy" way of writing 01101101. By now you can see hex is much easier to work with as it takes less space to write.



Hex would usually be designated in our case as 0x6D (for languages such as C programming), or $6D, H'6D', 6Dh, 6D16, etc... It's just important to realize that the format is denoting Hex, not decimal. Also if you are reading assembly #$ and $ mean different things. #$ means load the literal hex value of, while $ alone means use address such...


Anyway hope this helps.

[ginnidog]

Still a little confusing to me..I`d like to learn 2600 programming..i only have some knowledge of HEX, thats it..but it seems
simple to learn over time..
thanks for the free class
Paulie

[grafixbmp]

Thanks Omegamatrix. Your addition helps greatly for moving on to the next part.

Relating all base number directly to the Atari or any other gameing system. The fundamentals are most always the same.

With all computing systems, we start with a CPU. With the Atari VCS/2600 we use a 6502 processor. But the processor is actualy a 6507. The diffrence is that the 6507 addresses less memory addresses than the 6502 but otherwise they are identical. We refer to the Atari CPU as a 6502 because they use the same opcode set and a deferential isn't needed. In order to address memory we need a memory reference value. This value is created with 4 hex digits. The range is from 0000 to FFFF. This is 00000000 00000000 to 11111111 11111111 in bianary and is 0 to 65535 in decimal. As you can see, this value takes up 2 bytes worth of space. But since the atari has a 6507, it takes the high byte and ignores the last 3 bits in the number. It would be like this XXX11111 This is the only real diffrence.

Each address location is a byte in size and certain ranges in this full range refrence diffrent parts of the Atari hardware. When a programer wants to affect changes in the Atari, an address is referenced and a value is placed there or pulled from there to the processor.

Each divided group of the whole is a gateway into a particular peice of atari hardware.
THe first part is the TIA. This custom chip is the heart of the players experience since it places the images on a TV and the sound to the speakers.

This range starts from 0000 and goes to 002C. This is the first part of the TIA where data is "wrote" to the chip and affects how the screen looks. This is also where the sound is controled.

from 0030 to 003D is where data is read from the TIA. This shows when screen graphics touch or cross paths and also gives readings of paddle controls and butons.

The next part of the hardware holds the RAM (random accsess memory) and controls the console buttons and switches. There is also a modifiable timer which can count by itself without any monitoring or control from the CPU. It only has to be set to a value and an interval of division. More on later.

This is a single chip called PIA /RIOT

The RAM is located from 0080 to 00FF

The rest of the chip is from 0280 to 0297

The game ROM (read only memory) itself rest from F000 to FFFF


As you can see some ranges aren't even set to anything or so it would seem. THe other ranges actualy point to these devices again. When a device can be referenced with more thanone range, the additional ranges are called mirrors.

Addresses are read using Hex values. It properly coresponds to computer arcitecture rather than trying to use decimal and is much easier to keep track of than using strait bianary.

The 6502 works with a byte at a time but it referenced addresses using 2 bytes since that's what it takes. In order to do this, it reads the 2 bytes in reverse. the last one first and the first one last. This is called little-endian format as Andrew Davie mentioned in his wonderful workshop tutorials.

That all for now. We can try manipulating bianary numbers next time.

[grafixbmp]

As Omegamatrix said earlier, transistors are used as switches to manipulate bianary data because it is the easiest device to do the job. When a microprocessor or CPU does what it does, these transistors switch on and off depending on the data they are using at a time. In order to properly get the results that are needing in a microprocessor, we need a special arrangement of these transistors to acheive it. These arangements are called "Logic circuits" In order get the specific results we want at a given instance the processor sends the data through these logic circuits and the outcome is the answer we want. Depending on what we are doing with the data also depends on which logic circuits are used. Most of this takes place without the intervention of the programer. The commands programers use are predetermined to use certain logic circuits to complete the task at hand.

The first of these we will cover is the AND. We will use single bits to illustrate this. This will show the basics but the same process applies to byte levels too. When one bit is ANDed to another bit there is a single bit answer and based upon what the 2 bits are, results with the outcome.

The AND rule is: when both the first bit AND the second bit are 1 then and answer is 1.

All other options are an answer of 0.

These outcomes are:

0 AND 0 is 0
1 AND 0 is 0
0 AND 1 is 0
1 AND 1 is 1

The second is OR. With this option either the first OR the second is 1 the answer is 1

These outcomes are:

0 OR 0 is 0
1 OR 0 is 1
0 OR 1 is 1
1 OR 1 is 1

The third is very close to the OR but with a twist. This is called the XOR (exclusive OR) This rule is as it sounds basicly when ONLY the condition of OR is met the the answer is 1

These outcomes are:

0 XOR 0 is 0
1 XOR 0 is 1
0 XOR 1 is 1
1 XOR 1 is 0

Notice that when the ORing is exceeded with the last option the answer is 0

The fourth and final logic circuit is actualy one normaly used in conjuction with the other 3 and this is called NOT. This basicaly reverses the answer we get on ALL options.

For AND this would be:

0 AND 0 Through NOT is 1
1 AND 0 Through NOT is 1
0 AND 1 Through NOT is 1
1 AND 1 Through NOT is 0

For OR this would be:

0 OR 0 Through NOT is 1
1 OR 0 Through NOT is 0
0 OR 1 Through NOT is 0
1 OR 1 Through NOT is 0

For XOR this would be:

0 XOR 0 Through NOT is 1
1 XOR 0 Through NOT is 0
0 XOR 1 Through NOT is 0
1 XOR 1 Through NOT is 1

This is the basic scheme for ALL processor. Without these logic circuits, computer would not be able to do what they do. In fact this idea of logic has been around far longer than computers have. If I remember my schooling correctly, this is called "Boolean algebra".

All opcodes used with the 6502 use many of these logic circuits aranged in diffrent patterns to acheive the outcomes we want when we program. In fact all processors do the same things, just others either do more of them per opcode or have more opcodes to use which would have diffrent and more elaborate pattern to acomplish what they are meant to do. And newer processors do this many many many... times faster.

And last but not least, you actualy have control enough to use these logic fuctions because there are opcodes taht do this raw form of computing with bytes at a time. You can have one byte ANDed, ORed, or XORed with another byte. Each bit is independently applied to the bit in the same placeholder of the other byte and the answer is stored in the place of the first byte.

Here is an examle of ANDed bytes


First: 00110101

second: 10101100
________
Answer: 00100100

In conclusion, this may bring you one step closer to becoming a great programer for the Atari 2600 or any other computer system.

I would also like to invite Omegamatrix back to explan "two's complement" subtraction to everyone (which is actualy addition).

[SpiceWare]

grafixbmp, on Fri Nov 21, 2008 1:33 AM, said:

On another side note that really isn't prudent to this cause it never had a good purpose I guess, was the long forgotten Octal. This is just base 8 and serves nothing any longer as far as I know. I would love for someone who know what this base was used for to step in and discribe it here.

While commonly defined as 8 bits, the definition of a byte really depends on the hardware. From wiki - byte

Quote

A contiguous sequence of bits within a binary computer that comprises the smallest addressable sub-field of the computer's natural word-size. That is, the smallest unit of binary data on which meaningful computation, or natural data boundaries, could be applied. For example, the CDC 6000 series scientific mainframes divided their 60-bit floating-point words into 10 six-bit bytes

Octal is very useful with 6-bit bytes as it's 3 binary digits grouped together so the full value can be represented by 2 octal digits, just like an 8-bit byte can be represented by 2 hex digits.

From wiki - Octal has a bit that display hardware was also a factor (early computers didn't have monitors)

Quote

At the time when octal originally became widely used in computing, systems such as the IBM mainframes employed 24-bit (or 36-bit) words. Octal was an ideal abbreviation of binary for these machines because eight (or twelve) digits could concisely display an entire machine word (each octal digit covering three binary digits). It also cut costs by allowing Nixie tubes, seven-segment displays, and calculators to be used for the operator consoles; where binary displays were too complex to use, decimal displays needed complex hardware to convert radixes, and hexadecimal displays needed to display letters.

Edited by SpiceWare, Tue Dec 2, 2008 12:08 PM.

[grafixbmp]

As the Atari runs through the bianary values, it needs to be able to distinguish one bit from another. It does this with a special kind of clock. Like the second hand on a clock ticks so does this one but far faster. THe main clock runs the TIA and the CPU clock runs at a third the speed of the main clock. This process works like that of a musician using a metronome.

The smallest possible spot on a TV that is running a signal from an atari is a pixel and in regarts to the clock, this is a single 'tick' of the TIA clock which is also known as a 'colour clock'. If a byte is loaded into one of the graphics registers of the TIA and a location on screen is chosen, then each 1 located in the byte will be represented as a colour clock of color for upto 8 colour clocks. With this method we can draw graphics on the screen.

The TIA only works with an area of the screen that stretches from the left side to the right side of the screen at a time. This is known as a scanline and once that line is done then a new one is created right below it. As a basic guideline or rule, the visiblle part of an atari image is around 192 scanlines starting from the top and going to the botom.

The CPU controls what the TIA is working with as it does what it does. However since the CPU runs at a slower rate, placing info where it is needed and have enough clocks to accomplish what you want is the most of the alure and challenge that attracts most if not all Atari 2600 programers.

The TIA has enough space to store data to effectively control a single scanline at a time. If this info isn't changed each scanline, then the info stays the same for every scanline effectively creating vertical bars or the likes of.

Most people don't realize that the image or space for an image is much greater that a tv makes it look. There are parts to the image of a TV that extend above below and to the side of each scanline in the image. This space is routinely used to work the CPU and work it hard. This allows us to change the info stored in the TIA so that when a new scanline starts, the image is diffrent. If all the changes that need to be made don't get done before the areas that are to be affected start drawing to the screen, then the screen usualy gets messed up.

With the atari, overall changes are made to a whole screen just slightly so that when the next screen is drawn, movement appears to be happening. When this is done constantly for each screen, you have the making of a game. The section of commands that are used to manipulate the TIA for the displaying process are called the "kernel". Most games use custom kernels because each game is diffrent and have to conform to what the programer want to happen for that particular game. As a single second passes so does 60 frames or images on the screen.

I will get deeper into this next time.

[Wickeycolumbus]

Sugestion: Its always helpful to have a scientific calculator that can convert bases for you handy when programming. I use a TI 36 solar, it was arround $20 but have seen it on sale for half that.

Edited by Wickeycolumbus, Fri Dec 19, 2008 5:21 PM.

[SeaGtGruff]

Wickeycolumbus, on Fri Dec 19, 2008 6:20 PM, said:

Sugestion: Its always helpful to have a scientific calculator that can convert bases for you handy when programming. I use a TI 36 solar, it was arround $20 but have seen it on sale for half that.

It's especially nice to have one for your computer. I don't know about other systems, but the Calculator program that's in Windows (under "Accessories" on the Start Menu) has an option to change the "View" to "Scientific," which switches from a normal (boring) calculator to one that can do hexadecimal, decimal, octal, and binary-- as well as changing back and forth between degrees, radians, and grads.

Michael

[grafixbmp]

SeaGtGruff, on Fri Dec 19, 2008 6:27 PM, said:

Wickeycolumbus, on Fri Dec 19, 2008 6:20 PM, said:

Sugestion: Its always helpful to have a scientific calculator that can convert bases for you handy when programming. I use a TI 36 solar, it was arround $20 but have seen it on sale for half that.

It's especially nice to have one for your computer. I don't know about other systems, but the Calculator program that's in Windows (under "Accessories" on the Start Menu) has an option to change the "View" to "Scientific," which switches from a normal (boring) calculator to one that can do hexadecimal, decimal, octal, and binary-- as well as changing back and forth between degrees, radians, and grads.

Michael

Just as the Atari does logic operations so does the Windows calculator as well. OR AND XOR and NOT. You can test all the things in this topic with the scientific calculator in Windows. This can get one use to how dealing with HEX and Bianary relates back to decimal.

Now that would be an intresting idea. A scientific calculator programed for the Atari 2600.

[grafixbmp]

I do want to thank Wickeycolumbus and SeaGtGruff for adding the usage of a scientific calculator. I actually forgot all about it. I use it quite a bit but never really thought about that here. The calculator can somewhat take away from the learning of how the process works but once that is achieved, then the calculator is AWESOME. But by the same token, a calculator can show realtime how the processes work so they do work best going hand-in-hand. Especialy when actualy starting a project cause you don't want to miss calculate and get the equasions wrong in your program. It ultimately depends on how best someone learns things.

[grafixbmp]

One nice thing about working with the Atari is that when you store values and such, you can either do strait bianary values or hex or even just a plain number. But you must sign it as such. %, $ etc.

There is the one mode you should want to avoid unless you intend to use it specificaly, BCD. This type of value stores the numbers diffrently anyway. This keeps classic decimal intact as to how it is stored. This counts as high as 99 all the way down to 00. This is used commonly with score keeping with 3 bytes you have a 6 digit score.

But te other methods are rather interchangeable I would think. Can I get a confirm on this?

[SeaGtGruff]

grafixbmp, on Mon Mar 23, 2009 1:48 AM, said:

One nice thing about working with the Atari is that when you store values and such, you can either do strait bianary values or hex or even just a plain number. But you must sign it as such. %, $ etc.

There is the one mode you should want to avoid unless you intend to use it specificaly, BCD. This type of value stores the numbers diffrently anyway. This keeps classic decimal intact as to how it is stored. This counts as high as 99 all the way down to 00. This is used commonly with score keeping with 3 bytes you have a 6 digit score.

But te other methods are rather interchangeable I would think. Can I get a confirm on this?

Yes, you can use binary, hexadecimal, and decimal interchangeably-- as long as the numbers are converted correctly, of course. For example, if you want to set COLUP0 (color and luminance of player 0) to red-- supposing "red" to be hue 4, luminance 4-- you can use [edit: the following is in batari Basic notation, because I thought this was the bB forum when I started replying]

a = %01000100
a = $44
a = 68

depending on whether you want to use binary, hexadecimal, or decimal.

Just a couple of very brief comments to add to what you wrote:

There's another mode you can use-- octal-- because DASM recognizes octal numbers as well, although I don't want to go into what it is or how to use it (and in my opinion, octal or "base 8" numbers don't have as much usefulness anyway, at least not for the Atari).

And BCD numbers are usually typed as hexadecimal numbers-- e.g., 99 in BCD would be $99-- although the only time you'd normally have a reason to use BCD in Atari programming is if you're doing a score, since it lets you "pack" two decimal digits into one byte (in fact, BCD is called "packed decimal" in some computer languages).

Michael

Edited by SeaGtGruff, Mon Mar 23, 2009 5:46 AM.

[grafixbmp]

It's been a long minute since I posted to this subject but with my current work I felt it was something I could add to the mix. This is more of a guideline than cold numbers.

You may read many times from seasoned programmers that they need to "optimize the code" or similar. Well, what does this mean? Here are a few examples of what I think is a part of it. However I know I will miss something so I hope others can fill the gaps and probably teach me a few things as well.

Eliminate Redundancy

A lot of times it can pay off to do this as you code but sometimes it can be overlooked too. I feel this has alot to do with "keeping track" of things.

When any value needs to be worked for any reason, it is loaded into a CPU register (usually all the time).

A = accumulator (This is known as the 'work horse' because it is the only one that can do the mathematics)

X = Index register (This is more or less a movable value that is mostly used for a reference)

Y = Index register (Mostly like the x register)

With the X and Y index registers you can:

store a value, load a value, or just temporarily hold it for a while. You can displace it's current value up or down by a factor of 1

Both X and Y's primary function is to work in conjunction with the accumulator by off-setting a memory location that the accumulator is referencing to load or store. the location is given and the index register being used is added to the location thereby allowing the programmer to scale across memory addresses with a single value from the index register(s).

This process has other detailed forms of the same type thing and depending on which form is used also affects the amount of time it takes to complete.

I say all of this to lay the foundation for reduced redundancy like this. These are the main workers of the programs programmers create. That is just the way it works. But there are only these and a few other task specific regiters to use. So lets make the best of them.

As a rule-of-thumb most all programmers use the Y index as a way to keep track of the current scanline being created on screen. Because of this, many things that need to be kept track of can be and mostly are tied to this value. There is no need to reinvent what already works.

The Big Squeeze

During game processes that happen in the background, it is a common thing to seek out any way to do the most tasks in the shortest amount of time. Sometimes this works great with quirks of the atari itself. If a normal operation has a little bug or effect that happens at a time when you need to stop doing something or start something, This can work great as a flag.

Sometimes there can be a dozen ways to do the same thing but only one is more effecient than the others at doing it when it comes to Time taken, RAM used, Or ROM used.

It usually goes this route when a programmer is tight on clock cycles that they go through this process of getting the "Most bang for their buck". This (to me) is a big chunk of what optimizing is.


RAM "Waste not want not"


Always reuse RAM addresses when what they contain is no longer needed anywhere else. Always be aware what RAM you use, when you use it, and if what it contains will be needed again. And when There are no more RAM addresses to use... improvise. Other places in the system, given certain provisions, can be used to temp store values.

Thanks for listening and hope to hear from readers soon. Be back again with more.

[Omegamatrix]

Being clever about what ram is used when can save you a few bytes of temp ram. Some ram locations can also me be multiused.

For example, if you have a ram register that only stores colors, than you can use bit 0 for something else. Bit 0 doesn't matter to any of the color registers. So in other words you can make use of that bit.

i.e. here I've merged a color register with a flag, to determine if I want to do a sound effect or not.

lda  colorRacingCar   ; but we don't actually don't want the color here...
lsr                   ; move bit 0 into carry
bcc  .skipEngineVolume
lda  #6
sta  AUDV0
.skipEngineVolume

;... code continues.

The consequence to this is:

a) All your colors have to be even numbered, ie the last digit ends in 0,2,4,6,8,A,C,D. (This is easy to do)
b) You got to preserve that bit whenever you update the colors. This will cost you some rom.

ex preserving bit 0, bit 0 could be set or clear, we don't know... but we want it to remain as is.

ldy  colorIndex
lsr  colorRacingCar  ; move bit 0 into carry
lda  CarColorTable,Y ; note all colors in the table have bit 0 as zero!!
adc  #0              ; bit 0 is reset
sta  colorRacingCar  ; to be used sometime later in routine...
sta  COLUP0          ; color register doesn't care about bit 0

You could also save some rom by "fixing" your color table ahead of time by shifting everyting to the right by 1.

ldy  colorIndex
lsr  colorRacingCar  ; move bit 0 into carry
lda  CarColorTable,Y ; 
rol                  ; bit 0 is reset, save a byte of rom!
sta  colorRacingCar  ; to be used sometime later in routine...
sta  COLUP0          ; color register doesn't care about bit 0

[grafixbmp]

I like that you brought that up Omegamatrix. I once asked others to share their own personal favorites of the method(s) you mentioned but didn't really get much feedback then. This was it:

http://www.atariage....s-with-1-stone/