Jump to content
IGNORED

What is the Atari 2600 screen resolution?


Gil-Galad

Recommended Posts

I've been trying to figure out what the Atari 2600 NTSC screen resolution is. One source says 192x160 and another says 160x192 and several other places have the resolution not even close to what I posted. Also, the current emulators do not output screenshots close to the resolution I posted other than MESS which outputs at 176x223. Here is the technical specification I found which list the resolution at 160x192 but the emulator does not support that resolution, apparently. http://nocash.emubase.de/2k6specs.htm

 

I used to have a Atari 2600 and I remember the resolution being wider than 160 for NTSC.

 

I'd appreciate it if anyone could clear this up for me.

Link to comment
Share on other sites

The Atari is an interesting machine.

 

It is kind of hard to explain without you having knowledge of how the system works. But I will give it a go...

 

The system technically has unlimited vertical resolution. However, it can't be higher than 262 on NTSC or else the screen rolls. Typically, the visible picture is 192 because the other 80 scan lines are used for running the parts of the program that don't draw the picture.

 

The horizontal resolution is the same, though, at 160 pixels. It sounds weird that the vertical resolution is higher than the horizontal one, but it works.

  • Like 2
Link to comment
Share on other sites

The vertical resolution is somewhat arbitrary, as a programmer can make it just about whatever he wants it to be, but within each TV format (NTSC, PAL/SECAM) is a fairly narrow range that most TVs will handle, and the further you get from the "ideal", the fewer TVs will display it without rolling the screen. 192 lines displayed vertical resolution is the "ideal" for NTSC.

 

Horizontally, I believe 160 pixels (displayed) is correct.

  • Like 1
Link to comment
Share on other sites

I'd appreciate it if anyone could clear this up for me.

This is an excellent question, but a complicated one to answer, because the answer can vary, and it can also depend on the terminology used. I'll keep my explanations as simple as I can while still being reasonably accurate and complete! :)

 

The Atari 2600 was created within the analog TV universe, and analog TV has no specific horizontal resolution per se, due to the analog nature of the signal. However, the vertical resolution for American analog NTSC TV is 525 lines, but some of those lines are devoted to the vertical blank period and the vertical sync. The lines that carry actual picture information are called "active" lines, and different sources give different numbers of active lines, ranging from 480 to (if I remember correctly) 485. The actual number is a little bit irrelevant, because some of the active lines are typically cropped, or "displayed" beyond the top and bottom edges of the screen. In modern times, the vertical resolution is usually given as "480i," or 480 lines displayed with interlacing.

 

By default, the Atari 2600's picture isn't interlaced, so the vertical resolution would be given as "240p," or 240 lines displayed progressively, without interlacing. Yet it *is* possible to create an interlaced display on the Atari 2600, so it *is* capable (through special programming) of displaying 480 active lines.

 

Most games limit the number of active lines to about 192, partly (and primarily) because with anything higher than that, you run the risk of some lines getting cropped at the top and bottom of the screen-- especially in the corners on older TV sets that have "rounded" corners. Another (secondary) consideration is that having fewer active lines lets you increase the length of the vertical blank period, thereby giving you more time to do all the processing that the game needs to do.

 

With interlacing, this could be doubled to 384 active lines or more, but we'll focus on a non-interlaced display (or 240p).

 

Although the horizontal resolution of analog NTSC TV is essentially undefined (since there are no "pixels" per se in an analog signal), in practice there's a limit to the effective horizontal resolution. However, this has no real bearing on the Atari 2600, because the 2600's signal is tied to the "color clocks" on each line. A "color clock" is often thought of as a "pixel," although they aren't really the same thing. Nevertheless, the smallest dot of color that the 2600 can draw is 1 color clock wide. NTSC TV has 227.5 color clocks per line, but the 2600 outputs 228 color clocks per line. However, 68 of these color clocks are devoted to the horizontal blank period and horizontal sync, so that leaves 160 active color clocks per line-- hence, the statement that the 2600 has a horizontal resolution of 160 pixels (228 - 68 = 160).

 

So that's where the "160x192" resolution comes from. However, that's a simplified answer, and the 2600 doesn't really have 160x192 *pixels* on its screen display.

 

It's possible (through special programming) to reduce the number of active color clocks on each line by increasing the length of the horizontal blank period, but I won't get into that, because my answer is already getting complicated enough.

 

Rather, let's talk about pixels, because that's what we're *really* interested in. For the sake of argument, we'll stick with the 160x192 resolution. Those aren't pixels, they're really color clocks and scan lines. The term "pixel" is rather complicated on the 2600, because the 2600 has different kinds of graphical objects that can make up its display, as follows:

 

- the background

- the playfield

- the player0 sprite

- the player1 sprite

- the ball sprite

- the missile0 sprite

- the missile1 sprite

 

The background has no "pixels" per se, because it has no bits that can be turned on and off-- it's really just one huge pixel that fills up the active portion of the screen. However, the other graphical objects are displayed on top (or in front) of the background, such that the background shows through wherever the pixels of the other objects are turned off. That means you can refer to "background pixels" wherever the background is showing through the empty spots in the other objects. In that sense, there can be many background pixels on the screen, and the smallest possible background pixel would be 1 color clock wide and 1 scan line tall (or "1x1").

 

The playfield is 40 pixels across, and each pixel is 4 color clocks wide. You can vary the vertical resolution of the playfield depending on how often you update the three playfield registers-- every line, every 2 lines, every 3 lines, every 4 lines, etc. So the vertical resolution of a single playfield pixel can vary from 1 line to 192 lines (or a resolution from "4x1" to "4x192"). You can even vary the playfield's vertical resolution on different lines of the screen, but we won't go there. ;)

 

The two players each have 8 bits, or are 8 pixels wide. However, the players can be displayed at single-width, double-width, or quadruple-width, so their pixels can be 1 color clock wide, 2 color clocks wide, or 4 color clocks wide. The vertical size of each player pixel can vary, just as with the playfield, so a single player pixel can have a resolution ranging from "1x1" to "1x192," or from "2x1" to "2x192," or from "4x1" to "4x192" (depending on the width of the player).

 

The other three sprites-- the ball and the two missiles-- each have only 1 bit, or are 1 pixel wide. However, they can be displayed at single-width, double-width, quadruple-width, or octuple-width, so the pixel can be 1 color clock wide, 2 color clocks wide, 4 color clocks wide, or 8 color clocks wide. As with the playfield and players, the vertical size of each pixel can vary, from 1 line tall to 192 lines tall.

 

As if all of that weren't complicated enough, you can change the color of a pixel as it's being drawn, and you can change its color from line to line. To the 2600 (in terms of turning a pixel on or off), it's still just a single pixel. But to your eye, that single pixel appears to be two or more pixels, since it's being drawn with two or more colors. So that means we have "logical" pixels that are controlled by turning their bits on or off, but we also have "virtual" pixels as defined by the dots of unique colors that are being displayed. In that sense, a virtual pixel can be smaller than a logical pixel (by splitting it up with color changes), or a virtual pixel can be larger than a logical pixel (by displaying two or more pixels of the same color side-by-side so they appear to be one block of color).

 

Given the complexity of this topic, it's no wonder people just simplify things by saying the Atari 2600 has a screen resolution of 160x192. But you can't actually display 160x192 pixels (or dots of unique color) on the screen at once, due to the limitations of the 2600's graphical objects. Still, the 160x192 resolution "works" in the sense that there are 160x192 specific locations on the screen that can have a unique color. For example, if you draw an 8x8 checkerboard pattern with a player sprite, where each player pixel is 1 color clock wide and 1 scan line tall, and if you then move the little 8x8 checkerboard (or player) around on the screen such that it passes over every possible location, each of the 160x192 locations can be one color or another at one time or another-- just not at the same time.

 

Sorry for overwhelming you with such a complicated answer, and I hope I didn't make your head spin too much! :D

 

Michael

Edited by SeaGtGruff
  • Like 16
Link to comment
Share on other sites

Thanks everyone, that's quite an interesting read and it clears up a lot of things for me. I had to read all this a few times to understand because I don't know the Atari 2600 system very well or analog television sets and I'm trying to wrap my mind around this entire concept. I'm more versed with the NES which doesn't seem to be as crazy with the video system. Even though you have to deal with the analog television set which I believe is about the same back in those days.

 

Although, these screen shots were also throwing me off about what the resolution could be.

 

Here is the MESS screenshot at 176x223. If you trim some of the black off it results to being close to 160x192.

 

Adventure.png

 

Here is a screenshot from PCAE-WIN. Stella appears to output a similar resolution.

 

ADVENTURE%20(1978)%20(ATARI).JPG

 

I do understand the vblank and hblank concept well enough. It's the color clocks that I don't quite understand. From what you said, 4 color clocks can equal one pixel and below you said one color clock can equal 1 pixel. Even though I know now there is no real pixel on one of these analog television sets. I'm kind of getting the picture that a lot of objects onscreen are of variable size. And that for larger television sets or different sizes, the video screen is scaled to fit. I wouldn't know the technical terms for this, only what I have observed by eye.

 

I still don't completely understand the entire concept. But soon I'm going to try and make a demo to see how it all works. But it may be awhile since I'm involved in a NES coding project right now. Happens to be my first one, as a matter of fact. So, I'm learning there as well. 6502 is coming easy to me, it's controlling the hardware that's a real battle.

 

And yeah, back to those screen shots. Neither one of them looks right to me. I used to own a Atari 2600 and also I watched a couple videos on YouTube and some of the commercials that showed a game being played, even if a very short clip.

Link to comment
Share on other sites

Here is the MESS screenshot at 176x223. If you trim some of the black off it results to being close to 160x192.

 

Adventure.png

 

Here is a screenshot from PCAE-WIN. Stella appears to output a similar resolution.

 

ADVENTURE%20(1978)%20(ATARI).JPG

The MESS screenshot is displaying some of the vertical blanking and horizontal blanking-- the black region surrounding the game screen. Stella usually displays some of the vertical blanking above and below the game screen, but none of the horizontal blanking to the left and right-- except when there is an HMOVE black bar on the left, or in rare cases where the programmer deliberately increases the horizontal blanking to make the active region narrower. Stella also lets you tell it how many lines to display, and which line to start the display with, so you could trim off all of the vertical blanking if you wanted to.

 

I do understand the vblank and hblank concept well enough. It's the color clocks that I don't quite understand. From what you said, 4 color clocks can equal one pixel and below you said one color clock can equal 1 pixel. Even though I know now there is no real pixel on one of these analog television sets.

A color clock is always the same size, but pixels can be different sizes. Analog TV doesn't have clearly defined pixels, but the Atari 2600 does.

 

And yeah, back to those screen shots. Neither one of them looks right to me. I used to own a Atari 2600 and also I watched a couple videos on YouTube and some of the commercials that showed a game being played, even if a very short clip.

The NTSC TV signal draws a specific screen size, depending on the standard being used. Over the years, the specifications of the NTSC signal have changed a bit as different standards or "recommendations" have been released by groups like the SMPTE. So if you search the web for technical information about the NTSC signal, you'll notice that the stated length of the horizontal blanking period may vary slightly from one web site to another, or the stated number of active lines may vary slightly-- 480, 481, 483, etc. But let's pretend that there's only one standard, and all NTSC signals adhere to that standard.

 

Different TV sets display different amounts of the active picture. Almost all standard-width (4:3) TVs crop the active picture to some extent, but the amount of cropping varies from TV to TV. So even if there are 480 active lines in the picture, a given TV set might be capable of displaying only 440 of them, or 450, or 464, or some other number. The rest of the active lines are "drawn" beyond the top and bottom edges of the screen.

 

With computer CRT monitors the situation is usually different, because most of them let you control the size of the picture-- you can increase or decrease the width and height to make sure that none of the active image is being cropped. You can adjust it so that some of the blanking is visible at all four edges of the monitor, or you can adjust it so that none of the blanking is visible. When I was growing up, our family once had a TV set with some recessed knobs on the back that let me do the same thing on the TV-- I could shrink the active picture if I wanted, so that some of the blanking was visible, and none of the active picture was cropped. But I didn't see those kinds of controls on other TV sets that we owned, unless they were hidden away inside the casing such that they could only be adjusted if you took the set apart.

 

Anyway, the Atari 2600 deliberately draws its screen display so that the active area is smaller than the active area of a normal TV signal. Part of this is automatic on the part of the 2600 (the horizontal size), and part of this is controlled by the programmer (the vertical size). So if you wanted to, you could tell your 2600 game program to draw 240 active lines, which would probably fill up the screen in the vertical direction on most TV sets-- but chances are, some of the active lines would get chopped off at the top and bottom of the TV set. By sticking to about 192 active lines, or maybe 200 active lines, you can safely assume that the entire picture will be visible on almost all NTSC TV sets. That means you'll see a black border (the blanking) around the game screen, but you're probably going to see different amounts of black border on different TV sets, depending on how much they crop the picture.

 

When you start talking about emulators, you're getting into another area entirely, because emulators run on computers, and computer monitors have much higher resolutions than TV sets and the Atari 2600. The main issue with emulators has to do with "pixel aspect ratio." Ideally, a computer display uses a screen resolution that produces square pixels, but TV sets don't have square pixels, and the Atari 2600 doesn't have square pixels. When an emulator like MESS or Stella draws an Atari 2600 game screen on the computer monitor, the game screen may look distorted from what you'd see on a real 2600, depending on the screen resolution that the emulator is using, as well as the pixel aspect ratio it's trying to duplicate. If you're using the OpenGL option with Stella, you can adjust the "GL Aspect (N)" setting for NTSC games for a more accurate-looking screen display, because that setting lets you adjust the pixel aspect ratio that's being emulated. A "GL Aspect (N)" setting of 83 should work well. For PAL games, you would adjust the "GL Aspect (P)" setting, but I don't know what the best setting would be.

 

Michael

Edited by SeaGtGruff
  • Like 1
Link to comment
Share on other sites

When you start talking about emulators, you're getting into another area entirely, because emulators run on computers, and computer monitors have much higher resolutions than TV sets and the Atari 2600. The main issue with emulators has to do with "pixel aspect ratio." Ideally, a computer display uses a screen resolution that produces square pixels, but TV sets don't have square pixels, and the Atari 2600 doesn't have square pixels. When an emulator like MESS or Stella draws an Atari 2600 game screen on the computer monitor, the game screen may look distorted from what you'd see on a real 2600, depending on the screen resolution that the emulator is using, as well as the pixel aspect ratio it's trying to duplicate. If you're using the OpenGL option with Stella, you can adjust the "GL Aspect (N)" setting for NTSC games for a more accurate-looking screen display, because that setting lets you adjust the pixel aspect ratio that's being emulated. A "GL Aspect (N)" setting of 83 should work well. For PAL games, you would adjust the "GL Aspect (P)" setting, but I don't know what the best setting would be.

Just to add to this (already correct) information about Stella. The reason for no black borders on the left and right (other than HMOVE blanks, which are already explained) is that we know that the maximum horizontal resolution is 160 pixels, so no 'padding' is required. Internally, Stella generates a 160 pixel wide screen (ie, the TIA 'framebuffer' is 160 pixels wide). However, when output the horizontal resolution is doubled, to 320 pixels. This isn't quite what happens on a real TV, but it's as close as can be done efficiently while rendering in software mode. If you switch to OpenGL mode as suggested, then there are aspect ratio settings for NTSC and PAL mode, which can vary the width as a percentage. For example, if you set "GL Aspect (N)" setting to 83, as suggested by SeaGtGruff, this makes the horizontal resolution 0.83 * 320 ~= 266 pixels, which is probably closer to what you'd see on a real TV. As I said, this can only be done in OpenGL mode purely for technical reasons (basically, it's trivially easy to do in OpenGL, and computationally-intensive in software mode).

 

OK, that's the horizontal resolution part, which was actually the easier one to explain. :) Next is the vertical resolution. As already explained, the 2600 really has no limit on this. However, this ambiguity isn't any good for me as a developer, so a limit had to be set somewhere. Through experimentation, we found that a 'normal' NTSC scanline rate of 262 could fit into a vertical resolution of 210 pixels, and a PAL scanline rate of 312 could fit in 250 pixels. That's why screenshots generated with Stella are normally multiples of 320 pixels wide and 210/250 pixels high.

 

Work is ongoing in having Stella deal with ROMs that fall outside these guidelines, and have the window size created according to the scanline count of the image (currently, these sizes must be set manually, per-ROM in the game properties). And finally, the internal resolution of the TIA (in Stella) is 160x320 (or 160 wide as described above) by 320 high. I'm not entirely sure of the max of 320, but I assume it's related to framerate (as the scanline count increases, the framerate decreases, so at some point with enough scanlines the framerate will approach zero). Perhaps this is the crossover point?

Link to comment
Share on other sites

Unfortunately for me, there is a problem. Stella is not detecting that I have OpenGL even though Everest is telling me that I have version 1.4.1. Stella tells me that I need version 2.0+ and GLSL. I'm using a eMachine and I dare not update the manufacture's drivers because the eMachine drivers are custom modified and I don't want to break my OS or even the integrated video hardware. This wouldn't normally be a problem but my PSU in my PC of choice blew a fuse a couple of weeks ago and I don't have the money to get another PSU right now. eMachine doesn't have a newer update for this PC.

 

I have a NVIDIA GeForce4 MX Integrated Codename Crush17. Has 64MB VRAM. DirectX 7.0 support.

 

Back to the screen resolution. All this is really interesting indeed. I'm certainly not near as confused about the resolution as I once was. The vertical resolution is pretty much programmer controlled. The resolution is apparently internally correct in Stella and comes out a bit different in the conversion to modern television sets and monitors. Not to mention all the technical details that I've read about it from SeaGtGruff that have cleared a lot things up about scanlines, color clocks and pixels.

 

All this stuff has been interesting to me lately. I may make a demo in the upcoming months to increase my understanding of the Atari 2600. 6502 isn't that much a problem for me, but the hardware is going to be a challenge for sure. I see a lot of good things going on around here for sure.

 

Thanks a lot you all!

Edited by Gil-Galad
Link to comment
Share on other sites

Unfortunately for me, there is a problem. Stella is not detecting that I have OpenGL even though Everest is telling me that I have version 1.4.1. Stella tells me that I need version 2.0+ and GLSL. I'm using a eMachine and I dare not update the manufacture's drivers because the eMachine drivers are custom modified and I don't want to break my OS or even the integrated video hardware. This wouldn't normally be a problem but my PSU in my PC of choice blew a fuse a couple of weeks ago and I don't have the money to get another PSU right now. eMachine doesn't have a newer update for this PC.

 

I have a NVIDIA GeForce4 MX Integrated Codename Crush17. Has 64MB VRAM. DirectX 7.0 support.

 

Back to the screen resolution. All this is really interesting indeed. I'm certainly not near as confused about the resolution as I once was. The vertical resolution is pretty much programmer controlled. The resolution is apparently internally correct in Stella and comes out a bit different in the conversion to modern television sets and monitors. Not to mention all the technical details that I've read about it from SeaGtGruff that have cleared a lot things up about scanlines, color clocks and pixels.

 

All this stuff has been interesting to me lately. I may make a demo in the upcoming months to increase my understanding of the Atari 2600. 6502 isn't that much a problem for me, but the hardware is going to be a challenge for sure. I see a lot of good things going on around here for sure.

 

Thanks a lot you all!

 

I would recommend using batari Basic if you are just starting Atari programming. It's not only much easier, it also gives you a decent understanding of the hardware. However, while it does allow for a good variety of games to be made, assembly is much more flexible in what you can do. Good luck!

 

-Jonathon Bont

Edited by Animan
Link to comment
Share on other sites

Unfortunately for me, there is a problem. Stella is not detecting that I have OpenGL even though Everest is telling me that I have version 1.4.1. Stella tells me that I need version 2.0+ and GLSL.

Those specs are only required to use OpenGL TV effects. For just general OpenGL support, version 1.4.1 is fine. Try going to Video Settings and setting Renderer to OpenGL. Then restart Stella and see what happens. As for your video card, while it is an older model, I think the basic OpenGL rendering in Stella wouldn't be too much for it (I've tested on old Intel-based chipsets, and it worked fine there, and those are slower than a Geforce4 MX).

Link to comment
Share on other sites

Unfortunately for me, there is a problem. Stella is not detecting that I have OpenGL even though Everest is telling me that I have version 1.4.1. Stella tells me that I need version 2.0+ and GLSL.

Those specs are only required to use OpenGL TV effects. For just general OpenGL support, version 1.4.1 is fine. Try going to Video Settings and setting Renderer to OpenGL. Then restart Stella and see what happens. As for your video card, while it is an older model, I think the basic OpenGL rendering in Stella wouldn't be too much for it (I've tested on old Intel-based chipsets, and it worked fine there, and those are slower than a Geforce4 MX).

 

Thanks a lot. I didn't realize that you could change the renderer. That works perfectly and all is well in the Atari 2600 gaming universe for me. I'm having a good time playing Yars' Revenge and it looks right visually as well. I've learned quite a bit about the Atari 2600 lately.

Link to comment
Share on other sites

I would recommend using batari Basic if you are just starting Atari programming. It's not only much easier, it also gives you a decent understanding of the hardware. However, while it does allow for a good variety of games to be made, assembly is much more flexible in what you can do. Good luck!

 

-Jonathon Bont

 

Thanks a lot for the advice. I'm kind of surprised to see that the Basic version for Atari 2600 even works on the real hardware. NBASIC for the NES does not work right on the real hardware and it's also shareware. So, for those two reasons it's shunned. I was told that it wasn't implemented correctly, even though it certainly is possible.

 

Unfortunately, I don't know BASIC at all, I only know 6502. I might just stick to using 6502 for Atari 2600 programming.

Link to comment
Share on other sites

I would recommend using batari Basic if you are just starting Atari programming. It's not only much easier, it also gives you a decent understanding of the hardware. However, while it does allow for a good variety of games to be made, assembly is much more flexible in what you can do. Good luck!

 

-Jonathon Bont

 

Thanks a lot for the advice. I'm kind of surprised to see that the Basic version for Atari 2600 even works on the real hardware. NBASIC for the NES does not work right on the real hardware and it's also shareware. So, for those two reasons it's shunned. I was told that it wasn't implemented correctly, even though it certainly is possible.

 

Unfortunately, I don't know BASIC at all, I only know 6502. I might just stick to using 6502 for Atari 2600 programming.

 

BASIC is probably one of the easiest languages to learn. If you only 6502 assembly, then BASIC should be a breeze (although I can't say that for sure)

 

However, 6502 is one thing. Learning how to program the 2600 is a whole other challenge there. But, you never know. Try assembly, and if you think it's too much, try BASIC. Also, this version of BASIC allows you to use 6502 assembly inside of it, so knowing some assembly will help out a bit.

Link to comment
Share on other sites

  • 1 year later...

I think people usually care about this resolution so that they can output the same amount of picture from an emulator like from the real console. So in other words: what is the real resolution the most common Atari 2600 game occupies on the unmodified CRT screen (including borders)... I think it is more than 192 scanlines... at least my Junior (PAL) surely does not fill the whole screen with active graphics...

Edited by maiki
Link to comment
Share on other sites

what is the real resolution the most common Atari 2600 game occupies on the unmodified CRT screen (including borders).

It varies depending on the TV set, because different TV sets overscan the video by different amounts. Some TVs may display 240 or more lines per field (IIRC, I think the maximum is sometimes stated to be 243 "active" lines per field, or 486 per frame), while others may display fewer than 210 lines per field.

 

Also, a particular TV set may display a different number of lines depending on how bright the picture is, due to "blooming."

Link to comment
Share on other sites

  • 2 years later...

Perhaps this will help...

 

cycles2_2.png

 

First, let's learn a bit how a standard NTSC television signal works. A TV scans 1 line in 1/60th of a second. During that time, the TIA clock chip ticks 228 times. The first 68 ticks are the for horizontal blanking period. The beam isn't actually retracing back to the left, it's just off. This is needed because the electronics needs some time to bounce back from painting the previous line. The vertical blanking section similarly is a waiting period because of the inductive inertia of the magnetic coils which deflect the electron beam vertically in a CRT. Unlike most computers, even older systems that existed in the 2600 heyday, the video chip took care of everything for you to display an image. In the 2600, the CPU has to pick up the slack and handle programming of the TIA registers for each and every scan line. Therefore, the only time you can use the CPU for game logic is when it's not painting the screen. Painting the screen eats about 75 percent of the processor's time too. This is generally handled by your program in what's called a kernel. The rest of your program, the game logic and data gets tucked in with the kernel and after the screen is drawn, your game logic can execute.

 

Since there are 228 color clocks per scan line, and 68 of them are blanked, that leaves 160 color clocks. If you're nifty at programming, you can change the TIA registers while the scanline is being painted. So you can technically change the color for each color clock, hence the analogy that you can have 160 horizontal pixels. Technically, I think the hardware only supports 4 colors per scan line though.

 

Vertically, as was stated before, 192 scan lines is the safest bet for vertical resolution, so you get an "effective resolution" of 160x192. The reason the vertical can be cheated to 384 (double 192) is because TV's use a trick called interlacing. Interlacing is simply drawing all the odd scan lines first... 1,3,5,7,9, etc.... and skipping the even lines, then, after reaching the bottom of the screen, it goes back and fills in the even lines. This was needed in the early days of TV because it took too long to draw the screen fast enough. In other words, when they tried progressive scanning, the top of the display would fade too much by the time the scanning reached the bottom and the display would flicker noticeably. By interlacing, since you're skipping 1/2 the lines, you hit the bottom of the display twice as fast and the fading effect is spread out over the entire screen rather than at the top, and the other scan to cover the even lines is right behind it to boost the image back up.

 

Video display on the 2600 is a really interesting beast. Typically, computer systems set aside a section of RAM to act as a video buffer. All you do is dump data into the buffer, and voila, the video chip echos that data visually on the display. In text modes, text will appear, in graphic modes, colored dots appear. When the 2600 was designed back in 1975, RAM was very expensive. Even with a resolution of 160x192 and two colors (say, black and white) would require 1 byte per 8 pixels. 160 times 192 times 1 bit per pixel = 3840 bytes of RAM (Yow!), and that's just B&W. 2 bits would allow 4 colors, 3 bits, 8, etc... so RAM was out of the question due to the cost. That's why this whole game of using the CPU to manually load the TIA registers for each scan line was used.

 

It's a really goofy setup, but it kept the price down to $199 at launch in 1977.

 

Alot of people might consider this a weakness of the 2600, but in reality, since so much is left to the software, hacks, which here basically refer to using the hardware in an unintended manor, made the 2600 a really versatile platform, and helped keep the system in active production for 15 years. Newer technology eventually brought 16 bit systems which finally rendered the 8 bit systems obsolete.

 

Another thing to consider is televisions themselves went through changes as well. Back in 1977. televisions had one input. A broadcast antenna input, and that's it. Hence, the NTSC composite output of an Atari 2600, as well as other game and home computer systems, would RF modulate the composite signal onto a television broadcast frequency, typically channel 3 or 4. You would use the channel not used in your area to prevent interference with a TV station's broadcast. In the simplest terms, the Atari output on broadcast channel 3, or 4.

 

RF modulating a composite signal onto a broadcast carrier frequency compresses the signal causing image degradation, but TV's back then didn't have composite inputs. Later, TV's started building in composite inputs so one could get a better image when using VCR's, and later DVD players, and video game systems started putting composite outputs in their consoles. The TIA in the Atari produces a composite NTSC signal, which is then RF modulated, but one could tap the composite output of the TIA and drill a hole in the cabinet, add an RCA jack, and run composite out right into the composite input of a modern TV. These days TV's have all sorts of choices. Broadcast & cable inputs, composite input, VGA, and HDMI. The Radio Shack Color Computer 3 had composite out, but the 1 and 2 didn't. We used to do modifications to add a composite output so we could use a C64 (composite) monitor, or as TV's gained them, use them there. I imagine hackers have done the same for the 2600.

 

 

Hope that sheds a bit more light

  • Like 1
Link to comment
Share on other sites

The DK Arcade 2600 link in my Signature pushes the total scanlines to 270 giving a few more visible scanlines and more overscan needed for the barrel stage logic.

 

SpiceWare commonly uses 210 visible scanlines for games (up from 192) with no problem. (Correct me if I am wrong.)

 

I love how flexible the Atari VCS 2600 is because it is so primitive!

Link to comment
Share on other sites

NES and all the 16-bit era consoles had squarish pixels and filled the screen (240p). Atari was really a different beast in 1977 with it's rectangular pixels and only filling about 3/4 of the screen. The pertinent data has already been mentioned but the early consoles all had a different vibe compared to "NES and up." Atari VCS may be the most underpowered yet flexible console ever made.

Link to comment
Share on other sites

SpiceWare commonly uses 210 visible scanlines for games (up from 192) with no problem. (Correct me if I am wrong.)

 

I suspect you got 210 from the number of lines that Stella saves in the screenshot - it does that because where the output shows up is so flexible due to it being totally under program control. If you need more processing time in Vertical Blank and have plenty to spare in OverScan you can easily scoot the image down a few scanlines to give VB more time and OS less.

 

I took some screenshots and cropped the images so fully black lines at the top and bottom were gone. Visible scanline counts for my finished games are:

 

200 - Medieval Mayhem

194 - Stay Frosty (part of Stella's Stocking)

201 - Space Rocks (it was higher at one point)

202 - Stay Frosty 2

 

For total scanlines I normally use 262, though for Stay Frosty I used 264 as supercat's music driver for the main menu needed the count to be evenly divisible by 4.

 

WIP:

182 - Draconian - Even with the ARM chip, keeping track of 150 sprites, 20 missiles and 150 stars (for the parallax background) uses a lot of resources, so the screen is smaller.

196 - Frantic

196 - whatever Timmy! becomes

Edited by SpiceWare
  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...