Re: [stella] Visual questions

Subject: Re: [stella] Visual questions
From: Erik Mooney <emooney@xxxxxxxxxxxxxxxx>
Date: Tue, 25 Jul 2000 09:40:47 -0400 (EDT)
> When talking about a byte, the numbering is like this, right?
> 128 	64 	32 	16 	8 	4 	2 	1
> What about the bit numbering?  Does it go from left to right or right to left?

Correct.  The bits are numbered right to left - bit0 is the one with the
value of 1.  Two to the power of the number of the bit is the decimal
value of the bit (2^0 = 1, 2^1 = 2, etc.)

> So when drawing player sprites for use in memory by using graph paper, what 
> you see is what you get on the screen if you feed it numbers like the 
> above, ala:
> X X X X X X X X = 255
> X 0 0 0 0 0 0 0 = 128
> X 0 0 0 0 0 X 0 = 130
> etc?

Right.  Although just about all programmers just leave the numbers in
binary in the source code, and never worry about the decimal values.
> Also, how I'm going to explain VDEL is that it has the net effect of 
> shifting sprites down a single scanline.  So if you want to move a sprite 
> up a single scanline, you move it up a full scanline (since it's a 2 line 
> kernel) and enable VDEL, the next frame you don't enable VDEL so it has the 
> effect of moving it another single scanline, and so on.

That's correct - if you're using VDEL in the manner that the designers
intended.  For it to work that way, the kernel _must_ work so that on each
pair of scanlines, you write GRP0 on the first scanline and GRP1 on the
second.  VDEL doesn't work as advertised if you write to GRP0 in ways
other than that.

> Also, I've noticed that a lot of source code stores sprite data upside 
> down.  Any reason why?  Do they scan memory by decrementing a counter or 
> something?

Yep.  It's easier to decrement a counter in a loop than to increment it,
because then you can use the conditional branches BNE or (more commonly
for me)  BPL immediately after the decrement, instead of having to do a
CMP first. 

Archives (includes files) at
Unsub & more at

Current Thread