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?

  • 1
    Both the NES and the Master System have a common VDP/PPU parent in the TMS9918a (the Master System a lot more explicitly), which goes some way to explaining the similar design decisions.
    – Tommy
    Apr 9, 2018 at 12:42

4 Answers 4


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:

enter image description here

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:

enter image description here

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:

enter image description here


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.

  • 1
    I think that the NES and SMS don't have that much flexibility, despite it being common on many home micros. Both can subtract a column or two and the SMS has hard-coded split modes, where either or both of the right 64 pixels and the top 16 pixels don't scroll while the rest of the screen does. All cases of a programmer opting to display fewer than 256 pixels though, so this is a long-winded agreement.
    – Tommy
    Apr 9, 2018 at 17:31

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.

  • 2
    NES had a Ricoh reimplementation of a 6502, sans BCD instructions. SNES had a Ricoh 5A22 processor, based on the 65C816, again the 6502 family but newer. This one did have 16 bit registers though.
    – nexus_2006
    Apr 9, 2018 at 10:11
  • 1
    @nexus_2006 hmm than which was with Z80 (SEGA and Nintendo perhaps) I mistaken them with?
    – Spektre
    Apr 9, 2018 at 14:15
  • 2
    @Spektre of consoles with 256 pixels across, the Z80 was in the ColecoVision and the Master System, and was also in the Mega Drive as the sound processor but could own the whole bus if a Master System cartridge was in use. It's also in the Game Gear and an 8080 derivative with some backported Z80 features powers the Game Boy. So maybe your mental Nintendo association is from the latter? Talking only about consoles, the 6502 and close derivatives were used in the Ataris (from the 2600 up to and including the Lynx), the NES, the SNES and the PC Engine.
    – Tommy
    Apr 9, 2018 at 17:24

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?

  • "Just like how regular broadcast television tends to work" - I probably don't fully understand how what you describe works. - Could a TV-station have put text( 1-letter-wide going along any margin ) in that overscan-margin as one-way-emails/memos-to-staff only broadcast for a short interval so no one would notice, a cheaper option to some type of decoder-box for the same function, obviously they would have had to de-tune the tv ( horizontal or vertical adjustments ) to see the text, when would have been the earliest that that would have been possible Dec 30, 2019 at 1:50

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .