Author
I'm roughly 40% done with my Complete Overhaul hack of The Legend of Zelda, and have come to a point where many of my ideas require significant alteration of some of the original paradigms.
Lately, the major manifestation of this is with the dungeon bosses. For example, the Aquamentus (Level 1's lime-flavored wussdragon) sprite consists of a block of three 8x8 tiles horizontally, and four tiles vertically. (The game actually identifies "tiles" as being 16x8.) My Aquamentus replacement concept is best displayed with different dimensions, so it's not a matter of merely redrawing tiles in TLP or reconfiguring the tile pointers at $[11844-F].
Somewhere in the ROM exists a block of data which tells the game,
- Lime Wussdragon is 24 pixels wide and 32 pixels tall.
- These tiles are animated; these tiles aren't.
- Any H/V tile flipping, direct or implied.
- Look $here for actual tile pointers.
...for every boss character (as well as regular rank-and-file creatures). I imagine there might also be some info nearby about HP, damage potential, weapon susceptibility, movement patterns and/or palette references. But for now, I'm mostly concerned with the dimension/animation/flipping controls. The question remains, how does one find such data? Are there certain byte values which, when used in a certain context with each other, suggest that this is the sort of thing being programmed? Can one set a breakpoint for this data in a debugger?
After giving me a very thoughtful answer, Mr. Disch suggested I post this question publicly. To avoid redundancy, I've included his input below.
From Mr. Disch:
Quote
Easiest way I can think of is to corrupt. Figure out the tile IDs used by the sprite by looking at the PPU viewer. After checking Zelda briefly I see that the head of that dragon from level 1 is tile $C0 on the left-hand pattern table. Keep in mind this game uses 8x16 sprites, so tiles $C0 and $C1 on the left pattern table would be '$C0' in the game, and those same tiles on the right pattern table (which in this case seems to be graphics for the wall) would be '$C1' in the game.
ANYWAY, once you know one of the tiles is $C0, corrupt the ROM looking for $C0 and narrow it down until you find the byte in the ROM which controls the tile used for the dragon graphic (there might be more than one -- like a separate one for each frame of animation. If that's the case you'll probably want to find all of them, but they should be close together).
Other things, like X,Y positioning, H/V flipping, palette assignment, etc is probably all stored in the same chunk along with that tile ID. So once you find that tile ID you've probably found all the info you need to rearrange the sprite however you want. In-game formats may vary, but they probably keep it in the same order as the NES uses it which I remember as "YTAX (why tax?)" That's: Y coord, Tile number (what you're corrupting to find), Attributes (H/V flip, palette), X coord. The whole YTAX block is 4 bytes, and there's probably several YTAX's for the sprite layout with possibly a small header indicating how many YTAX's there are.
But this is a guess mostly -- like I say the game may do it differently. However it's a solid bet that if you find that tile number, you find the sprite layout. Even if it's not in YTAX form, it should still all be together. And worst case... if all the stuff is separate, finding the tile ID will at the very least give you a solid spot to set a breakpoint on and start tracing from in order to find the rest.
ANYWAY, once you know one of the tiles is $C0, corrupt the ROM looking for $C0 and narrow it down until you find the byte in the ROM which controls the tile used for the dragon graphic (there might be more than one -- like a separate one for each frame of animation. If that's the case you'll probably want to find all of them, but they should be close together).
Other things, like X,Y positioning, H/V flipping, palette assignment, etc is probably all stored in the same chunk along with that tile ID. So once you find that tile ID you've probably found all the info you need to rearrange the sprite however you want. In-game formats may vary, but they probably keep it in the same order as the NES uses it which I remember as "YTAX (why tax?)" That's: Y coord, Tile number (what you're corrupting to find), Attributes (H/V flip, palette), X coord. The whole YTAX block is 4 bytes, and there's probably several YTAX's for the sprite layout with possibly a small header indicating how many YTAX's there are.
But this is a guess mostly -- like I say the game may do it differently. However it's a solid bet that if you find that tile number, you find the sprite layout. Even if it's not in YTAX form, it should still all be together. And worst case... if all the stuff is separate, finding the tile ID will at the very least give you a solid spot to set a breakpoint on and start tracing from in order to find the rest.
(Moderator edit: BBCode does not work in the thread subject. Fortunately for us all.)
It just wasn't worth building a good engine that is variable for only 8 bosses. It's probably hardcoded just because they could.