The most tedious thing of Zelda 1 (and the main reason it became my worst game ever played), is starting with 3 hearts each time you die. I'm quite surprised (an understatement, to be honest) a fix for that isn't included in the list of changes.
That's one of the points yet to be done for the main hack.
You can see it in the OP:
- Save the amount of hearts you last had if the game was saved manually, so when you load, you start with the same amount of life (this I'm not sure if it will be implemented in the end hack)
- Implementation of a Copy/Erase file system like in subsequent Zeldas, where D-Pad Up and Down control the cursor in the File Selection and pressing A brings up the Name screen (Example: ALttP)
- Add water animation (possibly by converting the ROM to MMC5?)
- Diagonal sword swing
I'll see what I can do about that. I think I can modify the code to make Link always spawn at full health, but the optimal way to do it would be for the custom routine to detect the current amount of hearts Link has, and then save that to RAM, so the next time you boot the game, you start with those exact hearts. The only exception would be if Link is below 3 hearts, or if he dies, then he should respawn with 3 hearts. Only when he has above 3 hearts should be hearts after a boot be kept.
I know RAM address $066F is the one that gets set when booting a save file. It's always the current number of heart containers in the high nibble, and always $2 is the low nibble. So if you have, let's say, 9 hearts in our meter, the game loads $92 (9 hearts with 3 filled), 10 hearts would be $A2 (10 hearts + 3 filled), etc. So the game always sets 3 hearts to be filled regardless of containers.
I tried doing a bit of debugging to track down where the game sets this value at save boot, but I haven't figured it out the exact place that sets the value, nor how to hijack it.
Now that we are on topic about the things left to be done for the project...
I think I will have to cut down on some of the things for it.
As soon as the animation and the current reworked credits are working, I think I will call it complete and release the hack like that. For as much as I'd like to add the Diagonal sword swing to Zelda 1, that's far beyond my reach (heck, even the animated tiles are tbh), and I really don't want to let this hack go into hiatus for years like Zelda 2 Redux did, and that one still had one last thing I wanted to have in it, but hasn't been done yet.
With that said, the final list of things to do for Zelda 1 Redux would probably look like this:
- Add water animation. Either by using the current CHR-RAM method, or changing to CHR-ROM or MMC3)
- Rework the Credits for the game to have full names show up for each developer (like in Zelda 2 Redux)
For the Credits thing, I mentioned this before, but this is what I'm aiming for:
Current Credits / Mockup Desired Credits
As you can see, I managed to get some of them to look like the mockup.
However, I'm missing, a way to separate "PRODUCER, DIRECTOR, DESIGNER, PROGRAMMER" into their own lines, separate from the actual names. Basically, just being able to have an additional row/line below those 4 so I can add the full custom name for the developer. I think the code related to the handling of this is somewhere around bank 2 (I believe it should around 0xA800-0xBFFF), but I haven't pinpointed where exactly.
Here's the original post where I asked for help with this, for more details:
I remembered I wanted to do another thing in Zelda 1 which I couldn't tackle as well before, and that's to add the proper full names to the credits of the people involved in the game, instead of using nicknames.
The way I have it right now, I had to sacrifice the first name, and I only added the full last name to the credits.
I tried making my mockup work in-game, and while I did accomplish the result I wanted for "Executive Producer: Hiroshi Yamauchi" and "Sound Composer: Koji Kondo" exactly as in my mockup, the rest I couldn't replicate as I wanted, mainly because the way the credits are printed doesn't allow for such formatting on the screen.
The pointers for this are separated into two parts, a table with the low bytes of each entry's pointer (at $AC2E), and another table with the high bytes of each entry's pointer (at $AC45). The code that seems to handle all of this is located between $ADF9 (0xAE09) and $AE90 (0xAEA0).
Basically, what I'm looking for is being able to break the "Designer" and "Producer" lines into two lines instead of one, the "Director" lines into 3 lines instead of 2, and the "Programmer" lines intro 4 lines instead of 3.
Current Credits / Mockup Desired Credits
I found something rather interesting while trying to debug the Credits sequence.
RAM Addresses $302, $303, $304 and $305 are loaded and handled separately from tables to setup the PPU transfers for the credits. At $AC16-$AC21, there's a table for the first part of the PPU transfer for each entry.
[28 29 2A 2B 20 21 22 23 28 29 2A 2B]
At $AE4E (0x0AE5E) is the code that sets this up.
02:AE4E:BD 16 AC LDA $AC16,X @ $AC17 = #$29
02:AE51:8D 02 03 STA $0302 = #$FF
It's a simple Load -> Store done within a loop.
After that comes another table at $AC22, which seems to have something to do with the Y-Position of the credits in the scrolling text, but I'm still not sure how that one works.
At $AE96 seems to be where the actual code related to the positions of the credits is located.
As for the actual code/routines that handle the entirety of the Credits, it seems to start at $AE15 and up to $AF8F (0x0AE25-0xAF9F in PC address). So the hijack to add 4 more lines to the Credits should be somewhere in there.
I will see what else I can gather.