nesdev.org

Now that I think of it, you don't NEED to have only 64 symbols to use a mix of DTE and TTE (although I don't see why anyone would want to use more than 1/4 of the tileset just for text - unless when doing midscreen CHR swapping).

Numbers 0 to 127 could mean uncompressed characters, like said before. But if the 8th bit is set (> 127), that would mean compression. Half of the codes could be for strings that are 2 characters long and the other half for 3 characters long, so you have 64 of each. Or this distribution could be arranged differently, with more codes indexing pairs of characters, if this works best.

But then you don't have that "4th mode" that Bregalad talked about.

EDIT: commodorejohn had a nice idea. Combining a dictionary with DTE might work quite well.

Another possibility is using DTE codes within the DTE table itself.

That gives you a way to have single byte encodings of 3 or even 4-letter words (though it takes up more than one code, so you would only want to do it for very commonly-used words).

Edit: re tokumaru's idea, is there any reason it has to be a power of 2 range? Just partition the 256 codes into whatever ranges give you the best compression, even if that means 49 single characters, 97 two-byte DTE codes and 110 three-byte codes.

The reason we've been going with powers-of-two (specifically, 128 normal characters and 128 DTE characters,) is because, when the value is loaded into the accumulator, its high bit gets copied to the status register's Negative flag (i.e. the high bit is treated as a sign bit,) allowing us to simply BMI to detect DTE entries rather than having to use compare instructions. You certainly don't have to do it that way, it just saves some cycles.

But seriously, why would you need to worry about saving a few cycles per letter in a NES game? How often do you plan to write a letter to the screen anyway? Most games even spit 'em out at a typewriter's pace for aesthetic reasons.

The only situation I can think of is if you would need to do a lot of random accesses to specified lines/positions in the text. But then, you're probably better off re-thinking the message engine itself. CPU usage ain't much of an issue in text compression for video games. Memory usage, on the other hand...

Like I said, you really don't have to if you don't want to. I did so in my example code because it was written assuming that the text characters were located at the ASCII positions in the tile table, and therefore printed text (excepting foreign-language text which uses the accented characters,) wouldn't use the top 128 tiles. Writing an LDA and a BMI was just a whole lot simpler than writing a series of compares and BEQs, especially since I was only demonstrating how DTE would work, before we got into discussions on other algorithms and combining algorithms. My method works. Your method would also work. You're right in that text display isn't processor-intensive; I just did it that way because it was easier and because I believe efficiency is always a good thing, especially when easily achieved.