Re: [stella] Skeleton - complete

Subject: Re: [stella] Skeleton - complete
From: "Eric Ball" <eball@xxxxxxxxxx>
Date: Tue, 10 Sep 2002 09:06:20 -0400
Hi Manuel!

> Ok, I see. How about doing smaller mazes for those kill-o-zap guys like

The 16x16 maze takes up one page, no more, no less.  It's related to how
movement works.  Impossible to change.

> Uhm... I've read that a few times now, but I don't get why the PAL
conversion should cause any severe space problems / table rearrangements.
Just adjust the number of WSYNCs for PAL to burn the additional lines away,
that shouldn't cost a single byte.

For a normal kernel, that may be true.  But the Skeleton kernel is based on
very large look up tables and heavy use of LDA (ZP),Y.  For every line on
the screen, I have 6 bytes of maze lookup.  And the skeleton player
graphics are also done for each visible line.  So for PAL, the active
screen increases by 20% from 190 lines to 228 lines, with a similar
increase in lookup table size.

Yes, it's space inefficient, but I found that I didn't have enough cycles
and registers to keep multiple counters going.  As it is, some of the
kernel uses X to help draw the horizontal lines.

Let me give you an example.  Grab your copy of skeleton.asm and follow

The kernel is unrolled into 20 line chunks.  Each chunk handles drawing one
set of walls.  There are three wall types: closed, open, and corridor.
Each chunk does basically the same thing.  Y is the line counter and is
also used as an index into the lookup tables.  A is typically used for LDA
(ZP),Y -> STA PFn, although there are some ANDs/ORs to handle the
horizontal lines.  X is used in delay loops, although it also gets used to
create the horizontal lines.

So the sequence is normally: lookup left wall, update PF registers as
required, check for Skeleton start/end & lookup/store if necessary.  Delay
to the middle of the screen.  Lookup/store the right wall PF, increment Y,
test for end of chunk & handle horizontal lines.

Each line is cycle counted in the comments, and most chunks I don't have
more than a couple of spare cycles before the STA WSYNC.  (And in KERN60, I
had to do some fancy footwork because I had to remove the delay loop
entirely from the draw skeleton path.)  (BTW the PVIEW4 subroutine is in
the middle of the kernel to shove KERN60/WAIT60 off the page boundary.)

Ideally, I would have multiple counters going:
- a line counter
- a maze index which would only be updated every n lines
- a skeleton index which would be updated depending on the distance

If I had the registers and cycles to keep these counters going then I could
significantly reduce the size of the lookup tables and simplify the PAL

The other problem is ensuring the location of the lookup tables doesn't
cause the LDA (ZP),Y to go over a page boundary.  This is particularly true
for the skeleton graphics, which need to be stored towards the end of a

Whew.  A long winded explanation for why PAL Skeleton isn't as simple as
you might think.  But I hope this helps everyone understand how Skeleton
works a little better.

Archives (includes files) at
Unsub & more at

Current Thread