So... I'm working on the staff credits for Zelda II: The Adventure of Link. The titles and names themselves have turned out just fine, but I've hit a snag when trying to expand the "Staff" string from 5 characters to 8.

This string is a bit unusual. One oddity is that it has its very own special font, which only happens to look the same as the rest of the game's text. Well, no problem there - a few minutes with a tile editor fleshed out the special font with the letters I wanted.

The second oddity is causing me significantly more trouble. (Almost?) Every other string outside the main dialogue follows the same handy format: 2 bytes to give the string's position, 1 byte to give the string's length, the string itself, and then a terminating FF byte. The "Staff" string, however, has an additional 20 bytes between the string and the terminator which trigger some palette swapping.

I can move the entire 29-byte chunk to someplace with more room and everything stays peachy. But when I try to expand the string from 5 characters to 8, something goes wrong and I end up with screen garbage after the string is printed (I'm fairly certain my extra 3 bytes aren't overwriting anything important). After some trial and error, I've found that if I chop off the last 4 palette bytes, I don't get screen garbage, but I also don't get the palette swap those 4 bytes trigger (the one that keeps "H.Yamauchi" black/black until it swaps into white/purple).

It's not a huge issue, since everthing works fine after that, but still... I want my palette swap! And so I turn to you, o members of RHDN. Does anyone have any insight to offer on my problem or advice on how to crack it?

I don't mean to sound like a wiseass, but did you remember to alter the "string length" byte from $05 to $08? (That would be the first thing I'd ask myself were I in your shoes.) It sounds like you have a very good grasp of what you're doing, and perhaps more importantly, the pitfalls that might be encountered while getting it done. When one is trained and focused on such higher-level tasks as ASM routines and palette swaps, it can be easy to overlook something as simple as a control byte.

If that isn't the case, I'd be interested in finding out just what those three irreplaceable bytes are. You said you moved the entire 29-byte sequence and everything worked fine? That suggests against a subroutine buried elsewhere having a pointer directed to that very spot...

I don't suppose it's feasible to move the entire CREDITS sequence back three spaces?

You're in good company. I spent weeks parsing my way through a certain ASM sequence in Zelda 1, only to find that the alterations I wanted to make wouldn't require anything more than a simple 8-byte overwrite at a mostly-overlooked location.