Re: [stella] Qb/Demo background animation (very rudimentary)

[Manuel Polik <manuel.polik@xxxxxxxxxxx>]

Hi again Andrew!

> Here's a newer version.  The target display (top right) is now functional,
> and you can move 'cubes' around (only the one at top left at start-up,
> though).  This demo so far is all background.  As soon as I can find my
> manual... I'll start tackling sprites.  

Are you sure you sent the correct binary?
On Z26 I experience timing problems and the target display seems to be
random, more or less. (See attached GIF)

> Source code is included in this post
> (enjoy!), and as you can see I seem to have HEAPS of processing time
> available for sprites, etc., during the kernal display.

I spent some hours yesterday reading & tweaking it, really a great job
so far. 
(I was even stunned by some DASM features I didn't know like REPEAT -
REPEND)

Some thoughts:
Sooner or later you'll have to do ROM optimisation. For example I found
you're using a complete 256 byte table with the numbers from 0 to 255.
It's only acessed for incrementing by 3:

        lda next+3,x
        cmp #8*3 ;PFSIZE
        bcs nn
        jmp nexlin0

Just replace that with:

	inx
	inx
	inx
        cpx #8*3 ;PFSIZE
        bcs nn
        jmp nexlin0

(You might need to skip one of the NOPS in the code above that, to fix
the timing. (Philosophical question: Are 2 cycles worth 256 Bytes of
ROM? :-))

The code for drawing the 6 top and bottom lines is copied 6 times in the
ROM. It can easily be put in a subroutine. (You can't do that with the
more timing critical action-field, of course.)

I tried these two things yesterday, freeing nearly 1K of ROM space!!

For the RAM issues: It'd of course be easy to free lots of RAM, if the
blocks would *teleport* instead of *move*
Even if they'd only move vertically and teleport horizontally would free
38 Bytes.

But you've still ~ 40 bytes RAM left, I think this might be enough for
the sprites anyway.

Another thing: I bet that the blank lines in both PF frames will cause
you lots of troubles sooner or later. You'll see that, when running out
of ROM, this effect will steal lot's of prescious cycles... 
At the moment it just wastes some hundreds of Bytes, but I guess you'll
need 'em soon :-)
(Maybe it'd already help a lot to change the PF pattern only every three
lines instead of every line, just popped to my mind. Judging from your
6x6 pixel PF resolution, a single line PF update is such a great waste
of cycles & ROM...)

I hope you don't take this as criticism about your programming style
(which it isn't), it's just some (maybe helpful) thoughts to keep you
going :-)

Can't wait for the next update,
	greetings,
		Manuel