Re: [stella] RAM optimization

Subject: Re: [stella] RAM optimization
From: Erik Mooney <emooney@xxxxxxxxxxxxxxxx>
Date: Wed, 21 Jun 2000 11:24:08 -0400 (EDT)
>What happens when you try to read values from $0E to $2C?  These are
>unused in the Read table. 

I _think_ when I tried this a while back, all you get is a mirror of the
collision registers (read addresses $00-$0D) at $10-$1D, $20-$2D, and so

>>No and no.  From a programming standpoint (which you're unfamiliar
>>with), the scanline ends immediately at the right border of the visible
>>area... the right overscan area is for all intents and purposes part of
>>the horizontal blank region for the next scanline.

>In the diagram from the Stella programmer's guide, the overscan is shown
>on the left and not the right.
>From the perspective of the picture tube, however, are you saying that
>the overscan overlaps from the right back to the left? 

The diagram shows the overscan on the left, yeah.  That isn't technically
accurate, though.  The "overscan" area shown in that diagram actually
includes the blanking on the right side of the screen, the actual
horizontal sync beam-repositioning time, and then the overscan on the
left on the next scanline.

>How is the background color generated, BTW.  Doesn't this color beyond
>the 160 pixels available to the playfield and sprites? 

Nope.  Look at River Raid.  Clearly, the blue river is the background and
the green part is the playfield (has to be since player-playfield
collision detects when the player dies.)  The blue doesn't extend past the
edges of the green.  It's not the same as the VGA "background color".

>The 128 bytes of memory is in the PIA.  The PIA contains the 128 byes of
>memory, the timer, 2  8-bit input/output ports(all configureable in/out,
>but the 2600 circuit board requires some to be input to prevent
>contention), and interrupt logic.(which is not used)

That chip is more commonly called the RIOT, Ram/Input/Output/Timer.

> If the beam starts to retrace at cycle 76 then how can the background color 
> continue on to the right?

>The bottom line is that it certainly is possible to have single line
>resolution (both sprite and PF) without any problem, but by _not_

>I think most games released that had single line res tended to have 
>relatively simple or nonexistent playfields.  For instance, Demon Attack.

What about River Raid?  That's single-line resolution all the way, and a
fairly compelx playfield, although it is always simple-reflected, it never
does midscreen playfield rewrites.  Same goes for Pigs in Space, the part
where you fly through the big long tunnel shooting Gonzos.

And don't forget Centipede and Millipede, which have a very complex
playfield with tons of midline rewrites, but keep all the sprites

>How hard would it be to create a game that managed to read the paddles
>do single line res (sprite AND playfield) with a busy display across the 
>entire vertical space? ;)

I dunno, ask the writer of Astroblast :) (though the playfield is low-res)

>As I understood it, the VDEL was implemented to solve an issue when you a
>double line resolution display.  If you are doing a double line display,
>you only update all the registers every other line(and do
>something/nothing else on the other line).  The issue arose, although it
>is fine for your playfield to only change everyother line, what about
>objects that move vertically(like missles, or tanks)?  If you only do
>screen stuff everyother line, the moving object would jump every other
>line when moving.  Using vdel, you can do your graphics updates on every
>other line, yet still be able to place players and missles on any line.

That's correct - vdel allows single-line object placement in an otherwise
double-line kernel.  However, remember that technically, the VDEL
registers do nothing of the sort.  When VDEL for a player is set, any
writes to that GRP are "cached" and not put into the GRP register until
the GRP register for the *other* player is written to.  The way it was
envisioned and used for Combat is that, on each pair of scanlines in a
double-res kernel, you write to GRP0 on the first scanline and GRP1 on the
next.  If player 0 wants to start on the second scanline of the pair, you
enable VDEL for that player (can and probably was done offscreen); so when
you write to GRP0, nothing shows up until one scanline later, when you
write to GRP1.

>How many scanlines can you spread out the reads in order to still achieve 
>accurate results?

However many you want.  It's actually the number of reads that matter, not
how far they're spread out.  Remember that games like Super Breakout only
actually use like a third or quarter of the paddle's physical range.  The
Super Breakout paddle can be in any of 128 positions horizontally.  As
long as you do 128 evenly spaced paddle reads, you'll have accurate
results.  If those 128 paddle reads are across the entire screen, most of
the paddle's range of motion will be used; if those 128 reads are across
like 20 scanlines, the portion of paddle movement in use will be much
smaller (maybe 15-20 degrees), but you'll still have a full 128 steps of

Archives (includes files) at
Unsub & more at

Current Thread