Though most changes introduced with each revision to the DS firmware had minimal visible difference, the 2005-02-28 version does introduce a bug fix for the initial setup language selection GUI. Before, you could input the Back button before the animation completes, cutting off the selection sound.
A comparison of the text with and without the kerning adjustment. The difference is 1 pixel, but makes the difference between awkward spacing and good looking spacing.
The BNFR font file format used by the firmware does not have support for kerning pairs, so the spacing between the L and T in "HEALTH" would appear too wide. The BNLL file splits the text at this point and moves the letters 1 pixel closer together. This is only done for English. [2/2]
A preview of the English health-and-safety BNLL file. The heading ("WARNING - HEALTH AND SAFETY") is split into two messages around where the L and T meet in the word HEALTH.
In the DS firmware boot menu, the health and safety heading text is split into two separate text elements to adjust for kerning in the word HEALTH. This is controlled by a BNLL file, which defines text and where it goes on the screen. [1/2]
By the version 2006-03-08, the firmware is no longer applying the patch on the basis of game title ID, but by scanning for the applicable code sequences in the game's code. I'd like to write a full comprehensive list of all changes between versions some time, but that will take a while. [6/6]
The patches affect game title IDs ADMx (Animal Crossing: Wild World, all versions), ASCx (Sonic Rush v0), AYAJ (Big Brain Academy v0, v1), ATGJ (Daredemo Asobi Taizen v0), ABLJ (The Blade of Fate v0), and AM9J (Lost Magic v0). These patches are not applied in the IS-NITRO versions. [5/6]
The DS wireless patches were introduced in firmware version 2006-02-05 following discussion of games having wireless errors on the DS Lite's updated MAC. They patch the WaitLoop_ClrAid function to check for MAC states of MP response and pre-response. [4/6]
One notable thing I found is that the code for download play patching for Super Mario 64 DS was only added in the version 2005-02-28. This version also replaces their slow ASH decompressor written in C to one written in assembly. [3/6]
The two IS-NITRO-EMULATOR firmware versions dated 2006-02-20 (original controller and USG controller) are actually identical in code and data, only differing in the IPL2 type field in the header, where the USG controller version sets the USG bit (which allows configuring the backlight level). [2/6]
I've been examining the differences between different DS firmware versions, I'm surprised that there isn't much information about what's different between them. [1/6]
Took some time this week to write up a quick and dirty program for operating on DS firmware images. Can clean/replace user data, extract/replace modules, fix errors and more. Find it at github.com/Garhoogin/fw.... :)
Given the final result, it's clear that there's nothing specific to 24-bit RGB values here, nor does the color channel order have any effect. This can be adjusted to other channel widths by changing the OR bitmap. For 15-bit RGB, for example, use 0x4210. [9/9]
It becomes clear that all we're doing after right shifting the color one place is separating and re-combining parts of the color. It can finally be simplified: [8/9]
It becomes apparent now that since we're going to be setting the most significant bit of each channel with the final OR with 0x808080, we don't need to worry about clearing the upper bit of each channel. We'll rearrange some shifts: [7/9]
We can pull out the right shifts on each of the channels next by combining some shifts: [6/9]
We can pull some operations out. First, we can eliminate some of the OR operations: [5/9]
int r = (c >> 0) & 0xFF, g = (c >> 8) & 0xFF, b = (c >> 16) & 0xFF; r = (r >> 1) | 0x80; g = (g >> 1) | 0x80; b = (b >> 1) | 0x80; c = (r << 0) | (g << 8) | (b << 16);
Given y is 8 bits, right shifting it one place gives a 7-bit value. Because the addition will not produce any carries, it can be written with a bitwise OR operation. Applying this to all channels gives the following code: [4/9]
I want this to round half up to the next whole number, so I will add 1 before dividing by 2. This gives y'=(y+256)/2. In bitwise terms, this last equation can be written y'=(y+0x100)>>1. The addition can be pulled out, giving y'=(y>>1)+0x80. [3/9]
Here, I define colors as a 24-bit value where the least significant 8 bits are the level of red, then the next 8 bits are the green level, then the blue level. The formula I use to average a color with white is to apply an averaging on each channel with 255. This looks like y'=(y+255)/2. [2/9]
A cool bit trick I've picked up is a really quick way to average an RGB color with white. In the end, the whole process is reduced to just two operations. Over the course of this thread I'll walk through my process of coming to this conclusion, and hope that you might find it interesting. [1/9]
Guessing this is a resource saving mechanism? Mario Kart DS does something similar for Download Play, to reduce memory and download time. Perhaps it was considered a minor detail and worth cutting corners on?
Overall, you get a 3 bits-per-pixel texture data (2 bits per pixel in texel data plus 1 bit per pixel, on average, in index data), plus the size of the palette. Using good techniques in the encoder, you can achieve a really strong quality of compression. [7/7]
There's other opportunities for optimization too. You may choose to use transparent mode on an interpolated tile even when it has no transparent colors if the interpolated color is better fitting the colors in that tile than the 2 you'd get without it. [6/7]
This makes encoding difficult, since it allows not only for palettes to be shared, it allows them to be overlapped. Two 4-color palettes may share 2 of their colors, for example. Or even more confusingly, a 2-color interpolated palette can have its colors used as part of a 4-color palette. [5/7]
There's one final flag stored in the index data, which indicates the tile uses a transparent color mode. For the interpolated color mode, this gives only one interpolated color, and color index 3 becomes transparent. For full 4-color mode, you lose the third color for transparent. [4/7]
In addition to this, the index data includes a flag to select a 4-color mode instead of 2 colors and 2 interpolated colors. This opens up a lot of opportunity to extract more texture quality out of the format. The palette index is still in terms of 2-color palettes, however. [3/7]
For one, rather than storing 2 colors with the 4x4 block of pixels, the colors are stored in a palette separate from the texture data, and a 16-bit unit of data (index) associated with each 4x4 block gives the palette index for that tile. This allows multiple tiles to share a single palette. [2/7]
Texture compression on the DS is such a tricky thing. In a way, it's structurally similar to common DXT texture compression. It's just different enough to make it a huge pain to encode. [1/7]
That would make sense, there's definitely not enough hanzi in this glyph set to represent much meaningful Chinese. This image I just rendered from font 0 (main font) in my IS-NITRO's firmware, so I'm sure a JNFR from a Chinese firmware would be a good bit larger.
Set of glyphs included in the DS firmware's main font
In a way that makes sense, given that the font the banner text renders with has the following glyphs to use, none of which appear Cyrillic that I can tell:
For other languages, the search order is English, German, French, Spanish, Italian, than Japanese. If no banner text is available in any language, then the firmware uses the user's current language (i.e. shows no text). [3/3]
