12

When storing graphics in a non-sequential/planar format (like the SNES does), converting to an 8-bit value representation requires first accessing multiple bytes (amount depending on bits-per-pixel), then taking into account the place of each bit to get the final result. So for 4bpp graphics, the most common type on SNES, data from 4 bytes or 2 words in separate locations will need to be accessed and added to a single byte to get the palette index.

Why are graphics stored this way when, if each bit of a pixel was stored sequentially (2 full pixels per byte), only one byte need be accessed and a simple >> 4 or & 0x0F could get a pixel's value? This seems like it would be not only much faster (less bit/math ops and memory accesses) but also simpler in design.

Improve this question

4 Answers 4

Reset to default
9

Why aren't each pixel's bits stored sequentially on the SNES?

Well, to start with, they are always (!) 8 pixels sequentially within a byte - and multiple byte in parallel for extended colour depth.

Why?

TL;DR: Because it simplifies hardware when multiple colour depth is handled.

Why are graphics stored this way when, if each bit of a pixel was stored sequentially (2 full pixels per byte), only one byte need be accessed and a simple >> 4 or & 0x0F could get a pixel's value?

Sure, on a simple, fixed colour depth system this would. But with variable (like 2,3 or 4 bpp) formats, a separate rendering pipe would be needed for each. At least when memory size is of concern.

Going always 4 bpp wastes memory space and bandwidth when not needed (like when in mode 0 with 2 bpp). Using a variable number of bits per pixel allows to reduce needed memory bandwidth and more important ROM space for the game - a direct influence in how complex a game can be at a given ROM size.

To understand how this simplifies the chip, it's necessary to look beyond a single pixel or byte, and even more important, see the pixels as a stream. To display 8 pixels in a 4 bpp mode, 4 bytes have to be read, which is the same as with a two pixel per byte encoding. Just instead latching 4 bytes in sequence and outputting them as 4 bits toward the pixel engine via of masking and shifting (*1), now each of the 4 bytes gets loaded into 4 shift registers, and shifted in parallel into the pixel engine. Memory load is exactly the same, just data encoding a bit different.

The very same hardware could now as well used to produce 1, 2 or 3 bpp graphics, by loading only 1, 2 or 3 bytes, and clear all other shift registers during load. The only difference is how to apply the clear signals (*2) and how much the address counter gets advanced (and registers loaded).

In the end it's the same way and reasoning why the Amiga did use a similar graphics system. Here is a good write-up about the same facts for the Amiga.

I'd say one simple video logic supporting 4 different colour depth is a great achievement.

This seems like it would be not only much faster (less bit/math ops and memory accesses) but also simpler in design.

Not faster. At best equally fast - and at lower colour depth slower than an adaptive method like the used one. Also not really simpler in design - at least not when considering that it need to support different colour depth

*1 - Well, rather muxing.

*2 - The registers could be cleared every cycle, or be made to be cleared during mode set and then just never loaded.

Improve this answer
10
  • "Well, to start with, they are. Always (!) 8 serial within a byte - and multiple byte in parallel for extended colour depth." I don't think thereis support for 1bpp graphics on the SNES. So this doesn't really apply(?).
    – Accumulator
    Commented Sep 3, 2018 at 1:16
  • 1
    @Accumulator But there is 2bpp and 4bpp (not sure about 3bpp). And that's what is enabeled here. But more relevant here: this remark is about the basic asumption that it's not a serial format. It is pixel serial colour parallel format. Which is also much like the way people think when designing (classic) video circuity.
    – Raffzahn
    Commented Sep 3, 2018 at 1:22
  • If you only want 4 bpp though, then sequential is clearly better, right? Software guy here, so not sure if I miss some HW issue. Some problems I see with bit planes, other than convenience issues: (a) If you have no blitter chip (as in Atari ST), and so you need pre-shifted images for speed, you have to store 4 times more of them. (b) For certain optimizations on 16 bit wide bus, the width of objects can only change in 16 pixel jumps, instead of 4 pixel jumps.
    – ddekany
    Commented Mar 30, 2021 at 14:51
  • @ddekany Well, it may depend on way more than only colour depth. The hardware issue mentioned here is about simplifying it so it may work with various levels. It does not imply how wide (or high) a sprite can be. Of course, if they are aligned at byte or word borders reading them is simplified as well. Needed bandwidth is the same for either organisation. Main point is that, at that time, it had to be a compromise between easy access and features offered. Nowadays we have enough bandwidth to do whatever suits.
    – Raffzahn
    Commented Mar 30, 2021 at 15:42
  • @ddekany As hard and software guy I preferred kind of 'blitterish' interfaces. With a single port for data and others for setup. Like the 9918 had (in part) or the Thomson EF96xx series. Ports to set x,y and operation and then simply reading and writing with auto increment. Saves the need to hold and handle coordinates in registers (or worse RAM) while abstracting video hardware to a great deal.I do not need see the screen in my address space, I do not care how it's organized. All I want is functions on screen data.The only graphics hardware I ever designed (fully) from scratch worked that way
    – Raffzahn
    Commented Mar 30, 2021 at 15:50
3

It simplifies the video generation hardware. When generating a pixel the hardware needs to determine its colour index into a palette.

The index value can have a variable number of bits depending on how many colours the individual element is using - 2, 4, 8 or 16 colours for 1, 2, 3 and 4 bit images.

The simplest way to implement the loading of a variable number of bits from RAM is to separate out those bits into planes and simply turn the DMA for each bit on and off as needed. Unloaded bits are kept as zero so a 4 bit colour index with only 2 bits loaded from RAM will be in the range 0-3.

While it would be possible to store all bits sequentially in RAM this has two main disadvantages. Say you want to store 3 bits per pixel, you can either pack two bits per byte which is wasteful or 2 and 2/3rds of a pixel per byte which requires complex decoding hardware and makes DMA memory access less regular.

Improve this answer
2
  • SNES does support 2, 4 or 8 bits, it doesn't natrively support 1 or 3 as you claim (although games can simulate that by duplicating/filling bitplanes but that's another story).
    – Bregalad
    Commented Sep 3, 2018 at 14:31
  • 1
    Fair enough. I was speaking more generally about various machines that use bitplanes, not the SNES specifically.
    – user
    Commented Sep 3, 2018 at 15:22
3

Why are graphics stored this way when, if each bit of a pixel was stored sequentially (2 full pixels per byte), only one byte need be accessed and a simple >> 4 or & 0x0F could get a pixel's value? This seems like it would be not only much faster (less bit/math ops and memory accesses) but also simpler in design.

You are clearly thinking as a software or emulator viewpoint. You should look at the problem in a hardware viewpoint. The address and data lines can be tweaked for whathever logic is required in order to fetch graphic tiles, and this has negligible hardware cost.

Each clock cycle, a byte from VRAM can be read, and it makes absolutely no difference whether the bytes read are consecutive bytes in memory or not. Assuming 4BP graphics, 2 pixels per layer are fetched on each clock cycle, and it thus requires 4 cycles to fetch a full tile line (8 pixels). Whether those 4 bytes are in successive locations in memory or not is irrelevant.

Improve this answer
0

The SNES architecture appears to have been developed roughly 8 years after the Amiga. If Atari hadn't instigated the collapse of the video game industry around 1983, the Amiga would have been that 16-bit game machine (and more).

It looks like Nintendo copied the idea of a bitplane architecture similar to the Amiga for the same reasons, to simplify the design work required for the multi-resolution data path of the chips/ASICs.

Instead of complex multiplexing into and out of all the pixel shift registers, only one block of memory-to-pixel shift logic needs to be designed for 1-bit of a pixel, and then these blocks can be replicated for as many bits per pixel as the design memory budget allows. Thus each bitplane ends up in a separate memory block to allow the logic design of each block to be well separated.

The difference today is (1) modern ASIC design tools allows far more complex logic to be designed, simulated, and have layout done and verified, and (2) the advance of Moore's laws allow a boatload more pixel memory to be put in affordable systems, which means almost nobody cares about low-res graphics.

Improve this answer

You must log in to answer this question.

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