[Coco] More colors on CoCo 1?
operator at coco3.com
Wed Jan 24 16:15:29 EST 2007
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.
More information about the Coco