Start of Backgrounds

So after a little bit of fiddling with the ARM9 memory manager, I decided to dive straight into the next stage of the DS video core...the backgrounds.

Essentially, part of the DS video core allows you to define a background, which is essentially an array of indexes into an array of tiles. The tiles are represented as palettized image data; either 8-bit indexes or 4-bit indexes. The last time I really dealt with this was when I was writing my NES and GBC emulators; both systems handle backgrounds pretty much the same way, and what they have to offer is quite simple.

The DS's background core is far more complex; it supports 4 different backgrounds, with two types of palettes, 4 different sizes, and alpha blending between backgrounds and sprites. Furthermore, there is no static memory reserved for the map or tile data; you instead map a VRAM bank to background data. Also, there are 5 different modes of operation, and in each mode, the backgrounds have different types; they can either be text, rotation, or extended.

Text backgrounds are the simplest backgrounds, and the ones I decided to go with first. They are similar to the NES and GBC in that they're just represented by an array of indexes, and the only transformation you can do on them is scroll them.

Rotation backgrounds (also called affline backgrounds) are the same as text backgrounds, except you can perform rotation, shearing, or scaling operations on them for neat visual effects. This is accomplished with a 2x2 matrix which maps screen space to background space.

Extended backgrounds I believe are just large bitmaps; I haven't read too much into these yet, but that will come soon.

I ran into a quick hiccup with the palettes; palette memory occupies 1 KB of space, but there are two different palette modes: 256 color and 16x16 color. Each palette entry occupies 2 bytes, so a quick calculation says that there can be 512 possible palette entries. 256 color mode should only use 256, and 16x16 color mode (16 colors split into 16 palettes), should really be 16x32 mode? Was it true that the palette only used 512 bytes of the 1 KB space?

I eventually had to look this up online, and found out that the 1 KB space is in fact split into two; backgrounds occupy the first 512 bytes, and sprites occupy the next 512 bytes!

This is the sort of answer that's unbelievably obvious when you uncover it. I figured that this had to be the case, but I couldn't quite put together the full explanation. I could have gone with the assumption and figured it out down the road, but lately I'm feeling that the best option is to be as trained as possible about everything that's happening in the system, as you never know when things change just because an assumption you made was wrong, or didn't factor everything in.

I've tried to avoid running another emulator in my quest to learn how the system works. This may seem like an unusual approach, but it has several key reasons. First off, emulators might not emulate the system completely correctly, so I can possibly get into situations where I'm not sure if my code is correct or the emulator's interpretation is correct. Furthermore, I want to keep my investigation to raw datasheets and reverse-engineering, as this is a clear limitation on my resources, which is tremendous practice for when the situation actually calls for a clear limitation with no other option.

Anyways, I'm getting pretty tired right now, so that's about all I have to write.