[aml435]

Yeah unfortunately using Link's palette means that the rupee will also change color depending on what tunic/ring he has.
The same thing happens to the Sword and the Arrow/Bow as well, they change colors depending on what ring Link has.
Given that, I went ahead and made some mockups for the Rupees:

Original (Orange & Blue, used for Orange/Blue enemies as well):


With Link's palette:


With Moblin/Zora's palette:


I'm still on the idea that leaving it as plain orange without flashing is the best way to go about it, but I'm open for suggestions.

Either the orange or the Zora teal look great.

[ShadowOne333]

Shadow, in regards to changing how the hearts line up in the file select screen. I did line them up in the modern style for my Trial of Courage hack. The thing is though, the death counter is on top of your file name, not on the bottom.



and this right?



I'd have to find where I did that in code though, I haven't hacked Z1 since June-ish.

Hey 3Dude!
Thanks for dropping by!
For the in-game hearts, Automap flips them automatically, but I managed to find exactly what part of the code flips them in the overworld and dungeons:

Code: [Select]

// Flip heart rows in HUD:
org $A507 // $06517
db $20,$D6,$08 // Originally 20 B6 08
org $A512 // $06522
db $20,$B6,$08 // Originally 20 D6 08
But the one I haven't been able to flip are the hearts in the File Select screen.
The thing is, that the PPU transfer for the Name is tied to the hearts, only the one for the Death counter and the second heart line is handled separately.
I can flip them like you have them in your image if I change the [21 89 03], [21 09 11] and [21 12 08] found in three specific locations in the following code, but what I want to accomplish is to leave the Name and Death counter positioned where they are at the moment, and only invert the hearts.

I did some debugging a while ago, and managed to found this:

Code: [Select]

// Flip heart rows in the File Select Screen:
//Found the routines, now I just gotta figure out how to invert the heart printing
//A4C6: B9 54 A2  LDA $A254,Y @ $A258 = #$24 // 0xA4D6
//A254: 21 09 11 24 24 24 24 24 24 24 24 2F 00 00 00 00 00 00 00 00 // PPU Transfer for Name and lower (starting) hearts (0xA264)
//A268: 21 32 08 00 00 00 00 00 00 00 00 FF // PPU Transfer for upper Hearts (0xA278)

//A520: B9 74 A2  LDA $A274,Y @ $A278 = #$24 // 0xA530
//A274: 21 89 03 24 24 01 21 E9 03 24 24 01 22 49 03 24 24 01 FF // PPU Transfers for Death counter(s) (0xA284)
The point of interest here is not the PPU transfers, but the routine around 0xA4D6 (the one at 0xA530 seems to handle the Death counter).
Those two routines are the ones that I believe print the hearts, as those two load the PPU transfers for the hearts.
Although, given my somewhat limited knowledge on ASM, I have not been able to figure out exactly what part tells the game where to print the hearts specifically.

[The3Dude]

Oh! Sorry I put the wrong image, I meant this.











Also, my ASM knowledge is extremely limited .

[ShadowOne333]

Oh! Sorry I put the wrong image, I meant this.


Also, my ASM knowledge is extremely limited .

Hahah don't worry.
I was able to view that image if I opened the link in another tab
But yep, that one part in particular is the one I want to change, but I want to leave both the name and death counter intact, and only flip the hearts.

I will continue researching those two routines, hopefully I can find what part determines which hearts go to what row.

[Trax]

Well, I tackled the flashing problem. Against all odds. The color switch is 8 frames, and applies to a few objects, like small hearts, Triforce pieces, etc. I looked for all occurences of RAM $15, which is a frame counter. So, starting at 1E735, there's code that determines which items should be flashing. So replace this code with NOPs (EA) :

Code: [Select]

1E73D: E0 16 CPX #$16 ; Number of Rupees (66D)
1E73F: F0 0C BEQ $1E74D
That's it, no more flashing rupee. At 6B5C, there's a table with palette codes for various things. Change value at 6B72 to make the rupee another color if you want.

[ShadowOne333]

Well, I tackled the flashing problem. Against all odds. The color switch is 8 frames, and applies to a few objects, like small hearts, Triforce pieces, etc. I looked for all occurences of RAM $15, which is a frame counter. So, starting at 1E735, there's code that determines which items should be flashing. So replace this code with NOPs (EA) :

Code: [Select]

1E73D: E0 16 CPX #$16 ; Number of Rupees (66D)
1E73F: F0 0C BEQ $1E74D
That's it, no more flashing rupee. At 6B5C, there's a table with palette codes for various things. Change value at 6B72 to make the rupee another color if you want.

Oh that's fantastic!
Just NOP'd those two opcodes, and indeed the rupee is no longer flashing, it stays at a static orange color now, thanks!
I also went ahead and tried changing the palette for the rupee, but without a doubt the orange one is the one that looks the best. I could make it work with Link's palette, but the fact that palette changes doesn't make it suitable.
I will make an optional patch that changes the orange for green later on.
Thanks again, Trax!

---------------------------------------------------------------------------

In the meanwhile, I did some more research regarding some of the still unlabelled RAM addresses in the range of 600-700, mostly documented what seems to be RAM addresses related to the File Select screen.
I did find what some of those are and have update the Data Crystal entry accordingly:
https://datacrystal.romhacking.net/wiki/The_Legend_of_Zelda:RAM_map#RAM

---------------------------------------------------------------------------

I noticed that some of the data I wrote for the hearts in the File Select screen was wrong, I just corrected it, here's the proper data:

Code: [Select]

// Flip heart rows in the File Select Screen:
//Found the routines, now I just gotta figure out how to invert the heart printing
//A4C6: B9 54 A2  LDA $A254,Y @ $A258 = #$24 // 0xA4D6
//A254: 21 09 11 24 24 24 24 24 24 24 24 2F 00 00 00 00 00 00 00 00 // PPU Transfer for Name and lower (starting) hearts (0xA264)
//A268: 21 32 08 00 00 00 00 00 00 00 00 FF // PPU Transfer for upper Hearts (0xA278)

//A520: B9 74 A2  LDA $A274,Y @ $A278 = #$24 // 0xA530
//A274: 21 89 03 24 24 01 21 E9 03 24 24 01 22 49 03 24 24 01 FF // PPU Transfers for Death counter(s) (0xA284)
---------------------------------------------------------------------------

Last, I found out that there's one existing hack that does implement values above 255 in the rupee counter!
Although...  It's one of those "bad" hacks, so it's not available in RHDN.
I started dissecting the ROM, ditching the sprite/text/palette changes, and I managed to disassemble it a bit:
https://pastebin.com/uqw123pu

It's not a 100% disassembly, but it's something at least to start working on the 999 rupees.

Some points of interest regarding this >255 implementation:

• The way it works currently, is that a second counter appears below the rupee counter.
• Whenever the rupee counter goes above 255, the code adds one to the value of the below counter.
• The new counter goes up to FF (I think), so it's possible to have up to 65535 rupees. Obviously I would modify it to limit it to 999 rupees instead.
• The new counter uses RAM address $660 for it, which overlaps with the bit/byte for raft. This can easily be avoided by using another RAM address, which is why I started looking into what some unlabelled RAM addresses do.

Considering the above points, what needs to be changed is:

• Repoint or move the code so it doesn't collide with any existing code in Redux.
• Make it so that the "new counter" is not parsed as a separate counter, but rather the values should modify the currently existing counter for the rupees directly, adding to the 255 value whenever it's needed.
• Limit the maximum amount of obtainable rupees to 999.
• Assign a new RAM address to the code, so that the Raft byte ($660) remains exclusive to the raft and doesn't overlap.

[lexluthermiester]

With Link's palette:

Personally, I think this looks great! The red could be a 10 or 20 rupee value item.

[Trax]

You have two avenues for new RAM usage. Either you use CPU RAM, but the trade-off is that you need to save the value in VRAM (cartridge RAM) when saving and reload it in CPU RAM when loading a game. You also have to consider the 3 save slots. Or you use VRAM directly, and it gets saved automatically.

Also, one place that is often overlooked is the CPU stack. High values in the 100-1FF range are rarely used because the stack never goes that high.

[ShadowOne333]

You have two avenues for new RAM usage. Either you use CPU RAM, but the trade-off is that you need to save the value in VRAM (cartridge RAM) when saving and reload it in CPU RAM when loading a game. You also have to consider the 3 save slots. Or you use VRAM directly, and it gets saved automatically.

Also, one place that is often overlooked is the CPU stack. High values in the 100-1FF range are rarely used because the stack never goes that high.

From what I tested on that romhack, the amount of rupees collected past 255 do get saved on game load as well.
As for the RAM, are there any unused addresses within the 600-700 range?
From what I tested, I couldn't find anything that seems to call RAM $672 and $673, so maybe the whole rupee calculations could be moved to those two (High byte for >255, low byte for =<255).

-----------------------------------------------------------------------------

Out of that, I also started some research into using the Select button for switching the selected item for the B button.
I found that the routine which checks for the Select button to enable Pause is located at $1EC1B. The check for the button is at $1EC38 (CMP #$20).

I started doing some dummy code to make the Select button press change whatever item is selected, this is what I have at the moment. I've been testing this code with an online assembler for 6502 to see if it's giving me the correct values I need, so I haven't tested this in-game yet.

Online Assembler:
https://www.cs.otago.ac.nz/cosc243/resources/6502js-master/namedconsts.html

Code:

Code: [Select]

    INC $0656 ; Increment value at $0656
    LDA $0656 ; Load value from $0656
    CMP #$02  ; Is the item position $02?
    BEQ check_bow_arrow
    CMP #$09  ; If $0656 < 9, reset to $00
    BCC end
    LDA #$00
    BCS set_selection ; Carry is known to be set, so this act as a "BRA" from 65816

check_bow_arrow:
    LDA $065A ; Does the player have the bow? (0 if no)
    BEQ select_04
    LDA $0659 ; Does the player have arrows? (0 if no)
    BNE end

select_04:
    LDA #$04

set_selection:
    STA $0656

end:
    RTS
The only part that doesn't seem to be working is the "check_bow_arrow" routine, which for some reason doesn't work if $0659 is set to $01.

So what should that code do:

• Hijack the original Select button code to bypass the Pause and change an item instead (STILL NOT IMPLEMENTED). I haven't found the exact point to hijack to bypass the "Pause" altogether
• Increments the value found at RAM address $0656 (which determines what item is in the B button)
• The item selection should cap off at $08. Reason being that the items in the menu go from a value of $00 (Boomerang) to $08 (Magic rod). However, values $09 and above are also possible, but those items are the Raft and the other key items which cannot be selected, so the code needs to check if the increment has reached $09, and if it has, then reset the value to $00 to avoid this problem
• Something interesting happens with the Bow/Arrow items. If you have the bow but not the arrow, the menu completely bypasses selecting the bow on its own, jumping from value $01 (Bombs) up to $04 (Candle), completely bypassing values $02 (Arrow) and $03 (Bow). This is the part that currently is not working properly, as the address that checks if you have the bow or not is $065A (00 = Nothing, 01 = Bow)
• As with the above point, the code also needs to check whether or not the player has purchased the arrow or not in order to know if the cursor/selected item should actually fall into the arrow position in the menu ($02) or bypass it if the player has the bow, but not the arrows. The ram address which holds the value for the arrows is $0659 (00 = No arrows, 01 = Normal arrow, 02 = Silver arrow)
• Currently, the code works as far as resetting the value when it hits 09, but I haven't been able to implement the bow/arrow check into the routine yet

Also, another thing worth mentioning, I haven't found a proper way to bypass the "Pause" when pressing the Select button, so I don't know exactly where to hijack the original routine to completely remove the "Pause" altogether to use my custom code for this.


I'm not that adept at assembly programming, I did this code with the little I know, so any help with what remains to be done for the code (and the hijack portion for it) would be appreciated!

[Trax]

I think $672 is for Ganon's Triforce. I have nothing for $673 in my docs, so I can't say for sure.

As for the programming of the 999 rupees, again, I can see two choices. You can use 2 bytes for the number itself, and cap it explicitly at 999. This is very easy when doing ADC and SBC, but more complex when you have to actually break down the 2 bytes into 3 digits to display on screen. Or, you could use 3 bytes that represent the 3 digits separately. It's not as straightforward for additions and subtractions, but it's considerably easier to display.

[DannyPlaysSomeGames]

Personally, I think this looks great! The red could be a 10 or 20 rupee value item.

I was going to say that the problem is that the rupee wouldn't be the same color because it would keep changing color due to tunics.

But then that thought gave me an idea: what if the ring/tunic you wore affected the value of the 1 rupee? Like maybe when Link starts off normal, he encounters green rupees (that match his tunic) worth 1 and blue rupees worth 5. Afterwards, when he gets the blue ring, all the rupees he encounters are blue (the ones that match his palette and the ones that are regularly blue), so he always gets 5 rupees. Finally, when he gets the red ring, he can get regular blue rupees and red rupees, worth 20. Not only would this solve the situation of the rupee's color being inconsistent, but it's also a very convenient upgrade that helps grinding, considering that arrows are planned to have a separate counter now, and would need to be frequently bought from shops. That's just my suggestion though.

[lexluthermiester]

I was going to say that the problem is that the rupee wouldn't be the same color because it would keep changing color due to tunics.

But then that thought gave me an idea: what if the ring/tunic you wore affected the value of the 1 rupee? Like maybe when Link starts off normal, he encounters green rupees (that match his tunic) worth 1 and blue rupees worth 5. Afterwards, when he gets the blue ring, all the rupees he encounters are blue (the ones that match his palette and the ones that are regularly blue), so he always gets 5 rupees. Finally, when he gets the red ring, he can get regular blue rupees and red rupees, worth 20. Not only would this solve the situation of the rupee's color being inconsistent, but it's also a very convenient upgrade that helps grinding, considering that arrows are planned to have a separate counter now, and would need to be frequently bought from shops. That's just my suggestion though.

That is a very interesting notion. How possible is it, do you think?

[erpster2]

Change the duplicate bosses in Level 4 and 7 (Gleeok and Aquamentus) to Lanmola and Patra respectively.

changing the boss for level 7 to Patra is fine (use the circular & "unpredictable" version of Patra to up the challenge, hee-hee - I mean the one where a group of small patras expand and contract unpredictably) but I like the "weaker" Gleeok boss in Level 4

[ShadowOne333]

changing the boss for level 7 to Patra is fine (use the circular & "unpredictable" version of Patra to up the challenge, hee-hee - I mean the one where a group of small patras expand and contract unpredictably) but I like the "weaker" Gleeok boss in Level 4

Went ahead and made an optional patch for the bosses.
I called it "RearrangedBosses.ips", and this is what it changes:

• 1st Quest - Level 4: Changes the Manhandla in the level to Red Lanmolas, keeps the two-headed Gleeok at the end
• 1st Quest - Level 7: Changes the Aquamentus for a Patra with Oval attack cycle
• 2nd Quest - Level 2: Changes the two-headed Gleeok to Blue Lanmolas (You can still fight a two-headed Gleeok in Level 6)
• 2nd Quest - Level 8: Changes the 3 Dodongos to a Patra with Circle attack cycle

I decided to have all of the head-variants for the Gleeoks present in both Quests, so you can fight the two, three and four head variants of it in both quests. Manhandla is the only boss that doesn't appear in 2nd Quest.

[DannyPlaysSomeGames]

Went ahead and made an optional patch for the bosses.
I called it "RearrangedBosses.ips", and this is what it changes:

• 1st Quest - Level 4: Changes the Manhandla in the level to Red Lanmolas, keeps the two-headed Gleeok at the end
• 1st Quest - Level 7: Changes the Aquamentus for a Patra with Oval attack cycle
• 2nd Quest - Level 2: Changes the two-headed Gleeok to Blue Lanmolas (You can still fight a two-headed Gleeok in Level 6)
• 2nd Quest - Level 8: Changes the 3 Dodongos to a Patra with Circle attack cycle

I decided to have all of the head-variants for the Gleeoks present in both Quests, so you can fight the two, three and four head variants of it in both quests. Manhandla is the only boss that doesn't appear in 2nd Quest.

Actually, that reminds me, isn't there an unused Gleeok with one head? Either way, the boss patch seems like a pretty great idea. I was wondering what happened to this thread a while back but good to hear you're still working on it.

Also, I was curious if that rupee idea I posted was anything worthwhile.

[Trax]

It could be interesting to have a stronger and more aggresive Aquamentus, kinda like a "revenge", or as an alternate version, like the Orange/Blue Gohma.

[aml435]

It could be interesting to have a stronger and more aggresive Aquamentus, kinda like a "revenge", or as an alternate version, like the Orange/Blue Gohma.

Maybe an orange or blue Aquamentus that was only weak to a certain weapon and maybe had statues in the room providing supporting fire could be interesting... or maybe if it telegraphed blowing fire and you had to shoot arrows into it's mouth when it opened it's mouth to shoot fireballs at you in order to hurt it. Though this would probably be complicated to add into the game.

[Trax]

A version of Aquamentus that you can only beat with the Magical Rod would be interesting.

[EthansDreamLand]

Went ahead and made an optional patch for the bosses.
I called it "RearrangedBosses.ips", and this is what it changes:

• 1st Quest - Level 4: Changes the Manhandla in the level to Red Lanmolas, keeps the two-headed Gleeok at the end
• 1st Quest - Level 7: Changes the Aquamentus for a Patra with Oval attack cycle
• 2nd Quest - Level 2: Changes the two-headed Gleeok to Blue Lanmolas (You can still fight a two-headed Gleeok in Level 6)
• 2nd Quest - Level 8: Changes the 3 Dodongos to a Patra with Circle attack cycle

I decided to have all of the head-variants for the Gleeoks present in both Quests, so you can fight the two, three and four head variants of it in both quests. Manhandla is the only boss that doesn't appear in 2nd Quest.

I appreciate the patch, but I feel like there's a glitch with it. I was playing the redux game with the patch, but when I got to Dungeon 9, the room filled with Wizzrobes that leads to the room containing the Silver Arrows leads to a room that contains two Blue Lanmolas with no entrance to the Silver Arrows room, which leads to a glitched room that only leads outside the dungeon, making the game unbeatable. Can you please fix this?

[ShadowOne333]

Actually, that reminds me, isn't there an unused Gleeok with one head? Either way, the boss patch seems like a pretty great idea. I was wondering what happened to this thread a while back but good to hear you're still working on it.

Also, I was curious if that rupee idea I posted was anything worthwhile.

Oh yeah there's a Gleeok with one head that's unused in the final game, though I don't know where it could be implemented, if at all, since a one-head Gleeok kinda kills the challenge of Gleeok, being one head attached and one floating around attacking you.
As for the rupee stuff, the concept is kinda neat too, and would add a feature to the tunic beside extra protection.
As for implementation, I am not sure, it would for sure require extra coding, but seems like the work for it might not be worth the effort.

It could be interesting to have a stronger and more aggresive Aquamentus, kinda like a "revenge", or as an alternate version, like the Orange/Blue Gohma.

A blue variant of Gleeok sounds cool, his sprite in that palette would be nice to look at!

I appreciate the patch, but I feel like there's a glitch with it. I was playing the redux game with the patch, but when I got to Dungeon 9, the room filled with Wizzrobes that leads to the room containing the Silver Arrows leads to a room that contains two Blue Lanmolas with no entrance to the Silver Arrows room, which leads to a glitched room that only leads outside the dungeon, making the game unbeatable. Can you please fix this?

I noticed that for some reason that room got changed, even though I didn't touch it at all.
I reuploaded the patch, with the room (hopefully) restored, could you try it out again, please?