Re: [stella] 'Look Ma No Flicker' revisited

Subject: Re: [stella] 'Look Ma No Flicker' revisited
From: Erik Mooney <erik@xxxxxxxxxx>
Date: Thu, 30 Aug 2001 23:48:52 -0400
On Wed, 29 Aug 2001 20:10:05 -0700, you wrote:

>>SC Football already definitively does it, so you aren't really doing
>>anything strictly new technically.  More so the challenge here is to create
>I tried disassembling SC Football and didn't get that far.  Huge chunks of 
>"data" which I knew had to be code and not knowing what to do with it.
>>believable sprite shapes within the constraints of the missile objects.
>I already attempted as much that in the mockup images.  I thought it looked 
>somewhat Berzerk-like and acceptable.

Those look okay, but they're only one frame of animation each; keep going.

>This is a real newbie question, but what's the best approach in the middle 
>of the kernel to answer all these scanline-state questions, namely:
>Am I on a scanline that requires P0, if so, which address offset from the 
>top of P0 do I pull the graphics from?
>Am I on a scanline that requires P1, if so, which address offset from the 
>top of P0 do I pull the graphics from?

Using Supercharger or Superchip RAM, there's a very elegant solution to
this.  Simply have a 100-byte (or however many iterations your kernel goes
through) zeroed block of RAM.  Offscreen, copy the sprite data into the
proper place into the 100 bytes, and every line in the kernel all you need
is an indexed load and zeropage store!  (Works for your missile objects
too although you need to separate the NUSIZ and HMOVE data.)

Sadly, even Superchip RAM isn't enough to do that for more than one player
object.  Supercharger or Megacart RAM, on the other hand, could.

Isn't there one of the M-network banking schemes that has 2K of RAM?  That
could pull this off and make it playable on current emulators (SC is but
Megacart isn't.)  I'd like to see a game come out of this list that goes
beyond the standard 4k cart or SC formats.  If you really want to push the
2600's limits...

>I have a hard time figuring out how I can write the above code in the tiny 
>amount of time one is given between WSYNC and the first playfield rewrite.  
>Once the playfield starts rewriting there isn't going to be any time to do 
>anything else until after PF1 on the right side is stored, which only leaves 
>a little time left before you've reached cycle76.
>Since I'm only doing double-line res, I can unroll the kernel into a 
>line-pair and only ask relevant questions about one player at a time, since 
>even if they are supposed to appear on the same scanline, VDEL will make the 
>adjustment to line them back up.  But even then, it seems like there isn't 
>enough time to do all this processing.

Well, first you need to figure out exactly how you're writing the
playfield code, then you'll know exactly how many cycles you have to do
the players.  Get your playfield functional, then we'll all have a go at
optimizing it.

>Once I can get beyond this critical-section of the code, I think the rest is 
>going to be a piece of cake in comparison.

It's a piece of cake to code but not necessarily to get up the motivation
to do it.  I lost interest in INV once the technical parts were done.

Archives (includes files) at
Unsub & more at

Current Thread