192 lines (or more?)

[brainwagon]

As a relatively new programmer to this platform, I'm working on my first program which ultimately I want to run on real Atari hardware. As such, I'm trying to do as much development using emulation as humanly possible, with the idea that I may have to burn this only a couple of times.

 

I'm curious though: for NTSC your program must generate 262 lines, normally divided as three vertical sync lines, 37 more in the vertical blank, 192 visible, and 30 in the overscan. Is there a hidden gotcha in using slightly more in the visible area (other than possibly clipping the bottom?) I'm running short on scanlines to accomplish all the data that I'm trying to dump on the screen, and I'm wondering if a significant reorg might be required or if I can let it slip.

 

Incidently, the project isn't really a game: it's a simulation of the WWII German crypto machine Enigma. The encoding and decoding work, and generate text which can be deciphered with my reference C implementation, I'm mostly working on interface and graphics. I use the 48-pixel wide trick to get six characters on a line. Currently I display two keyboard layouts (as a 5x6 matrix) and use the ball to implement a cursor. There are also six character input and output buffers. I suppose I could eliminate the output keyboard matrix (no real need to keep it), but I kind of like the trick.

 

[SeaGtGruff]

I'm curious though:  for NTSC your program must generate 262 lines, normally divided as three vertical sync lines, 37 more in the vertical blank, 192 visible, and 30 in the overscan.  Is there a hidden gotcha in using slightly more in the visible area (other than possibly clipping the bottom?)  I'm running short on scanlines to accomplish all the data that I'm trying to dump on the screen, and I'm wondering if a significant reorg might be required or if I can let it slip.

936868[/snapback]

You don't need to limit yourself to 192 lines of display, that's just the number Atari settled on because it seemed to work best with most TVs (NTSC of course). If you want a taller viewing area, just borrow scan lines from the top and bottom blank areas. For example, 192 scan lines is equivalent to 24 rows of 8-line-tall characters on a computer, and the Atari 8-bit (and many other home computers) did have just 24 rows of characters, but some had 25 rows-- which is 200 scan lines tall rather than 192. So you could use 3 vertical sync lines, 33 blank lines, 200 display lines, and 26 overscan blank lines-- borrowing 4 more lines at the top and 4 more lines at the bottom to keep things "vertically centered" on the screen-- or you could have only 29 blank lines at the top and 22 blank overscan lines, so you'd have 208 display lines, etc.

 

The only things you need to worry about are (1) making your display so tall that it won't be fully visible on a TV, (2) taking away too many blank lines which might potentially interfere with the total vertical blank time, and (3) having fewer cycles during the vertical blank for performing all the tasks that normally get done after drawing one frame and getting ready to draw the next frame. So it's a balancing act between how many lines your TV or monitor can actually display without any portions of your screen getting "cropped," and leaving yourself enough vertical blank time to do all the things you want or need to do between frames.

 

I think the resolution on an NTSC TV is something like 640x 480, but the 2600 doesn't (normally) interlace the screen, so the vertical resolution is more like 240 viewable lines-- 30 rows of 8-line-tall characters. The 8-bit Atari leaves 3 rows blank at the top of the screen, and 3 rows at the bottom (30 - 3 - 3 = 24 rows of characters), so that the pixels in the corners will be viewable, since most (older) TV sets had rounded corners. But modern TV screens are more rectangular, so you should be able to squeeze in more lines at the top and bottom without having the pixels in the corners getting cropped by the TV set. I don't know if you can actually go as high as 240 scan lines and still see everything at the top and bottom edges (and corners), but you should certainly be able to display more than just 192 lines.

 

Michael Rideout

[mos6507]

192 was chosen in the mid 70s when TVs were much rounder. It's really an antiquated guideline unless you still play 2600s on 30 year old TVs.

 

Ever since the mid 80s when TVs became more squared off, 200 pixels will fit across the full width of the tube.

 

I remember running a test on my Atari 8-bit in the mid 80s on my TV and only the very edges of the screen started to crop with 25 lines of Gr.0. text.

 

I do recommend going to 200 pixels by default.

 

For your game there isn't much going on in the corners so you really have nothing to worry about.

[supercat]

I think the resolution on an NTSC TV is something like 640x 480, but the 2600 doesn't (normally) interlace the screen, so the vertical resolution is more like 240 viewable lines-- 30 rows of 8-line-tall characters.

 

A television set is required not to show lines 21 or above on a 262-line screen. So that leaves about 240 lines that a television set might show. In practice, most sets probably show around 220, but some may have the picture a little 'higher' than others.

 

If CPU time is not an issue, I'd suggest 3 lines of VSYNC, 19 lines of blanking, then 20 lines of stuff that you don't care whether or not it shows up (like sky), then 200 lines of good stuff, then 20 lines of stuff you don't care about (like ground). Running full bleed borders on the top and bottom of the screen can be a nice touch if you can afford the time to do it. The left and right edges of the screen you can't do anything about, but the top and bottom you can.

[SeaGtGruff]

I think the resolution on an NTSC TV is something like 640x 480, but the 2600 doesn't (normally) interlace the screen, so the vertical resolution is more like 240 viewable lines-- 30 rows of 8-line-tall characters.

 

A television set is required not to show lines 21 or above on a 262-line screen. So that leaves about 240 lines that a television set might show. In practice, most sets probably show around 220, but some may have the picture a little 'higher' than others.

937333[/snapback]

Yeah, according to the NTSC information I've seen on the internet, NTSC has a viewable vertical resolution of about 480 lines-- that's 525 lines (interlaced), less 40 lines of vertical flyback time (20 per field), less 2 lines of CC information (1 per field), giving 483 lines (241.5 per field), with about 3 lines being cropped (about 1.5 per field), leaving 480 lines (240 per field). But I take it that this is an "ideal" number, which assumes that the TV's vertical picture settings allow that much of the picture to be shown. Most of the modern TVs I've seen don't seem to have any vertical or horizontal control settings the way most older TVs often did, and I think they're designed to automatically give you pretty decent picture, but many older TVs (as well as most monitors) would let you adjust the vertical size and vertical positioning of the picture, so there's basically no telling in advance how many lines are actually being displayed. The only thing you can do is try for the maximum vertical resolution (which I take it is about 241.5 lines, or 241 on a noninterlaced Atari screen) and see if you can count how many lines are actually viewable.

 

One way to do that is to display a steady (rather than verically-scrolling) image of rainbow colors, one color per line so 8 lines per hue, which for a 240-line display would be 30 hues, so that would be the 16 hues plus a second set of the first 14 hues. Then count how many hues can be seen, and whether all 8 lines can be seen for the topmost and bottommost hues.

 

Of course, if you found out that you can see 240 lines on your TV or monitor, and you program an Atari screen for 240 lines, that dosn't guarantee that everyone else will be able to see all 240 lines, too. And if you're using an emulator, then the graphics mode being used to display the emulated screen will also be a factor. And if you're using a TV-- especially an older one with rounded corners on the picture-- then you might be able to see all 240 lines in the very center of the screen, but not in the corners.

If CPU time is not an issue, I'd suggest 3 lines of VSYNC, 19 lines of blanking, then 20 lines of stuff that you don't care whether or not it shows up (like sky), then 200 lines of good stuff, then 20 lines of stuff you don't care about (like ground).  Running full bleed borders on the top and bottom of the screen can be a nice touch if you can afford the time to do it.  The left and right edges of the screen you can't do anything about, but the top and bottom you can.

937333[/snapback]

Actually, although you can't make the picture any *wider* (the way you can on the Atari 8-bit computers by switching to "wide playfield" mode), you can make the picture *narrower* by manually turning the VBLANK on and off for each line. Due to the timing issues, there are specific numbers of pixels that you can get across the screen, because 1 machine clock equals 3 color clocks, so you can move the left and right borders inward at increments of 3 color clocks, but not at increments of 1 color clock. And if I remember correctly, you can time things so the left and right borders meet at the center of the screen (i.e., the entire line will be blanked), and move outward from there at intervals of 3 color clocks, so you can't get 128 color clocks (equal to 32 playfield pixels, or the 2nd and 3rd playfield registers on a reflected screen), but you can get 126 color clocks (first color clock of left side PF1 shaved off, and last color clock of right side PF1 shaved off), or 129 color clocks (all of left PF1, left PF2, right PF2, and right PF2, plus 1 color clock from left or right PF0).

 

Of course, this raises the question of why you'd possibly want to make the screen any narrower, but there can be advantages to doing that, like gaining extra cycles for any routines that you're performing during the horizontal blanks-- allowing for the instruction times needed to turn VBLANK on and off at just the right moments-- and it could also potentially save memory if you don't need to worry about saving data for PF0 (assuming a single-scan-line playfield resolution, with each line being mapped to RAM or a ROM table, that's equal to a savings of 192 or 384 bytes on a 192-line screen, depending on whether you're using 2 bytes for left and right PF0, or just 1 byte [left and right nibbles] with the nibbles being shifted 4 bits as needed to get the data for the left or right side). Or you could just leave PF0 blank (as bB does, for example), but then you still get the background color. So moving the left and right borders inward using VBLANK might not be necessary, but it will prevent graphics data (background, sprites) from being displayed where you don't want it.

 

Based on the screenshot that was posted, it looks like this particular program isn't using a lot of the left and right sides of the screen anyway, so using VBLANK to move the borders inward might be a viable option for gaining more h-blank time if needed for anything that's being done during the h-blank intervals.

 

Michael Rideout

[SeaGtGruff]

The only thing you can do is try for the maximum vertical resolution (which I take it is about 241.5 lines, or 241 on a noninterlaced Atari screen) and see if you can count how many lines are actually viewable.

 

One way to do that is to display a steady (rather than verically-scrolling) image of rainbow colors, one color per line so 8 lines per hue, which for a 240-line display would be 30 hues, so that would be the 16 hues plus a second set of the first 14 hues. Then count how many hues can be seen, and whether all 8 lines can be seen for the topmost and bottommost hues.

937412[/snapback]

Here's a simple program that displays the Atari rainbow on 240 scan lines to help you see how many are actually visible. Since you don't want to start with a black scan line (it would be hard to tell whether that line is being displayed or not!), the program starts with color 254 (hue 15, luminance 14) and double-steps backward. This works out pretty well, because hue 0 ends up near the middle of the screen, which kind of helps you count hues from that point down.

 

The program starts with 3 lines of VBLANK/VSYNC, then 19 lines of VBLANK, so the 240 lines of video are lines 23 through 262, which assumes that line 21 (the CC info) is getting cropped, and line 22 is also getting cropped, plus the half-line at the bottom of the screen. If you can't see the last line of color, the last 1.5 lines may be getting cropped, plus the CC line (but in that case hopefully not the line after the CC line as well), so you can reduce the VBLANK loop to just 18 lines, and add a line of VBLANK just before the VSYNC, so the VBLANK is on lines 262 and 1 through 21, and the video is lines 22 through 261.

 

 

Michael Rideout

VERTICAL.ZIP

[supercat]

Actually, although you can't make the picture any *wider* (the way you can on the Atari 8-bit computers by switching to "wide playfield" mode), you can make the picture *narrower* by manually turning the VBLANK on and off for each line.

937412[/snapback]

 

You could do that to make the screen narrower, but I really don't think there's much point. It's usually much easier to make the screen narrower by using the PF0 to draw a border.

[brainwagon]

Thanks for all the hints. Here's another question: I'm using Stella (of course) to test my game. Is there some good way to make sure I get 262 scanlines per frame exactly?

[+stephena]

Thanks for all the hints.  Here's another question: I'm using Stella (of course) to test my game.  Is there some good way to make sure I get 262 scanlines per frame exactly?

937726[/snapback]

The next version of Stella, due out quite soon, has a built-in debugger. When in debugger mode, you can do a frame advance (or advance by XXX frames), and it will show how many scanlines are in the current frame. I've actually used this to determine that some games are in fact NTSC when they've been labeled as PAL.

 

Not that any of this helps you right now, of course. But in a week or two we should be ready for a release. In the meantime, have a look at http://www.hardcoders.org/stella_nightly. Download the latest Win32 version. Unfortunately, we don't have OSX or Linux static binaries working right now.

[vdub_bobby]

Thanks for all the hints.  Here's another question: I'm using Stella (of course) to test my game.  Is there some good way to make sure I get 262 scanlines per frame exactly?

937726[/snapback]

The next version of Stella, due out quite soon, has a built-in debugger. When in debugger mode, you can do a frame advance (or advance by XXX frames), and it will show how many scanlines are in the current frame. I've actually used this to determine that some games are in fact NTSC when they've been labeled as PAL.

 

Not that any of this helps you right now, of course. But in a week or two we should be ready for a release. In the meantime, have a look at http://www.hardcoders.org/stella_nightly. Download the latest Win32 version. Unfortunately, we don't have OSX or Linux static binaries working right now.

937760[/snapback]

Or use z26 with the -n command line switch.