Re[2]: [stella] I did it!(SFCaves 2600)

Subject: Re[2]: [stella] I did it!(SFCaves 2600)
From: Thomas Jentzsch <tjentzsch@xxxxxx>
Date: Tue, 3 Oct 2000 11:41:30 +0100
Mark wrote:
>> - If you have the chance to determine (from the contents of X and Y),
>> if the left/right half of the line is full/empty you could gain some
>> extra time (i did this in Thrust)

MDS> Yes, there will be many lines that are full, but once I get this free
MDS> time, what do I do with it?  The player objects are never drawn on lines
MDS> that are full.  There will be few lines that are all empty, and the player
MDS> objects will be drawn on those, but also partially filled lines.

Ok, i will try to explain more detailed what i mean:

In your current scheme, a half playfield line can only
look like this (this is exactly as in my Thrust-kernel,
except for number 4, which is not possible):

1 |-------     |
2 |     -------|
3 |---     ----| bottom only
4 |    ----    | top only
5 |            |
6 |------------|

Each of these halves can be only combined in a very
limited way. The resulting matrix shows this:

  | 1 2 3 4 5 6
1 | - x - - x x
2 | x - - - x x
3 | - - - - - x
4 | - - - - x -
5 | x x - x x x
6 | x x x - x x

If you look at it, you will see, that it is never
necessary to do the AND/OR on both halves. You can
reduce the problem to the following three cases.
a. The line goes on and off in different halves (1,2).
   -> you don't need any ANDs/ORs, just store the data
   of the correct tables for both halves.
b. The line goes on and off in the same half (3,4).
   -> AND/OR one half, the other half is simply $FF/$00
c. The state of the line never changes.
   -> this is simply a special case of a. or b.

Normally you would need at least 66(=6*11) cycles to do
the calculations for both halves. In case a. this can
be reduced down to 42(=6*7) cycles, case b. needs 44
(=3*11+11) cycles. If you add the overhead for the
determination of the case, you will *never* need more
than about 55 cycles/line.

This will make your kernel far more complicated, but
gives you a total of 22 free cycles each four lines.
And you are always short of time, when designing a nice
kernel for the 2600.
Think about a colour striped and cycling, single line
resolution player object, or a different colour for
each playfield line... :-)

I hope this may help you (and others?).

Archives (includes files) at
Unsub & more at

Current Thread