Ok, I had a few people helping me out on certain aspects of Zelda, but that was months ago and I have since lost those records. If you were working on something, please let me know. I am going to put together a dev team to help me with aspects of Zelda that I cannot program myself. The entire dev team will be credited for the release of this project.

Below is a list of things that need to be done:

1. Artificial Intelligence
2. Collision*
3. Bullet-like shooting system for hook/longshot and bow
4. Smooth scrolling rendering of greyscale graphics

*Collision: The collision with enemies I'm assuming is part of the AI. As for collision with tiles, I just need a way to convert the pixel by pixel Player movement into a way to check if collision with a tile has occurred. To clarify, the variables PlayerX and PlayerY are in pixels. If someone can tell me how to convert that number into a tile value, I can handle checking for movement onto illegal tiles myself.

Beyond that, there are a few other things that need to be done.

1. Compress map data (I can provide the data here, but the utilities will not run on Mac. Someone may need to run the data and post the compressed here).
2. In game-dialogue. I can handle this.

for collisions, just use (<pixel position>+<amount of pixels the screen has scrolled since the last tile change>)/<tile size>+<tile offset to the top/left most tile being displayed on the screen> to find the tile a specific pixel is inside. that means that, in order to find the tile above/to the left of your character you would make pixel position the player's position minus one, and to find below/to the right of it would be player position+player size+1

you can do enemy collisions the same way, storing the player's position somewhere and then checking the enemy position against it. it would use their absolute pixel positions (x,y on the screen+tile offset*tile size), though, and would have to use regions, though, so the check for a contact between the player and an enemy would be:
(player position < enemy position < player position + player size) or (player position < enemy position + enemy size < player position +player size), where the positions are the top/leftmost pixel in the sprite. you don't need to worry about having any <= in there unless you make enemies that move in increments larger than enemy increment+player increment, because link gets knocked back by enemies, so they will never be exactly on top of him.

zelda AI should be simple, as they're mostly just moving in straight lines and turning at random intervals or moving towards the player. bosses may be more difficult, though.

just make bullets a special type of enemy that moves faster and deal with them the same way.

/\that works, too, but means that you would have to draw everything to three buffers instead of two, or even more if you want to have insta-kill tiles, like holes, which could really slow things down.

EDIT: it might be faster to check for enemies that way, though, because all that math can slow things down.

Well, the method I use to determine if you have moved onto an illegal sprite is this...

I have two separate sets of position variables, Player X and Player Y, both 1-byte large, and PriorPosition, 2-bytes large but contains the Prior X and Y.

1. The movement is performed, so for all intents and purposes, your character has actually moved over one tile, regardless of legality.
2. I test the current position against the value of the tile.
3. If the tile value is illegal (one that you can't move on to), I write PriorPosition over PlayerX and Player Y.
4. If the tile value is one that causes damage, then the correct damage flag is set and the damage counter initiated.

Is the method you guys are proposing more efficient, if so, then we should do that, but it is beyond my coding ability. So is AI of any sort

For Zelda AI, it is rather simple.
Player 1 has coordinates (x,y)
Enemy has coordinates (r,s)
Make (r,s) try to occupy the same space as (x,y). In pseudocode:

If X>R
R+1→R
If X<R
R-1→R

If Y>S
S+1→S
If Y<S
S-1→S
I've made games using a similar algorithm. (In TI-BASIC, I used lists to have multiple enemies chasing you).

Ah, good point >.>
Are you familiar with the bresenham line drawing algorithm? If so, you can follow the same algorithm, except instead of drawing pixels, draw the enemy

I don't think so, but if they are moving pixel by pixel, they can make it look like it is moving in more directions.

if you are basing your enemies on those of the first zelda game, there doesn't have to be any diagonal motion at all except for zora projectiles, which can move in 16 directions and can't change direction once they start. other games are a bit more complicated, though. here are a few quick examples of how enemies move: