Background plane numbering: 1 or 0 based?

The Super NES's background planes are numbered 1 through 4. But the Game Boy Advance's background planes are numbered 0 through 3. Why this discrepancy in numbering in the documentation for Nintendo-designed video processors of comparable capability?

The numbering from 0 to 3 was helpful for macros in the C header file that I made when I was into GBA dev. But now that I've started on an assembly header file for Super NES registers, this 1-based numbering is throwing me off.

I can't speak personally about SNES development, but I've been doing a lot of GBA work lately. This is just speculation, but perhaps Nintendo tried to make the documentation more straightforward or intuitive for the GBA? That is to say, many programmers are likely used to (and may even expect) numbering to be on a 0-X scale rather than a 1-X scale in documentation. When they looked back at what they wrote for the SNES, they may have said "this isn't helpful..." or "this doesn't seem as good as..." and changed how they documented hardware accordingly for the GBA. This may have also been a time when they simply switched documentation standards wholesale (applying it to N64 and/or GC docs as well).

Or (what I believe), it could just be how they always documented their portables. The DMG/GBC Windows were always 0 and 1; ROM and RAM Banks were always described 0-X as well. GBC Palettes and even SGB palettes were 0-X as well. The one case I can think of where DMG/GBC hardware used 1-X numbering in documentation is the sound channels (Sound Channels 1-4). Admittedly, Sound Channel 0 sounds a bit weird rolling off the tongue. I wouldn't doubt that they had two different styles of documentation for years between their consoles and portables, however.

The SNES background has also been named 0-3 in some cases, in older versions of SNES9x for instance.

Long winded historical answer:


Because on a video signal generation chip, Background Plane 0 would be the video input signal. any backgrounds, sprites, or border generated by the chip are overlaid on top.

Oh really? you say...

Let's start with the TMS9918 single chip video signal generator series:

Color 0 is transparent, and lets the "lower" layer through. This is true for the active screen character area, the sprites, and the border. Colors 1 through 15 are solid colors, and in its fixed palette color #1 is black. The (A) variant of the chip has a composite video input signal pin. If everything is color 0 then it's just the video input signal visible, so this is background 0. To re-iterate: The stack from bottom to top goes as follows: video input, character tile layer, sprites, border.

If you don't accept just that reason, let's add in another factor... The TMS9918A was first used in the TI-99/4A home computer. Add in the fact that the TI-99's Extended Basic, or human-friendly implementations of programming languages in general, like to start numbering from 1. So for example in TI Extended Basic, sprites are numbered from 1 to 28 in the CALL SPRITE( ) subprogram, character (tile) row locations range from 1 to 24, character columns range from 1 to 32.

Since I can't find any reference to the earlier predecessor Dartmouth Basic not using Zero-based numbering. Also given that Micro-soft wrote almost all of the notable BASIC language interpreters in the 70's to 80's, including TI BASIC, you could easily blame Microsoft for your problem? But really in their defense, the goal was a programming language "for the masses". Count up to ten by 1. What number did you start at?

Programmers and engineers from this era that used the register-based access to video RAM no doubt had been influenced (inspired?) by the TMS9918 series design and implementation, if not with the TI-99 then they at least caught it in the MSX, using it as a reference for their further work. The VIC-II and Yamaha chips et.al. improving on it. By the time we get to the SNES video chipset in the late 80's you can still see the pedigree of just adding on to the concept started by the TMS9918, sometimes deleting useful things like leaving an access window open for read/write during active video display, but I digress...


On the other half, a designer of an LCD controller wouldn't be under the same mindset as it really does come from a different lineage. Only fairly recently last decade did the two worlds combine in the flat-screen LCD TV's.


If anyone is really fascinated by the TMS9918 design like I was, there is this link here containing scans of original hand-sketched design documents. http://spatula-city.org/~im14u2c/vdp-99xx/

Part of me wonders if the reason they went with BG1-BG4 was because they considered BG EXT to be BG0 (if I understand the concept of BG EXT, that is). Kinda along the same lines as what whicker said.

I'm just gonna go with the simplest one and assume that they thought that starting with 1 made sense at the time.

I guess Sega dodged a bullet by naming the scrolls in the Mega Drive planes A and B instead =P

I'm still trying to figure out how PPU2 is told by PPU1 to input or output on the EXT pins, since PPU1 has the MASTER pin (for master/slave modes).

I'm pretty sure the EXT pins are always inputs. In a stock SNES, /MASTER on PPU1 is tied low and the PPU2 EXT pins are inputs (for Mode 7 EXTBG).

/MASTER probably determines how sync timing is generated--whether to generate it inside the PPU or to let external logic drive it, presumably via the /EXTSYNC pin.

Yet Fullsnes uses 0-based counting for V0VOLL-V7VOLL and V0VOLR-V7VOLR.

I was pointing out that Sound Channel 0 sounds weird to me. It kind of implies something like it's not used or is muted or something, a /dev/null for sound output or something. Maybe it's just me. I wasn't implying 0 based numbering sounds weird in and of itself, however.

For a programmer having things start at 0 is pretty natural, especially since it usually maps to the actual register/address value (i.e. first channel is likely 00, second channel is 01, etc.).

It's more so having dealt with audio software (prior to my involvement in emulator programming) that gives me the impression that Sound Channel 0 sounds weird. Hardly any software I used referred to channels as 0, so to me (even though I've been programming waaay longer than I have making 8-bit music) Sound Channel 0 comes off as some sort of dummy channel. The naming scheme may have been targeting sound-guys more than code-guys, since that's how Nintendo officially refers to sound on the GB and the GBA, and only sound-related documentation uses non-0 based numbering to my knowledge. Just to add to that, on the GB, Sound Output Terminals were also labeled from 1-2, so I think this idea is at the very least plausible.