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 '18 at 12:42

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 '18 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 '18 at 10:11
  • 1
    @nexus_2006 hmm than which was with Z80 (SEGA and Nintendo perhaps) I mistaken them with? – Spektre Apr 9 '18 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 '18 at 17:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.