[Coco] More colors on CoCo 1?

[John Kowalski]

At 03:15 PM 24/01/2007 -0600, CoCoList for Color Computer Enthusiasts wrote:

>If you try color mixing tricks with games, you're losing CPU time to 
>the video routines that the game code needs more.  So what you will 
>be faced with is trying to squeeze CPU cycles out of your game code 
>to make up for the loss.  It's already hard enough to write a CoCo 
>game with fast animation without using video tricks, so expect a challenge.

There are some cases where you could get a "hicolor" effect practically for
free when it concerns CPU cycles (as long as you omit updating the palette
registers every scan line, that is..)

For example:  If a game is intended to run at 60 frames per second and uses
double buffering.
All that would be required would be that both screen buffers contain
alternate sets of the same graphics.  Any time the cpu/game writes to buffer
#1, it uses graphics set #1 as source data and when it writes to buffer #2
it uses set #2.

The game graphics themselves could be entirely predrawn/precalculated with
the extra perceived colors.

As long as the game is running at 60 frames per second and switching between
the two buffers, you'll have the potential for 136 colors onscreen instead
of the usual 16.  The only cost is the extra RAM required to contain two
sets of source graphics (sprites, etc..) for the game instead of one.

>Why perform a slow 
>MUL(tiply) opcode on X,Y to figure where the screen byte is for 
>something when you can use a lookup table.

Another neat trick is to use the 256 byte wide virtual screen mode instead
of the normal 320x200 (160 byte wide) mode.   This way, Y is simply the MSB
of the memory address and X>>1 is the LSB.  No multiplication or lookup
tables required!

Speaking of using shifts instead of MUL.  I also sometimes (mis)use 6809
opcodes for purposes other than their original intention :)   Did you know
that you can do the equivalent of TFR X,Y by using LEAY ,X instead?  Same
result but it's 2 cycles faster.  Might not come in handy very often, but
there are a number of other cases where using the "wrong" opcodes will
perform the same operation, only faster.

I'm still a big fan of the MUL opcode, by the way.  And ABX too!

                                         John Kowalski (Sock Master)
                                         http://www.axess.com/twilight/sock/