How does the SNES (Super Nintendo) calculate the address of a character?

Question

The SNES has a PPU (Picture Processing Unit) which comprises VRAM, OAM (Object Attribute Memory), and CGRAM (Color Graphics/Palette RAM). These are used to represent tiles, tile maps; attributes for sprites; and color palettes, respectively.

The VRAM contains a 2D array which represents a map of tiles that are displayed on the screen (in four background layers, depending on the current mode, not relevant here).

In https://emu-docs.org/Super%20NES/General/snesdoc.html#Reg2116 there is a pretty good overview of how this works:

It states that each entry in the tile map contains this:

High     Low          Legend->  c: Starting character (tile) number
vhopppcc cccccccc               h: horizontal flip  v: vertical flip
                                p: palette number   o: priority bit

It then goes on to say that the following formula can be used to calculate the address of the character:

address_of_character = (base_location_bits << 13) + (8 * color_depth * character_number);

There is also an example:

For example, if base location 1 is selected, the color depth for the tile map is 4 bits (16 colors), and character number 1 is selected, the address will be (1<<13)+8*4*1 = 8224.

However, it then states:

Note that the word address entered into the VRAM address register will be half of that, or 4112.

1: Why is it half?

2: Why is the color depth 4 bits in this example?

3: How is color depth selected or derived, in general?

I've searched through the hardware registers: https://en.wikibooks.org/wiki/Super_NES_Programming/SNES_Hardware_Registers but I don't seem to find anything regarding color depth nor palette. This leads me to believe that the color depth is derived based on the current mode and perhaps something else. Please correct me.

Answer 1

1: Why is it half?

Erm, half as in halving like in divided by two (aka shifted by 1)? As described it's a word address, not an address of a word (or a byte address). (*1)

The example does illustrate this quite well by coming up with the (byte address) 8224, which turned into a word address (4112, exactly half, isn't it?) is to be stored in the register.

2: Why is the color depth 4 bits in this example?

Beside the obvious why not, it helps to create a nice result. In general, an example should always use different values for different parameters for readability and to avoid the usual 1*1=1 problem. In this case it also helps to underline and simplify the example about halving to make it easy to understand (only decimal digits and all power of two).

3: How is color depth selected or derived, in general?

In what context? Basic colour depth is defined by the mode selected.

---

*1 - Word Address vs. Byte Address

From comments I got the impression that this is maybe hard to grasp for today's programmers, who never ever experienced anything but byte-addressable machines/CPUs. While this would be more of a topic for a (or several) separate question, lets try here:

A word address numbers words as 0,1,2... A byte address does the same with bytes. A CPU with 16 bit memory and byte addressing will end up with the words 0,1,2... at address 0,2,4... In such a system, conversion between byte and word address is done by halving as one word occupies two bytes. Thus word address != address of a word. It has that been since the invention of memory addressing.

Or in other more 'modern' words (and I really hate to add it, as it's like explaining earth rotation using flat-earthers' vocabulary) think of memory like arrays in C. Some byte array at address 0 will number it's elements as 0,1,2... and they end up at a memory offset (address) of 0,1,2... A similar array with words will number them as well as 0,1,2... but now they end up at offset 0,2,4...

Defining such a 16 bit word, byte addressable memory in C might look like this:

union Memory
 {
  short AsWords[4]; // The Word Memory 
  char  AsBytes[8]; // overlayed with Byte Addesses
 } foo;

foo.AsBytes[4]will here resolve to an offset of 4, while foo.AsWords[2] will also produce an offset of 4. In this example the first is a byte address and the second a word address, both resolved to a byte address withing a byte addressable word orientated memory. But a programmer using a word will always use an index halve of what the bytewise memory address is.

This also shows the reasoning for alignment, as with a 16 bit data path words can be read at the same timing as bytes.

From today's perspective people often have a hard time to understand what a game changer the application of byte addressable word memory was, when Gene Amdahl made it a fundamental part of the /360 design. Today it's taken for granted that memory is seen not only as bytes, but words may reside anywhere. Completely ignoring that it took two major steps in CPU design to archive it: Byte addressing, available due a fitting ISA and misaligned data.

While the first is a real advancement in computer design, the latter not only required mostly useless (and back then large) hardware add-ons for minor gain, but also opened Pandora's box by encouraging to lazy programming, resulting in the need of even more hardware to cover the now common penalties associated.