Jump to content

Photo

Session 2: Television Display Basics


23 replies to this topic

#1 Andrew Davie OFFLINE  

Andrew Davie

    Stargunner

  • 1,782 posts
  • Dr.Boo
  • Location:Tasmania

Posted Thu May 22, 2003 12:00 AM

Hopefully you've been through the first part and have your editor, assembler, emulator and documentation ready to go. What we're going to look at now is a basic overview of how a television works, and why this is absolutely necessary pre-requisite knowledge for the '2600 programmer. We're not going to cover a lot of '2600 specific stuff this time, but this is most defintely stuff you NEED TO KNOW!

Television has been around longer than you probably realise. Early mechanical television pictures were successfully broadcast in the '20s and '30s (yes, really! - see http://www.tvdawn.com/index.htm). The mechanical 'scanning' technology utilised in these early television systems are no doubt the predecessors to the 'scanning' employed in our modern televisions.

A television doesn't display a continuous moving image. In fact, television displays static (non-moving) images in rapid succession - changing between images so quickly that the human eye percieves any movement as continuous. And even those static images aren't what they seem - they are really composed of lots of separate lines, each drawn one after the other by your TV, in rapid succession. So quick, in fact, that hundreds of them are drawn every image, and many images are drawn every second. In fact, the actual numbers are very important, so we'll have a look at those right now.

The Atari 2600 console was released in many different countries around the world. Not all of these countries use the same television "system" - in fact there are three variations of TV systems (and there are three totally different variations of Atari 2600 hardware to support these systems). These systems are called NTSC, PAL, and SECAM. NTSC is used for the USA and Japan, PAL for many European countries, and Australia, and SECAM is used in France, some ex-French colonies (e.g.: Vietnam), and Russia. SECAM is very similar to PAL (625/50Hz), but I won't spend much time talking about it, as Atari SECAM units are incredibly rare, and little if any development is done for that format anyway. Interestingly, the differences in requirements for displaying a valid TV image for these systems leads to the incompatibility between cartridges made for NTSC, PAL and SECAM Atari units. We'll understand why, shortly!

A television signal contains either 60 images per second (on NTSC systems) or 50 images per second (on PAL systems). This is closely tied to the frequency of mains AC power in the countries which use these systems - and this is probably for historical reasons. In any case, it's important to understand that there are differences. Furthermore, NTSC images are 525 scanlines deep, and PAL images are 625 scanlines deep. From this, it follows that PAL images have more detail - but are displayed less frequently - or alternatively, NTSC images have less detail but are displayed more often. In practise, TV looks pretty much the same in both systems.

But from the '2600 point of view, the difference in frequency (50Hz vs. 60Hz) and resolution (625 scanlines vs. 525 scanlines) is important - very important - because it is the PROGRAMMER who has to control the data going to the TV. It is not done by the '2600 (!!) - the '2600 only generates a signal for a single scanline.
This is completely at odds with how all other consoles work, and what makes programming the '2600 so much 'fun'. Not only does the programmer have to worry about game mechanics - but she also has to worry about what the TV is doing (ie: what scanline it is drawing, and when it needs to start a new image, etc., etc).

Let's have a look at how a single image is drawn by a TV...

A television is a pretty amazing piece of 1930's technology. It forms the images we see by shining an electron beam (or 3, for colour TVs) onto a phosphour coating on the front of the picture tube. When the beam strikes the phosphour, the phosphour starts to glow - and that glow slowly decreases in brightness until the phosphour is next hit by the electron beam. The TV 'sweeps' the electron beam across the screen to form 'scanlines' - at the same time as it sweeps, adjusting the intensity of the beam, so the phosphour it strikes glow brighly or dimly. When the beam gets to the end of a scanline, it is turned off, and the deflection circuitry (which controls the beam) is adjusted so that the beam will next start a little bit down, and at the start (far left-hand-side) of the next scanline. And it will then turn on, and sweep left-to-right to draw the next scanline. When the last scanline is drawn, the electron beam is turned off, and the deflection circuityr is reset so that the beam's position will next be at the top left of the TV screen - ready to draw the first scanline of the next frame.

This 'turning-off' and repositioning process - at the end of a scanline, and at the end of an image - is not instantaneous - it takes a certain amount of time for the electronics to do this repositioning, and we'll understand this when we come to talk about the horizontal blank (when the beam is resetting to the left of the next scanline) and the vertical blank (when the beam is resetting to the top left scanline on the screen). I'll leave that for a later session, but when we do come to it, you'll understand what the TV is doing at these points.

A fairly complex - but nonetheless simple-to-understand analog signal controls the sweeping of the electron beam across the face of the TV. First it tells the TV to do the repositioning to the start of the top left line of the screen, then it includes colour and intensity information for the electron beam as it sweeps across that line, then it tells the TV to reposition to the start of the next scanline, etc., right down to the last scanline on the screen. Then it starts again with another reposition to the start... That's pretty much all we need to know about how that works.

The Atari 2600 sends the TV the "colour and intensity information for the electron beam as it sweeps across that line", and a signal for the start of each new line. The '2600 programmer needs to feed the TV the the signal to start the image frame.

A little side-track, here. Although I stated that the vertical resolution of a TV image is 625 lines (PAL) and 525 lines (NTSC), television employs another 'trick' called interlacing. Interlacing involves building up an image out of two separate 'frames' - each frame being either the odd scanlines, or the even scanlines of that image. Each frame is displayed every 1/30th of a second (ie: at 30HZ) for NTSC, or every 1/25th of a second (25Hz) for PAL. By offsetting the vertical position of the start of the first scanline by half a scanline, and due to the persistance of the phosphour coating on the TV, the eye/brain combines these frames displaying alternate lines into a single image of greater vertical resolution than each frame. It's tricky and messy, but a glorious 'hack' solution to the problem of lack of bandwidth in a TV signal.

The upshot of this is that a single FRAME of a TV image is actually only half of the vertical resolution of the image. Thus, a NTSC frame is 525/2 = 262.5 lines deep, and a PAL frame is 625/2 = 312.5 lines deep. The extra .5 of a line is used to indicate to the TV if a frame is the first (even lines) or second (odd lines) of an image. An aside: about a year ago, the #stella community discussed this very aspect of TV images, and if it would be possible for the Atari to exploit this to generate a fully interlaced TV frame - and, in fact, it is possible. So some 25 years after the machine was first released, some clever programmers discovered how to double the resolution of the graphics.

Back to basics, though. We just worked out that a single frame on a TV is 262.5 (NTSC) and 312.5 (PAL) lines deep. And that that extra .5 scanline was used to tell the TV if the frame was odd or even. So the actual depth of a single frame is 262 (NTSC) and 312 (PAL) lines. Now, if TV's aren't told that a frame is odd, they don't offset the first scanline by half a scanline's depth - and so, scanlines on successive frames are exactly aligned. We have a non-interlaced image, displayed at 60Hz (NTSC) or 50Hz (PAL). And this is the 'standard' format of an Atari 2600 frame sent to a TV.

In summary, an Atari 2600 frame consists of 262 scanlines (NTSC) or 312 scanlines (PAL), sent at 60Hz (NTSC) or 50Hz (PAL) frequency. It is the job of the '2600 programmer to make sure that the correct number of scanlines are sent to the TV at the right time, with the right graphics data, and appropriate control signals to indicate the end of the frame are also included.

One other aspect of the difference between TV standards - and a consequence of the incremental development of television technology (first we had black and white, then colour was added - but our black and white TVs could still display a colour TV signal - in black and white) - is that colour information is encoded in different places in the signal for NTSC and PAL (and SECAM) systems. So, even though the programmer is fully-responsible for controlling the number of scanlines per frame, and the frequency at which frames are generated, it is the Atari itself which encodes the colour information into the TV signal.

This is the fundamental reason why there are NTSC, PAL, and SECAM Atari systems - the encoding of the colour information for the TV signal! We get some interesting combinations of Atari and games, for example...

If we plug a NTSC cartridge into a PAL '2600, then we know that the NTSC game is generating frames which are 262 lines deep, at 60Hz. But a PAL TV expects frames 312 lines deep, at 50Hz. So the image is only 262/312 of the correct depth, and also images are arriving 60/50 times faster than expected. If we were viewing on a NTSC TV, then the PAL console would be placing the colour information for the TV signal in a completely different place than the TV is expecting - so we would see our game in black and white.

There are several combinations you can play with - but the essence is that if you use a different '2600 variant than TV, you will only get black and white (eg: NTSC '2600 with PAL TV or PAL '2600 with NTSC TV) as the colour information is not in at the correct frequency band of the signal. And if you plug in a different cartridge than TV (eg: NTSC cart with PAL TV or vice-versa) then what you see depends on the television's capability to synchronise with the signal being generated - as it is not only the incorrect frequency, but also the incorrect number of scanlines.


All of this may sound complicated - but really all we need to do is create a 'kernal' (which is the name for your section of an Atari 2600 program which generates the TV frame) which does the drawing correctly - and once that's working, we don't really need to worry too much about the TV - we can abstract that out and just think about what we want to draw.

Well, I lie, but don't want to scare you off TOO early ;)

Next time, let's have a look how the processor interacts with hardware, I/O and memory.

#2 Thomas Jentzsch OFFLINE  

Thomas Jentzsch

    Thrust, Jammed, SWOOPS!, Boulder Dash, THREE·S, Star Castle

  • 22,693 posts
  • Always left from right here!
  • Location:Düsseldorf, Germany, Europe, Earth

Posted Thu May 22, 2003 12:46 AM

Too much "HardWork" ;) for me to read all the words, Andrew. But I am sure you are doing it right! :thumbsup:

#3 NoahsMyBro OFFLINE  

NoahsMyBro

    Dragonstomper

  • 551 posts
  • Location:New Jersey

Posted Thu May 22, 2003 12:57 AM

Andrew - this is a fantastic thing you've started. I very much hope you continue with this project for a long time. (I don't really know how you would determine the 'end' of it, so I can't see it one day being finished.)

You not only hit upon a good idea, but the writing is top-notch-professional throughout. I wasn't distracted at any time by typos, misspellings, or grammatical errors.

I honestly think you could produce a book out of this, and if you did I'd buy it.

So, as has already been mentioned above, keep this going, it's terrific stuff!

#4 DEBRO OFFLINE  

DEBRO

    Stargunner

  • 1,924 posts
  • Location:Atlanta, GA

Posted Thu May 22, 2003 4:45 AM

Andrew, why don't you team up with John Redant?

Atari Video Game Production Course
Class 200
Class 300

With your combined efforts you could really get these going.

#5 dirtboy69 OFFLINE  

dirtboy69

    Chopper Commander

  • 247 posts
  • Location:Kincardine Ontario

Posted Thu May 22, 2003 4:56 AM

i'd be willing to do this i got so far in programming then kinda got stuck. i'd like to see it do a little overview of the assembly basics though cause that was hard for me and it would be cool to get some light shone on it

#6 NovaXpress OFFLINE  

NovaXpress

    Skeet Shooter

  • 10,745 posts
  • Still Smokin'
  • Location:Dark Side of the Moon

Posted Thu May 22, 2003 4:58 AM

Thanks for sharing this information Andrew. So often in all forms of art, those with knowledge try to keep it hidden from others because they are afriad of competition. To offer your time and wisdom like this is admirable in every way and shows that you are in this for the creativity, not for the (not-worth-mentioning) profits.

Guys like you and others who posted above are the reason that the 2600 remains the most active classic console.

#7 Serguei2 OFFLINE  

Serguei2

    Dragonstomper

  • 652 posts
  • Location:Canada

Posted Mon May 26, 2003 10:32 AM

I wish to make a 2600 game. I begin to read 2600 for newbie. Here my question?

Why the programmers should take care about tv resolution on 2600?

Does 2600 not have a predefined resolution like c64 or even SNES?

If a programmer want to make a comodore 64, does he take care about tv resolution?

Maybe a stupid question.


Serguei2

#8 Happy_Dude OFFLINE  

Happy_Dude

    River Patroller

  • 4,212 posts
  • Forum Slacker
  • Location:Sydney, Australia

Posted Mon May 26, 2003 11:05 AM

I wish to make a 2600 game. I begin to read 2600 for newbie. Here my question?

Why the programmers should take care about tv resolution on 2600?

Does 2600 not have a predefined resolution like c64 or even SNES?

If a programmer want to make a  comodore 64, does he take care about tv resolution?

Maybe a stupid question.


Serguei2

I know it's a lot to read but its worth it ;)

But from the '2600 point of view, the difference in frequency (50Hz vs. 60Hz) and resolution (625 scanlines vs. 525 scanlines) is important - very important - because it is the PROGRAMMER who has to control the data going to the TV. It is not done by the '2600 (!!) - the '2600 only generates a signal for a single scanline.
This is completely at odds with how all other consoles work, and what makes programming the '2600 so much 'fun'. Not only does the programmer have to worry about game mechanics - but she also has to worry about what the TV is doing (ie: what scanline it is drawing, and when it needs to start a new image, etc., etc).



#9 Serguei2 OFFLINE  

Serguei2

    Dragonstomper

  • 652 posts
  • Location:Canada

Posted Mon May 26, 2003 12:05 PM

Oops. Missed that.

So 2600's graphics may vary from ntsc, pal and secam.

Thanks


Serguei2

#10 EricBall OFFLINE  

EricBall

    Dragonstomper

  • 789 posts
  • Location:Markham, Ontario, Canada

Posted Mon May 26, 2003 8:04 PM

So 2600's graphics may vary from ntsc, pal and secam.


The three major differences between NTSC & PAL/SECAM are:
1. Frame rate (60fps vs 50fps). This impacts any calculations which are based on the number of frames, typically movement.
2. Number of lines per frame (262 vs 312), important since the game is responsible for triggering VSYNC.
3. Number of visible lines (192 vs 228), which can change all kinds of things like sprite sizes, size of the playing field, vertical motion rate, and more.

Some homebrew programmers use the TV switch to change between NTSC and PAL, while others create NTSC & PAL specific versions.

(SECAM is the same as PAL (50/312/228) except the TV switch is hardwired to B&W and there are only 8 colors.)

PS The 2600 has 160 pixels of horizontal resolution.

#11 Serguei2 OFFLINE  

Serguei2

    Dragonstomper

  • 652 posts
  • Location:Canada

Posted Mon May 26, 2003 9:42 PM

Let me see.

In NTSC 2600 uses 160x192 resolution and in PAL/Secam uses 160x228 resolution.

A game made in USA the sprites may look smaller in PAL

Or a game made in Europe the sprites may look bigger in NTSC losing some lines at the bottom of the tv screen.


Serguei2

#12 Andrew Davie OFFLINE  

Andrew Davie

    Stargunner

  • Topic Starter
  • 1,782 posts
  • Dr.Boo
  • Location:Tasmania

Posted Mon May 26, 2003 10:17 PM

Let me see.

In NTSC 2600 uses 160x192 resolution and in PAL/Secam uses 160x228 resolution.

A game made in USA the sprites  may look smaller in PAL

Or a game made in Europe the sprites may look bigger in NTSC losing some lines at the bottom of the tv screen.


Serguei2



Please read the tutorial carefully. It explains what happens when you play a game made for one TV system, on another TV system.

If a company *converts* their ROM from one format to the other, then they also have the option of changing the sizes of things. Typically they wouldn't do that, so your statement that a PAL game converted to NTSC will generally display bigger sprites is somewhat correct. But in doing that conversion, you will also have to remove 50 scanlines from the screen, so you may very well have to reduce the size of your sprites to fit things in after all!

It's all a balancing act.

Worrying about the sizes of things between PAL and NTSC is pretty much the least of your worries. Just pick a platform (NTSC is my recommendation) and program your game for it. You can tackle the system conversion at a later date. And nobody is going to be running your NTSC game on a PAL console. And if they do it will be in black and white. Read the tutorial!

#13 Sharky OFFLINE  

Sharky

    Dragonstomper

  • 743 posts
  • At Home
  • Location:Oz

Posted Sat May 31, 2003 1:34 PM

This is interesting, after reading both sessions I finding know the difference between PAL and NTSC Televisions. (Also been to some links learning about it other ways)

Techinally PAL (More scanlines, slower framerate)
NSTC (Less Scanlines, Faster framerate)

Ive grown up in a PAL-TV Country and had no little or have played very little NTSC Games.

So I may myself start on PAL.

Its probably best I go back and re-read the tutorials again before I start reading Tutorial 3.

I feel ive just learnt 1 major important step today so Ill let all this sink in me and come back tommrow and start on Turtorial 3.

Thanks Andrew, you couldnt of explained it any better.

#14 bjk7382 OFFLINE  

bjk7382

    River Patroller

  • 4,577 posts
  • Location:Michigan

Posted Sun Oct 19, 2003 2:13 PM

So when you say that a game from a different t.v. system are displayed in black and white. All of the pal games I have tried on my NTSC tv are in color but they roll. Why isn't this mentioned in the lesson. I have never come across a pal game that wouldn't roll but was just displayed in b&w.

#15 Thomas Jentzsch OFFLINE  

Thomas Jentzsch

    Thrust, Jammed, SWOOPS!, Boulder Dash, THREE·S, Star Castle

  • 22,693 posts
  • Always left from right here!
  • Location:Düsseldorf, Germany, Europe, Earth

Posted Sun Oct 19, 2003 4:05 PM

So when you say that a game from a different t.v. system are displayed in black and white. All of the pal games I have tried on my NTSC tv are in color but they roll. Why isn't this mentioned in the lesson. I have never come across a pal game that wouldn't roll but was just displayed in b&w.

PAL games on NTSC consoles will always show some color, but the colors will be different than on PAL consoles.

NTSC games on PAL consoles will also show different colors or, if the number of scanlines is odd, only black and white. This is due to the different color encoding in PAL that requires an even number of scanlines.

The games may or may not roll, that mainly depends on your TV. While most PAL TVs can sync to NTSC, NTSC TVs very often can't sync to PAL.

#16 bjk7382 OFFLINE  

bjk7382

    River Patroller

  • 4,577 posts
  • Location:Michigan

Posted Sun Oct 19, 2003 6:00 PM

Yeah I read that somewhere. That is why you are selling Thrust+ as being both. Just when you play it on a pal tv you need to use the different color switch. On a pal tv it would be red instaid of purple, when the right difficulty switch is on A.

#17 Dragonforce-Europe OFFLINE  

Dragonforce-Europe

    Dragonstomper

  • 669 posts

Posted Mon Aug 30, 2004 10:18 AM

hi boofly! ;)

#18 jaginthebox OFFLINE  

jaginthebox

    Combat Commando

  • 2 posts
  • Location:Missouri

Posted Thu Oct 14, 2004 3:12 AM

:jango: Thank you Andrew. That's a good lesson and a lot to take in. I'll let todays lesson sink in and I'll read lesson 3 tomorrow. :D

#19 supercat OFFLINE  

supercat

    Quadrunner

  • 6,401 posts

Posted Thu Jun 2, 2005 11:20 PM

The upshot of this is that a single FRAME of a TV image is actually only half of the vertical  resolution of the image.  Thus, a NTSC frame is 525/2 = 262.5 lines deep, and a PAL frame is 625/2 =  312.5 lines deep.


A standard NTSC frame (two fields) consists of precisely 525 scan lines of 227.5 chroma clocks each. The Atari hardware outputs 228 chroma clocks per scan line, thus producing a horizontal scan rate which is about 1/4% slow. Using 262 scan lines instead of 262.5 helps make the vertical scan rate more nearly correct than 263 though in practice it doesn't matter. A standard NTSC field (1/2 frame) is precisely 59,718.75 / 3,579,545 second. A 262-scan-line Atari 2600 field is 59,736 / 3,579,545 second, i.e. about 0.002% slow. BTW, this translates into a frame rate of 59.92Hz.

Programmers who work with other systems may find it interesting to note that on platforms which output 227.5 chroma clocks per scan line, using 262 scan lines per frame will yield a different screen appearance from using 263. Using 262 scan lines, a solid color will generate a faintly visible stationary 'checkerboard'; using 263 scan lines, the checkerboard will alternate phases each frame. I would expect that the PAL hardware on the 2600 always starts each frame in the same color phase, thus requiring the use of an even number of scan lines.

#20 Thomas Jentzsch OFFLINE  

Thomas Jentzsch

    Thrust, Jammed, SWOOPS!, Boulder Dash, THREE·S, Star Castle

  • 22,693 posts
  • Always left from right here!
  • Location:Düsseldorf, Germany, Europe, Earth

Posted Fri Jun 3, 2005 1:38 AM

I would expect that the PAL hardware on the 2600 always starts each frame in the same color phase, thus requiring the use of an even number of scan lines.

Yes, especially because PAL is averaging its colors from two scan lines (alternating phases to correct color errors resulting from phase errors). If there is an odd scan line number, all colors are gone.

#21 thecheat123 OFFLINE  

thecheat123

    Combat Commando

  • 1 posts

Posted Mon Feb 14, 2011 7:11 PM

but how do you display a 200-something bar image with only 128 bytes of RAM?

#22 grafixbmp OFFLINE  

grafixbmp

    Dragonstomper

  • 679 posts
  • Location:South Central US

Posted Mon Feb 14, 2011 10:14 PM

but how do you display a 200-something bar image with only 128 bytes of RAM?

Don't forget the 4k ROM memory in your game carts. More if it is a bank switched cart.

#23 supercat OFFLINE  

supercat

    Quadrunner

  • 6,401 posts

Posted Tue Feb 15, 2011 5:16 PM

but how do you display a 200-something bar image with only 128 bytes of RAM?


There's no requirement that any particular information about any portion of the display above or below the current raster position be stored anyplace. The TIA has to have stored in it information about what should be displayed at the current raster position, but that's it. Anything else may be generated on the fly in any convenient manner. That's part of what makes the 2600 so neat.

#24 Nukey Shay ONLINE  

Nukey Shay

    Sheik Yerbouti

  • 21,639 posts
  • Location:The land of Gorch

Posted Tue Feb 15, 2011 5:57 PM

Really all games usually do is have a pointer or two already set up in RAM for an image....between the the time that the lower part of the screen has been drawn, to the time that the top of the next frame needs to be drawn. This small amount of user ram points to or holds the address of a bitmap in ROM. When drawing the display, just the pointer needs to be updated to fetch the next line of bitmap info...which is then sent to the display register. This process is happening as the screen is being drawn...so there is (almost always) no need to store the bitmap image into ram before it gets passed to the actual display register.

A possible exception would be some kind of really complex display where the kernel has no time to update and/or use such a counter to load bitmap data on-the-fly (which adds a few cycles to the process).

To create an image where each bitmap value is ~N scanlines high, just don't write to the register. The value that was sent on the previous line is used again automatically. That is why the console will display vertical bars on the screen with no cartridge program present...the random values that exist in the system ram registers are spilling onto the screen over and over - with no program to alter them.




0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users