RE: [stella] Higher Resolution through Interlacing

Subject: RE: [stella] Higher Resolution through Interlacing
From: "Billy Eno" <ceno@xxxxxxxxxxxxx>
Date: Sun, 30 Jun 2002 22:34:31 -0500
Interesting background on how TV's actually work.  I certainly was unaware.
It would be pretty easy to write a demo to see if it worked (I think), and I
may try.  But, if a TV interlaces two succesive Atari 2600 "frames" to
create an image, how would you (or the TV)know if the first frame was an
"odd" (to the TV) or an "even" (to the TV).  If the you didn't start with
the correct frame, likely the graphics wouldn't look right.

This is a simulated example using one of the Player graphics, forgive the
ASCII art.

frame1	frame2	interlaced	interlaced
				correctly	incorrectly

*0000000	0*000000	*0000000	0*000000
00*00000	000*0000	0*000000	*0000000
0000*000	00000*00	00*00000	000*0000
000000*0	0000000*	000*0000	00*00000
				0000*000	00000*00
				00000*00	0000*000
				000000*0	0000000*
				0000000*	000000*0

I suppose normal TV signals get it right, how do they do it?

There would be no difference between frame1 and frame2 in terms of how you
started and finished the frames.


> -----Original Message-----
> From: owner-stella@xxxxxxxxxxx [mailto:owner-stella@xxxxxxxxxxx]On
> Behalf Of Andrew Davie
> Sent: Saturday, June 29, 2002 7:19 AM
> To: stella@xxxxxxxxxxx
> Subject: [stella] Higher Resolution through Interlacing
> Uh oh.  I've been thinking!
> After Kirk started his tutorial and made the statement "There are 192
> visible scan lines on a TV." - which I corrected in a private email which,
> amongst other things, explained exactly how NTSC and PAL TV
> systems work.  I
> quote...
> "No.  TV standards differ from country to country - specifically there are
> two standards in common use... PAL (England, Australia and more) and NTSC
> (USA, Japan).  PAL standard is 625 scanlines per image, and NTSC is 525
> (check these figures!).  Each image is composed of two 'frames' -
> each frame
> being half of the image - so each image we see is actually built of two
> halves (one half being the even-numbered scanlines, and the other the
> odd-numbered scanlines).  In PAL countries, the powerline
> frequency is 50Hz,
> and the TV picture is, too.  So we see 50 frames drawn per
> second.  In NTSC
> countries, the powerline frequency is 60Hz, so NTSC images update at 60
> frames per second.  And THAT is why we have differences between
> PAL and NTSC
> Atari games.  Firstly, the number of frames displayed per second, and
> secondly the number of scanlines in each frame.
> Now, I said that the TV standards had a whopping number of scanlines per
> image - but each frame has roughly half that (625 lines is
> divided into two
> frames of 312.5 lines each).  Now, the correct number of scanlines to
> display for a PAL Atari game just happens to be... 312!  Guess
> what it is on
> NTSC?  Let's work it out...   525 lines per image,  interlaced to two
> frames... so each frame has 525/2 = 262.5 (ie: 262) lines.  So,
> dear reader,
> our PAL game needs to send 312 lines, and our NTSC needs to send
> 262.  If we
> send more, or less, our TV will be confused.  It might roll the image, it
> might not be able to display anything at all!  So, be very very
> careful that
> you are sending the correct number of lines per frame."
> As I was saying, affter sending this to Kirk, I started to think
> a bit more
> about how we do Atari 2600 kernels, and exactly what is happening when we
> hook up a TV to a '2600.  As I explained above, a TV draws its image in an
> interlaced form - that is, each image is actually composed of two fields -
> one containing the odd numbered scanlines and the next containing the even
> numbered scanlines. But when we write Atari 2600 games, we ignore
> this, and
> (typically) simply send the same data for each field.  This works fine,
> because the TV just merges them together (over the two frames) so it looks
> like a 312 line (PAL) or 262 line (NTSC) playfield.  But in actuality, we
> are seeing a playfield twice the size (in vertical resolution) displayed
> twice (first, as odd lines, then the next frame as even lines).  And so
> that's how the '2600 display is compatible with a TV - when we write a 312
> line kernal for PAL, we are actually sending the TV  624 (+1)
> lines, making
> it compatible with the PAL TV format.  And when we write a 262 line kernal
> for NTSC, we are actually sending the TV 524 (+1) lines, making it
> compatible with the NTSC TV format.
> Soooooo.... my theory is that if we have an Atari Kernel which displays
> DIFFERENT images on odd and even FRAMES (that is, it alternates its image
> every 1/50th (PAL) or 1/60th (NTSC) second) then we will actually be doing
> things the way a broadcast TV image does things.  And if we do that, we
> double the vertical resolution of our '2600 display.  So instead of, say,
> 160 x 192 as a standard resolution - with very little extra work we could
> have 160 x 384 resolution.  Now, I may be way off the mark - in which case
> I'll be interested to find out where my analysis is incorrect.
> But I think
> I'm on the right track here.
> An interesting side-note to this... I don't believe ANY emulator would be
> taking account of the interlaced nature of TV displays. Thus, I
> don't think
> they would cater for the possibility a '2600 game writes its screen in
> paired (odd,even) frames.  And as the emulators are pretty much written to
> work with EVERY '2600 game,  then the likelyhood is that NO '2600 game to
> date has attempted this method (High Resolution through Interlacing).
> Maybe I'm crazy, but it seems as if it would work.  I like the idea of
> requiring people to play on actual hardware on an actual TV to
> get the full
> effect of a game.  It worked fine with my ChronoColor (TM)
> technology.  Now
> here's another method we can try.  I'll think of a good name for it soon.
> Any comments?
> Cheers
> A
> ------------------------------------------------------------------
> ----------------------------
> Archives (includes files) at
> Unsub & more at

Archives (includes files) at
Unsub & more at

Current Thread