Re: [stella] Star Fire 2600: Star Background

Subject: Re: [stella] Star Fire 2600: Star Background
From: Manuel Polik <cybergoth@xxxxxxxx>
Date: Thu, 01 Aug 2002 14:08:48 +0200
Hi Thomas!

>>The Star background is done with 1LK precission.

>IMO, a 2LK precission wouldn't be worse. Maybe even looking better
>because the shape is more square.

Hm... I'm not too sure about that. Consider that with 2LK precission for
that, you'd lose every second HMOVE, i.e. all stars would then sit on
only 3 instead of the current 6 diagonals.

It's hard to judge the result without actually trying, tough.

>> So I'd be still short of *calculates* ~ 8 cycles in that line... :-(

>You can save a lot of additional cycles if you wouldn't have to exchange 
>the contents of Y over and over.

>E.g. You could use an (adjustable) pointer for the crosshair (instead of 
>a fixed value) and (by using my "skipDraw" code) should be able to use 
>only one Y counter for the whole kernel. We already have discussed this 
>trick here during the development of Qb and Gunfight.

Yup, I know it well :-)

The thing is, I need one register for the repositioning loop. So I had
to make a choice what to put in the permanent register:

- The line counter or
- The # of the current sprite

When I had to make this decission, it looked like I needed the sprite
index way more often than the line counter. Maybe now the # of accesses
is shifted towards the line-counter, then swapping might gain something.

I've to check that. I must know the exact gain/loss of that before
trying such a major impact on the kernel. It is so fragile and relying
on single cycles at several points, so that tweaking the tables to work
again after such a change will most likely cost me several hours.
There's only a very small window where the kernel can work at all.
Not yet rocket sience, but coming close I think :-)

As for the crosshair, I certainly won't gain any cycles by doing it with
skipdraw, instead it'd make the problem only worse. 
No skipping logic can be quicker then:

LDA table, line

>> Hey, wow. You got me, the 'suicidal try & error coder' into *thinking*
>> about such things ;-)

>If found that thinking is often easier and faster than "try & error" :-)

I normally only start thinking, when 1-2 hours "try & error" don't
produce the desired result ;-)

Archives (includes files) at
Unsub & more at

Current Thread