So what's your approach? Do you dma the tile data from a buffer into vram, or do you directly edit vram? (It begins at 7F, doesn't it?).
I usually use a buffer in tilelength and just dma this buffer after write of a character (or full tile) to vram. Some gfx routines i've seen in games tend to use the method of constantly working in vram though, which slows down a whole lot.

cYa,

Tauwasser

Bongo: nice idea but unfortunately I can't skip the space character in LTTP. That is, unless I implement some other way of clearing the screen or a line, which I could do. Some of the game's original text relies upon being able to use 42 spaces to clear a whole line (they're 4 pixels wide a piece).

Tauwasser: VRAM is a separate entity unto itself on the SNES. I'd say in my situation you can ignore VRAM for all intents and purposes. $7F0000 is just the start of the second WRAM (work ram) bank. The only difference between my approach and the game's original approach is how the data is written to the WRAM buffer for the text. The old method is to to examine every pixel of the character (which is referenced from ROM) and copy it to the buffer by first masking out any existing pixel data there, then writing the actual character's pixel value. This is done *bit by bit* which I found to be obnoxious. I opted to copy a row of 8 pixels (a 2 byte value) from the character, then use the character width to mask out the pixels, and finally use the buffer position (in pixels) to rotate the data appropriately (with the data that gets shifted out being used for the next tile). Before I can copy it though, I need to select a mask (based on the buffer position to erase the contents of where I intend to copy to. In theory I thought this would speed it up (copying up to 16-bits instead of 1 at a time, but the extra overhead has made the gain minimal :/.