Background Progress

I was going to write this last night, but I had to sleep early for a 7:30 AM dentist appointment...quite a start to the day.

As I wrote before, the DS has 4 different types of backgrounds: text, rotation, extended, and bitmap. Text backgrounds have about the same capability as what you'll find on the GBC or NES, while rotation backgrounds were very popular on the SNES.

As of now, I have text backgrounds working well; they render correctly, they scroll correctly, and my virtual memory mapper seems to be working well. I ran into a bug yesterday where I had loaded tile data into the sub core memory space, but no map data, and stuff was showing up on the sub core screen! To make it simpler, I was trying to get stuff to show up on both the screens; each screen has an associated core; the main core is the primary rendering core of the DS; it supports a few more styles, plus 3D...and can map more memory. The sub core is a secondary rendering core which has less memory at its disposal and lesser capabilities. Therefore, each core has its own virtual memory space, but for whatever reason, the sub core was taking data from the main core space. This was a bug in my virtual memory mapper; I wasn't doing a check correctly, so each memory read to this virtual memory space was always going through the main core.

My next task will be to read up on extended and rotation backgrounds; they seem pretty straightforward, albeit full of more features, so we'll see how that goes.

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.

Assembly Language Extasy

One thing about me: If there's ever an excuse to write assembly language, I'll take it and automatically try to shut down everything else. I did it about a year ago, when a friend needed some help with a bubble-sort-in-x86 assignment; I wrote it for him and then started writing everything in assembly language, including Space Invaders.

In messing around with the BIOSes of both chips, I've found that my focus has lacked a bit on the actual emulator. For instance, I made a stupid mistake in the memory manager; for each possible chip, I check to see if the address I'm trying to access can be accessed by this chip. I hacked together a quick two-register chip, and failed to write this validation function correctly (twice).

This sort of focus lapse is common when something is exciting, you just have to continue to remember why you're writing what you're writing, and on that focus, start to pick out the challenges and concentrate on them. I'm doing that just fine with assembly language, and the challenge it presents is an easy distraction!