[Coco] Let's figure out the best method to compile sprites for the CoCo - Please add your input

Richard Goedeken Richard at fascinationsoftware.com
Thu May 18 01:54:54 EDT 2017


Yeah I spent a lot of time working on this problem a couple of years ago.  The
code is all there on github.  The sprites are compiled by a python program,
and it does a ridiculous amount of computation to try and find the most
optimal 6809 assembly code.  The order in which you load the accumulators and
write out the pixels can save or lose you some cycles. For example you can
save some cycles if you finish one row with a value in A or B which will also
be used on the following row. For the indexed addressing mode, 5-bit offsets
are the smaller than 8-bit (compiled sprites take a lot of RAM), so you want
to position your row pointer in the horizontal center of the sprite and be
able to write to pixels in the [-16,+15] byte range for each row.  If a row
beneath the current row only has 1 or 2 bytes to be written, it's faster to
use 16-bit offsets and leave the index register alone than to update it to the
next row with "leax 256,x". For loading new pixel values into the accumulators
you can use coma/clra/deca/inca to save cycles/bytes if the new value is zero,
or the inverse, or plus/minus one, compared to the old value.  There are a lot
of crazy things you can do; all this stuff is implemented in my python script.

Richard


On 05/11/2017 03:49 AM, Dittel, Torsten wrote:
> ?For those interested in Sprites I recommend to have a look at Richard Goedeken's Game Engine "Dynosprite" here:
> https://github.com/richard42/dynosprite?
>
>
> Regards,
>
> Torsten
>
>




More information about the Coco mailing list