8-bit console horizontal resolution

Question

Some early consoles like the NES and the Sega Master had a horizontal screen resolution of 256.

That sounds good for an 8-bit machine, until you consider that a sprite sometimes needs a slightly negative position in order to be partly off the left side of the screen. (Consider e.g. the bad guys in Super Mario Bros, who move onto the screen from the right, and if you and they miss each other, end up moving off the screen to the left.) The upshot is that you need to track an extra bit for sprite positions. Not a huge problem, but it's got to be annoying being so close to being able to track positions in one byte, and just missing the mark.

It would seem that by reducing the resolution to 248, you could represent positions in one byte, without making any discernible change in the quality of the display. Why didn't they do this?

Answer 1

The NES did not use an extra bit for sprite positions. A sprite's X-position was the position of its left edge, which means that sprites cannot be placed partially off the left side of the screen:

However, the NES did actually provide the feature you're suggesting, in a way: bits 1 and 2 of the PPUMASK register can be used to keep the leftmost 8 pixels of the screen blank. This not only allows sprites on the left side to be hidden, but also helps to reduce the mirroring glitches on the sides of the screen in some games.

As an example, here's a screenshot of Super Mario Bros. 3:

It's especially obvious in areas where the background color configured in the PPU palette is different from what we humans would consider the background color:

Answer 2

256 is the maximum number of pixels per row, but most games used fewer. Using fewer pixels allowed for partially off-screen sprites with only 8 bits of position information.

Most hardware of that era allowed some flexibility with screen resolutions. While the timing for the display (PAL or NTSC) was fairly well nailed down, the programmer could choose to start or end the actual display of pixels earlier or later on each scanline, and earlier or later in the vertical refresh cycle.

Answer 3

the stuff you are describing has nothing to do with x resolution selection. In the 8 bit era CPUs didn't have mul , div instructions so computing *,/ was really expensive. That is why the x resolution is usually power of 2.

That allows to compute pixel address from x,y coordinates using just basic ALU operations. For example on 256 pixels per line and 1 Byte per pixel and LFB:

address = screen_start + x + (y<<8)

the screen is usually on some base address (not colliding with lower bits of screen range) so in such case you might rewrite to

address = screen_start | x | (y<<8)

and even the bit-shift can be replaced by adding/oring with higher BYTE instead.

Now back to your problem. Handling 16 bit x position is much faster than handling non power of two x resolution screen rendering. As you manipulate the x,y few times per frame but rendering sprites wold require expensive computations on per scan line of each sprite.

Answer 4

In addition to the above explanations re: sprites actually only having 8 bits of position resolution, the first column blanking option etc, the NES - and others following its same general design - actually had another, simpler, more physical tactic to address the problem: Overscan.

The pixel generator clock, derived from the NTSC colourburst crystal by some particular divider, was conveniently just slow enough that, on a "normally adjusted" CRT television (calibrated with the standard test card and other tools), the console couldn't quite show a full 256 pixels within the visible borders of the tube / bezel. ISTR your likely visible width being rated as somewhere around 240 to 252 pixels depending how well in-spec your TV is, and it being more likely that things would disappear off the left than the right due to the NES timing. Which is why on-screen text rarely goes all the way to the edges, despite how low resolution it already is.

This tactic is also used at the top and bottom, even though the 8-bit range isn't really a problem there. There's quite a bit of garbage that can be seen around the vertical borders, on emulators and I think PAL machines also (as the screen exposes more scanlines, usually a minimum of 256). The machine is generally set to produce 224 lines, sometimes 240, but yer typical TV can only display somewhere around 212 to 220 at best. Without having to do any particular work, therefore, most if not all of the junk is just pushed away off the top or bottom physical limits of the screen where no-one will ever see it ... at least, in the originally intended field of use. It doesn't therefore matter if weird things happen at the edges of the image, because, technically, you shouldn't be able to see it, or if you can it's right on the edge of the screen where the whoopsies will only be visible right near the centreline and will clip off for certain at the corners.

Just like how regular broadcast television tends to work, in fact. If you capture an old tape using a USB converter card, or even just play it on a modern flatscreen TV with way less inherent overscan (which also makes NES games look like crap, for that and various other reasons), you can see all kinds of little telling details at the margins that would have been totally invisible during the original broadcast.

As for what that particular pixel clock is, I forget exactly. It's five-point-something megahertz. 5.3? 5.7? It's a little odd in that it's derived from the slightly unusual NES master crystal that's not 4x the base colourburst, but 6x (so 21ish MHz vs the more familiar 14ish), owing to how the machine builds its colour output using a 6-bit quasi-binary pattern, so there's a different set of factors vs most other contemporary machines (other than those which use a similar video setup of course; the TI-99/4A, Colecovision, original MSX range, SMS, and Megadrive in 256px mode, are all at least close if not identical). I do know it's a little slower than 4/5ths of the Amiga's 7.1MHz (itself 2x colourburst, so it likely ain't 4/15ths of 21.whatever, which would be a weird and hard-to-engineer divisor anyway), because on the same range of TVs which exhibit the described behaviour, the Amiga (and Atari 8-bits - and C64? - before it), by a similar confluence of luck and design, manages to cram in 320 (or 640 (or 160)) pixels just inside of the overscan border, losing a few right in the corners of curvier tubes. So... less than 5.73MHz.

Probably 5.37ish? That's a nice round 1/4 of colourburst x 6, and conveniently is 3/4 of Amiga frequency - meaning mathematically it gives us 240 pixels "just" inside the overscan, with a single 8-pixel block on each side cut off by the bezel to a certain extent, or - if it's aligned more completely at the right - only a little bit missing on the right hand side, a mostly or completely missing first column on the left, and a second column which is either wholly visible or slightly cropped after it...

(NB I'm working off the on-screen appearance PAL machines here, which run just a little lower frequency than their NTSC counterparts; a US Amiga likely doesn't quite overscan even in the corners, and a US NES likely just neatly shears off most or all of the first column whilst leaving the second and all the other 30 intact... the figures are correct, however; colourburst frequency is exactly 315MHz divided by 88...)

PS, the "working out screen position from memory address without use of division/multiply" thing is... convenient for those systems which happen to have a 256- (or 128-, 512-) pixel screen width, or have the option of setting it (e.g. Atari 8-bits include the lower two amongst their many choices), but it's not universal. There are plenty of 8-bit systems (and, heck 16-bit ones which had MUL/DIV instructions but didn't exactly execute them particularly fast) where the screen wasn't a binary-aligned width - VIC20, C64, VCS, every other Atari mode, Apple ][, Amstrad (CPC and PCW), Gameboy, Gamegear... etc. Presumably there must still be ways - perhaps using modulo functions? - of carrying out the same task without spending inordinate processor time or wasting memory on huge lookup tables?