mjhjmtu

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.

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 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 i 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 Amigadid 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.

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.

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.

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.