[Coco] More colors on CoCo 1?

[Roger Taylor]

As for the topic of displaying more colors on a CoCo, here's my take.

This is better for graphics display programs, such as Projector-3, 
and Sock's HiColor BMP viewer.

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.

On the flipside of that coin, a CoCo 1,2 screen of 128x192 and 4 
colors doesn't use up a lot of memory so you're not dealing with that 
big of a graphics array size to update.

Here's what I suggest, and it works great to boost the speed of any 
game.  PRE-COMPUTE as much math as you can that you find yourself 
doing in the middle of critical routines.  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.  Why use a MUL instruction 
to find a sprite's location in the data section when you can just 
load the sprite # into the A register and clear the B register.  The 
result is "sprite x 256 memory bytes" if the sprites take up 256 
bytes each.  No math needed at all!

ldd #sprites	point to start of sprite data table
adda	<sprite		point to the sprite # we want
tfr d,x		make a pointer to this sprite

X now points to the sprite image data you want to plot on the 
screen.  Just be sure to prestore those sprites on 256-byte 
boundaries even if they take up just 64 bytes each.

Also, ALWAYS use the SHIFT-LEFT/RIGHT opcodes to do quick x2 /2 
operations or x4 /4, x8 /8 , etc. as long as the total opcodes to do 
this don't use 11 cycles or more, and 10 cycles or more in 6309 
native mode.  Otherwise, you're taking more time than the MUL 
instruction will for the same operation.

On a 6809, or 6309 in 6809 mode, you can perform a "x32" operation on 
a number 1 cycle quicker than MUL can by issuing 5 LSL's in a row for 
the register being multiplied.  However, you can't do bigger than 7x32.
lslb lslb lslb lslb lslb  (same as x32) but uses 10 cycles instead of 11

If you want to do a x16 operation, you can go as big as 15x16 and do:
lslb lslb lslb lslb (same as x16) but uses 8 cycles instead of 11 !

If you want to do a x8 operation, you can go as big as 31x8 and do:
lslb lslb lslb (same as x8) but uses 6 cycles instead of 11 !

If you want to do a x4 operation, you can go as big as 63x4 and do:
lslb lslb (same as x4) but uses 4 cycles instead of 11 !

If you want to do a x2 operation, you can go as big as 127x2 and do:
lslb (same as x2) but uses 2 cycles instead of 11 !

As you can see, the cycles saved over the MUL instruction can be 
DRASTIC in games that need all the speed you can squeeze out, but 
remember about the 8-bit limitations.  Ofcourse, depending on how 
many cycles are saved in your shift sequences, you can shift any 
overflowed bits into the A register to support bigger results.