[ShadowOne333]

Flips and Lunar IPS are my go to patchers, but I also tested with the RHDN online patcher and the MMC1 patch was still glitched.

I think John and Feisty are referring to the MMC5 one.
MMC1 it's known to glitch out on Everdrive due to the iNES 2.0 header.

That's why I'm looking for someone that can make proper MMC1 reproductions to test the MMC1 version on a real PCB on real hardware.

[SuperFeistyFox]

I think John and Feisty are referring to the MMC5 one.
MMC1 it's known to glitch out on Everdrive due to the iNES 2.0 header.

That's why I'm looking for someone that can make proper MMC1 reproductions to test the MMC1 version on a real PCB on real hardware.

Yeah, the MMC1 is glitched, so I got the MMC5 version installed on my Everdrive using Lunar IPS, which works just fine.

[Pleiades7]

I think John and Feisty are referring to the MMC5 one.
MMC1 it's known to glitch out on Everdrive due to the iNES 2.0 header.

That's why I'm looking for someone that can make proper MMC1 reproductions to test the MMC1 version on a real PCB on real hardware.

Hey there... on a separate note. There was an early tree graphic, the once you first proposed, for the hidden bush you had to burn to get to a hidden dungeon, etc. It was SO much better than the one you chose by committee. Any chances you could give us graphic as an optional patch? If it is not too much work, would love that. Thank you!

[InAnotherCastle]

This is why I want to ask if there are any reproduction makers following this hack, if they can make a proper test of the MMC1 version in a real NES with a reproduction/donor MMC1 board.

My goal was to make a cart of this hack once done testing the MMC5 version. And this was only the target because the MMC1 one failed in testing As far as I know there are no official 32kb CHR RAM boards for MMC1, so I'll check if I have any MMC1 donor boards which would be suitable for such an experiment.

[ShadowOne333]

Hey there... on a separate note. There was an early tree graphic, the once you first proposed, for the hidden bush you had to burn to get to a hidden dungeon, etc. It was SO much better than the one you chose by committee. Any chances you could give us graphic as an optional patch? If it is not too much work, would love that. Thank you!

Which graphic in particular are you referring to?
Since there were many mockups done during that time

My goal was to make a cart of this hack once done testing the MMC5 version. And this was only the target because the MMC1 one failed in testing As far as I know there are no official 32kb CHR RAM boards for MMC1, so I'll check if I have any MMC1 donor boards which would be suitable for such an experiment.

If you please can, that'd be awesome!
But what did you mean by "the MMC1 failed in testing"?
How did you test that one?
Afaik, any MMC1 board should work.

I'm intrigued by what comes out of your tests.

[InAnotherCastle]

If you please can, that'd be awesome!
But what did you mean by "the MMC1 failed in testing"?
How did you test that one?
Afaik, any MMC1 board should work.

I'm intrigued by what comes out of your tests.

Well, more or less what was written about here is what I experienced. Ie. I tested with an Everdrive and concluded that the MMC1 version would not work on real hardware. Anyway. I should be able to do a quick test soon using an AX5904 repro board. Found a 256kbit SRAM salvaged from a SNES game. If it doesn't work with the pirate chip I'll look for a real MMC1 donor board.
October 03, 2021, 09:46:19 am - (Auto Merged - Double Posts are not allowed before 7 days.)First follow up:

The missing graphics etc. are working on real hardware using 256kbit SRAM, a clone MMC1 in a variant of the SNROM configuration.

I did a bunch of quick runs. There's always glitching on startup before the welcome screen animation starts, a crash upon exiting the first cave happened once, and saving doesn't always work. But this might be because of the wiring and/or socketed chips on the repro test board not making solid connections.

Anyway. The graphics glitching I experienced with the MMC1 v2.0 patch on an EverDrive were not present. I'll be testing more.

[Fiskbit]

Just to clarify, Everdrive is not real hardware; it emulates cartridge hardware (mappers, boards) just as an emulator does. The MMC1 version of the hack is relying on an unusual cartridge configuration, and emulators that don't supply the resources requested by the NES 2.0 header (32 KB of CHR-RAM, in this case) will cause the animation to break.

I've sent ShadowOne an updated version of the animation code that tests whether at least 32 KB of CHR-RAM is available. If not, it disables animation, allowing the game to still be playable.

[ShadowOne333]

Well, more or less what was written about here is what I experienced. Ie. I tested with an Everdrive and concluded that the MMC1 version would not work on real hardware. Anyway. I should be able to do a quick test soon using an AX5904 repro board. Found a 256kbit SRAM salvaged from a SNES game. If it doesn't work with the pirate chip I'll look for a real MMC1 donor board.
October 03, 2021, 09:46:19 am - (Auto Merged - Double Posts are not allowed before 7 days.)First follow up:

The missing graphics etc. are working on real hardware using 256kbit SRAM, a clone MMC1 in a variant of the SNROM configuration.

I did a bunch of quick runs. There's always glitching on startup before the welcome screen animation starts, a crash upon exiting the first cave happened once, and saving doesn't always work. But this might be because of the wiring and/or socketed chips on the repro test board not making solid connections.

Anyway. The graphics glitching I experienced with the MMC1 v2.0 patch on an EverDrive were not present. I'll be testing more.

That's really good news tbh.
This means that actually the hack does work in real hardware through a proper MMC1 board, just like Fiskbit mentions below, and that the issue many have been experiencing has to do with the Everdrive not handling 8+kB of CHR-RAM for games with iNES 2.0 headers.
This seems like a note-worthy issue report for the Everdrive developers, if anyone can redirect this issue to them, hopefully they can fix it with an update (if the flashcart can be updated that is).

Best of luck with checking the wiring, hopefully it's only just a fluke or something small that's causing the other issues you have experienced.

Just to clarify, Everdrive is not real hardware; it emulates cartridge hardware (mappers, boards) just as an emulator does. The MMC1 version of the hack is relying on an unusual cartridge configuration, and emulators that don't supply the resources requested by the NES 2.0 header (32 KB of CHR-RAM, in this case) will cause the animation to break.

I've sent ShadowOne an updated version of the animation code that tests whether at least 32 KB of CHR-RAM is available. If not, it disables animation, allowing the game to still be playable.

Thank you for your insight on the issue. It's really appreciated.
I'll work on the updated version you sent me and will let you know if something comes up


EDIT:

I forgot to mention, I started doing some debugging work on the Hearts number being saved on SRAM (so you don't always start with 3 hearts, but rather the game saves the amount you last had and starts you with those, and if <3, then it defaults to 3 hearts).

While I still don't have anything set in code, I did get some routines that seem to be related to reading and writing the Hearts to the save file. Take into consideration that this is merely documentation on routines that are already in the game, there's no new code in this.
This is what I have at the moment in terms of documentation for it:

Code: [Select]

//***********************************************************
// Save hearts to SRAM
//***********************************************************

// RAM $066F is the amount of hearts obtained and filled
// Hearts are separated in nibbles:
// 1st: 1111 -> F = 16 hearts / Max amount of hearts (0 = 1 heart)
// 2nd: 1111 -> F = Fill all 16 hearts (0 = 1 heart filled)

// Address $6032 is where the game stores the current amount of hearts obtained in SRAM for Slot 1
// $6032 - Slot 1
// $605A - Slot 2
// $6082 - Slot 3

// FREE RANGES:
// Bank 2: 8F6F-900F, 9BE7-9D0F, A840-A86F, A8EA-A90F
// Bank 5: 145DA-1460F, 153EC-1540F, 15BE8-15F0F (OW columns, ruppe code begin at 15F10 and ends at 15FAC), 16CB0-16D0F

bank 2;
// Routine in charge of loading the hearts at File start
org $A606 // 0x0A616
lda.b ($00),y // Loads hearts value from SRAM ($6032-5A-82)
sta.w $0657,y // Stores table from SRAM (gets to $066F)
dey

// ???
org $A6C6 // 0x0A6D6
lda.w $0657,y // Grabs the value from $066F, RAM Location
sta.b ($C0),y // Stores it from $68B0?, SRAM Location

// ???
org $A6F3 // 0x0A703
lda.w $066F // Load RAM $066F (Hearts)
and.b #$F0 // Compare to value #$F0
pha // Push to stack
lsr // Left shift
lsr
lsr
lsr
sta.b $0A // Stores in RAM $0A
pla
ora.b $0A // Or $0A
sta.w $066F // Store in RAM $066F (Hearts)
lda.b #$FF // Load value #$FF
sta.w $0670 // Store $FF in "Partial hearts" address

// ???
org $A819 // 0x0A829
org $A827 // 0x0A837
lda.w $066F,y // Load table from RAM $066F
sta.b ($C0),y // Stores it from $0650?, SRAM Location

bank 5;
// Routine in charge of saving hearts on manual save or game over
org $8B6D // 0x14B7D
lda.w $066F // Load Hearts address
and.b $F0 // Compare with #$F0
ora.b #$02 // Set default value to #$02?
sta.w $066F // Store in address $066F (Hearts)
lda.b #$FF // Load value #$FF
sta.w $0670 // Store $FF in "Partial hearts" address
// Jump to $EBA3 (close routine?)


[InAnotherCastle]

That's really good news tbh.
This means that actually the hack does work in real hardware through a proper MMC1 board, just like Fiskbit mentions below, and that the issue many have been experiencing has to do with the Everdrive not handling 8+kB of CHR-RAM for games with iNES 2.0 headers.
This seems like a note-worthy issue report for the Everdrive developers, if anyone can redirect this issue to them, hopefully they can fix it with an update (if the flashcart can be updated that is).

Best of luck with checking the wiring, hopefully it's only just a fluke or something small that's causing the other issues you have experienced.

Indeed.

Don't mind my comments on the glitches. It's not the first time I've seen weird behaviour using the AX5904 MMC1 to test games with CHR RAM as well as PRG RAM.

So just to make clear: using 256kbit CHR RAM as proposed here does fix the issues.

Anyway, I'll check the wiring, prepare a real MMC1 donor, and perhaps mention this at krikkz' forum. But as also mentioned here, the EverDrive seemingly targets known use of mappers, so nonstandard configurations may not count as a bug :-)

[ShadowOne333]

Thanks to Fiskbit's help and feedback, the Animation code (including Automap and Visible Secrets) have been modified so that emulators and flashcarts that do not have compatibility or support for games that use MMC1 with CHR-RAM banks above 8kB will disable the animation in-game.

That way people can still enjoy Zelda 1 Redux MMC1 without graphical corruptions.
This is still a beta patch, so consider it as such and do mention if there are any bugs.

For emulators and flashcarts (if there are any) that DO support 32kB of CHR-RAM, the game should have its animation working properly, as it was before.

I tested this in both FCEUX (both with Animation and Animation Disabled), Mesen and in Nestopia, and it seems to work from the few minutes I tested it in all of them.

Here's the MMC1 beta patch:
https://github.com/ShadowOne333/The-Legend-of-Zelda-Redux/raw/master/MMC1/patches/Zelda1_Redux.ips

[netux]

The last patch seems to work correctly for MMC1 without animation in Nestopia. I also tried the original HUD patch and within the Dungeons it also restores the LEVEL-? text on the HUD... is that the expected behavior?

[ShadowOne333]

The last patch seems to work correctly for MMC1 without animation in Nestopia. I also tried the original HUD patch and within the Dungeons it also restores the LEVEL-? text on the HUD... is that the expected behavior?

Yeah that's normal.
Original HUD should also restore the LEVEL text inside dungeons.

[Cyneprepou4uk]

Besides that saving hearth amount and copy/erase saves, is there anything else you would like to do? Or do you think that your hack is basically perfect the way it is now?

[ShadowOne333]

Besides that saving hearth amount and copy/erase saves, is there anything else you would like to do? Or do you think that your hack is basically perfect the way it is now?

From all the things I could consider improving upon that I could think of or that bothered me from the original, I think Redux covers them all.
Basically, both saving hearts and the Copy/Erase stuff are the only things I can think of to consider the hack itself in a state I'm perfectly fine with.

That doesn't mean I'll close myself to suggestions though.

[lexluthermiester]

Thanks to Fiskbit's help and feedback, the Animation code (including Automap and Visible Secrets) have been modified so that emulators and flashcarts that do not have compatibility or support for games that use MMC1 with CHR-RAM banks above 8kB will disable the animation in-game.

That way people can still enjoy Zelda 1 Redux MMC1 without graphical corruptions.
This is still a beta patch, so consider it as such and do mention if there are any bugs.

For emulators and flashcarts (if there are any) that DO support 32kB of CHR-RAM, the game should have its animation working properly, as it was before.

I tested this in both FCEUX (both with Animation and Animation Disabled), Mesen and in Nestopia, and it seems to work from the few minutes I tested it in all of them.

Here's the MMC1 beta patch:
https://github.com/ShadowOne333/The-Legend-of-Zelda-Redux/raw/master/MMC1/patches/Zelda1_Redux.ips

Have tested and can confirm that everything seems to be as it should. Very nice!

[ropeFullOfHope]

God I wish this ROM hack would work with Zelda Randomizer.
But I bet this would require way too much work to make them compatible.

[dobole]

Ive had some issues playing with both the MMC1 and MMC5 versions, and using the FCEUX and Mesen emulators.
First, the title screen is very pink, and some sprites are chopped off. More importantly, the game freezes if I enter any cave.
I havent seen anyone else talk about these issues, so some help would be appreciated.

[lexluthermiester]

Ive had some issues playing with both the MMC1 and MMC5 versions, and using the FCEUX and Mesen emulators.
First, the title screen is very pink, and some sprites are chopped off. More importantly, the game freezes if I enter any cave.
I havent seen anyone else talk about these issues, so some help would be appreciated.

That seems like a ROM issue. What ROM are you using?

[ShadowOne333]

Hey guys!
Sorry for the absence, I had some IRL stuff to deal with, and it really took some time.

In the meantime, RH user, Minucce, kindly helped out with one of the very last features yet to be implemented into Zelda 1 Redux... A proper Copy/Erase save file system!

• The system behaves just like the one in ALttP and other Zelda titles, in which you move the cursor up or down with the D-Pad. You can move the cursor to an empty save slot to immediately get prompt with the Name Register screen.
• The Copy system functions like other Zelda titles as well, where you select the file you want to copy, and to which slot you want to move it to. You can overwrite already made save slots, like other Zelda titles do too, so take that into consideration!
• The Erase system is still similar to Elimination Mode, but Minucce went the extra mile and added some little quirks here and there to make it an even more polished feature.

With that said, I want to reach out to ask for help testing the new feature with the following aspects:

• Make a copy of any random save file you have available into a new slot
• Once copied, test out the number of hearts obtained, rupees, arrows, bombs, keys, Automap tiles uncovered, and quest items/objects obtained (and triforce parts). Make sure the copied save file has the exact same amount for all of those as the original
• In the overworld, test out that the exact caves that you have bombed, Heart Containers obtained, and NPC quests match that of the original save
• In dungeons, test out the exact number of doors opened with keys, compasses, maps, bosses defeated and map tiles uncovered. Make sure they match the original save as well

I did give some of these points a rather quick test of about 15 mins in several places (overworld, amount of items, Automap, some caves, etc.) and it all seemed fine. But I want to ask you guys to test it out thoroughly if possible.

Here are the beta patches:
MMC1: https://github.com/ShadowOne333/The-Legend-of-Zelda-Redux/tree/master/MMC1/patches
MMC5: https://github.com/ShadowOne333/The-Legend-of-Zelda-Redux/tree/master/MMC5/patches

I won't update the RH.net pages until we are clear it all works properly.

Next and last, would be for the game to save the hearts amount you have into SRAM, so if you have more than 3, that amount of hearts are saved/loaded when continuing, and if you have 3 or less than 3, they default to 3 when continuing.

Be sure to address any kind of inconsistency you guys might find!
And HUGE thanks to Minucce for this, he did an incredible work with this File System feature!

[JCreazy]

Hey, I just found this hack and am playing it on MiSTer FPGA.  If I try to play the MMC5 version, everything looks fine until I save.  Once the game starts over, a lot of the images start flashing back and forth between normal and some other image.  The MMC1 doesn't do this.  I assume the problem is caused by the FPGA but I thought I would mention it in case anyone wanted to look into it.  I honestly don't know what the differences are suppose to be between the two.