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

Subject: Re: [stella] 'Look Ma No Flicker' revisited
From: Chris Wilkson <ecwilkso@xxxxxxx>
Date: Fri, 31 Aug 2001 01:17:09 -0400 (EDT)

On Thu, 30 Aug 2001, Erik Mooney wrote:

> 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

Archives (includes files) at
Unsub & more at

Current Thread