Andrew,
This is exactly what I was doing with my interlacing tests quite a while
back. There were some issues to work out, but it was mostly working.
I was getting my video card to sync to the interlaced signal. And I was
able to merge a red field with a blue field to get purple (just super-
imposed, not interlaced interlaced). I forget what issues were still to
be solved. I think one thing that sync was still a bit flakey. But the
biggest thing was a lack of time on my part.
More recently, I think Manuel did something similar, maybe with simple
time multiplexing of different images to get different colors?
Manuel, do you remember? (sorry if I got the wrong person)
(the following discussion assumes NTSC...the reader should adjust
accordingly for PAL)
Regarding interlacing, the 2600 actually uses a 262 line, non-interlaced
display. This is a standard format, though not the one that is normally
used these days. If you do things the normal way, trying to superimpose
two kernels to increase the vertical resolution, you'll only get the
standard flicker based display. More objects, but still limited to 262
scanlines. To get it to work properly, you must strobe the RSYNC register
midline, so that each field is 262.5 lines long, effectively moving
one of the fields vertically by half a line with respect to the other.
This by itself is not enough. You must also play with VSYNC to be able
to draw the proper video signal...the 2 fields are different. If you
don't do this, the display won't sync properly. I don't have my test
code around anymore, but it was pretty simple once I got it working.
Just lots of trial and error to get there, of course.
-Chris
On Sat, 29 Jun 2002, Andrew Davie wrote:
> 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 http://www.biglist.com/lists/stella/archives/
> Unsub & more at http://www.biglist.com/lists/stella/
>
>
----------------------------------------------------------------------------------------------
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
