supercat, on Sat Sep 24, 2005 12:13 AM, said:
SeaGtGruff, on Fri Sep 23, 2005 3:26 AM, said:
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.
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.
supercat, on Sat Sep 24, 2005 12:13 AM, said:
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.
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
1
