[bogaabogaa]

Thanks I will have a look. I remember someone liked to have full health refill when the gamesave is loaded.

I made some code for it. This could be a new small patch:

Code: [Select]

bank 2;
org $a635 //PRG $a635
jmp RefillHealth


org $a830
RefillHealth:
lda $66f //Make halth container equal to current health
and #$f0
sta $66f
lsr
lsr
lsr
lsr
adc $66f
sta $66f

jmp $eba1
Thanks for all the info so far.

Update:
The glitch you are having is from a miss edit in the MMC5.asm
You made it accidently the wrong opcode. Still not sure why you think it is a good idea to include this as the opcode in this assembler is always clear form the context you put on it. It will make it more likely you do mistakes like this. That is the reason I never use them. I could see me use them when the assembler is bugged and could not choose pick the right opcode for some reason.


Update: Also the glitch happened scrolling along the vertical line. Depending how you look at it you can confuse this one. If you change the position of this line you get left or right.

[ShadowOne333]

Oooof you're absolutely right. I overlooked that typo.
I always tend to test byte per byte that the opcode is the correct one after compiling new code, and I forgot to check with this new one, was kinda in a hurry.

I think the reason why I started using the .b/.w specifications was because I had an issue some months ago with a specific opcode being output as $XXXX instead of $XX like I needed it to by leaving it as default, so that's why I started specifying .b/.w/.l to each opcode from there on, to avoid such a thing.
I know xkas does output what it thinks is the correct opcode given the code definition.
Well, there's also my OCD that might be at play with that as well

I'll see about converting the whole code to not have the .b/.w.
Does Asar also support .b/.w/.l? Or does it not?
I ask so I know if it would also make it somewhat compatible with compilation with Asar by doing minimal modifications to the code, if one wants to compile with Asar instead of Xkas.


In any case, thanks for pointing the issue out.
I already fixed it on my end, and the scrolling is now working properly.

I will be making a CHR.bin for Link's Awakening GFX today, and also editing the animations to match the new GFX for the Redux and LA graphics (the ones you made will be kept as is).

Oh and thanks for that code for refilling hearts!
I'll for sure adding it

Thanks again for all the help, Bogaa!


Finished the animations today for Redux and LA's graphics.
I also retouched a bit of the original CHR Bogaa made, and fixed the waterfall animation so it loops properly in a seemless manner.

Here's how it looks right now in-game:

[bogaabogaa]

I think the reason why I started using the .b/.w specifications was because I had an issue some months ago with a specific opcode being output as $XXXX instead of $XX like I needed it to by leaving it as default, so that's why I started specifying .b/.w/.l to each opcode from there on, to avoid such a thing.
I know xkas does output what it thinks is the correct opcode given the code definition.

I would be interested to see the file that made it fail. I could imagine the architecture was not defined. But I might also be wrong on this and the assembler does have a bug. I don't think the NES has any /.l opcode.

Does Asar also support .b/.w/.l? Or does it not?
Yes it does support this and there it make sense since the CPU can run in compatible mode. I mean the REP opcode that can make some registers run in 8 or 16 bit mode. If you don't know the status of this flag the assembler has no way to tell what opcode to use.

Asar does support SNES/SPC700 and FX code. It does not support any NMOS/6502 architecture. Xkas did not support this till the fork for xkas plus v14+1 did add the architecture. Other assemblers for the NES I know off don't have injection tools. But there are forks for some of them that added this functionality. Like Sonder for Loopy's ASM6. Or NaOH did fork and added macros that allow for injection patching.
Currently SpaderDave is working on a assembler that really blow my socks off. That one requires python but he made a Super C randomizer with a single .asm file.
If you are interested you can check it out here. https://cdn.discordapp.com/attachments/596475948325666833/786186797998276628/Super_C_Randomizer_2020.12.09.zip

And sorry for sidetracking..
I would not worry about other assemblers. Probably best to finish this project with the current assembler.

Great to hear you make progress with the graphics. I really just copy pasted PPU pages to CHR banks. I did make the animation as a proof of concept.
Still need to work on the automap stuff. Haven't found time so far.

[ifightdragons]

This isn't very important, but might be a very neat QOL addition.

There's a secret room in which you're given a choice of 3 paths. They're basically teleports to different areas of the map:
https://legendsoflocalization.com/media/the-legend-of-zelda/first-quest/take_any_road_comp.png

Maybe adding a small text hint below each staircase as to where they lead, could be quite useful?
I don't remember where they lead off the top of my head. But if one of them leads to the graveyard, it could simply say; Graveyard (or Graveyard Path).

[ShadowOne333]

I would be interested to see the file that made it fail. I could imagine the architecture was not defined. But I might also be wrong on this and the assembler does have a bug. I don't think the NES has any /.l opcode.

I might be misremembering exactly what opcode it was, but I know it was a problem of 8bit/16bit in an opcode.
It was months ago, so I don't even remember what file or code had that issue.
All I know is that it was either a $00 being changed to $0000, or $0000 being changed to $00 (I think it was the former).

I will be more careful when defining the bit length from now on to avoid such issues.

Great to hear you make progress with the graphics. I really just copy pasted PPU pages to CHR banks. I did make the animation as a proof of concept.
Still need to work on the automap stuff. Haven't found time so far.

Ah it's okay, don't worry, I know you made the animation as a PoC. I am more than glad to do all the graphic stuff so it plays nicely.
And don't worry about Automap, take your time with it, there's no hurry at all.
You've already done way too much for this project, and I'm really thankful for that.

This isn't very important, but might be a very neat QOL addition.

There's a secret room in which you're given a choice of 3 paths. They're basically teleports to different areas of the map:
https://legendsoflocalization.com/media/the-legend-of-zelda/first-quest/take_any_road_comp.png

Maybe adding a small text hint below each staircase as to where they lead, could be quite useful?
I don't remember where they lead off the top of my head. But if one of them leads to the graveyard, it could simply say; Graveyard (or Graveyard Path).

In theory, it does sound good.
However, there's one big issue with that.

There's like 3 or 4 caves that let you choose a path for warping to another place.
And the issue? They all use the same text.
It could probably be done by assigning another text for the other 3-4 caves, but all of the text and pointers are already being used in the game, so I have no free text to use for them.

So as you can see, it's not really that feasible to make a specific text for one, when all 3-4 share the same text, and the staircases themselves won't correspond for all 3-4 caves with staircases, as they change for each one.

[ifightdragons]

I thought it might be a tall order. Glad you liked the idea, still.
Can't wait to finally see the final version of this. Big thanks to you and everyone helping out.

[iridium_ionizer]

There's like 3 or 4 caves that let you choose a path for warping to another place.
And the issue? They all use the same text.
It could probably be done by assigning another text for the other 3-4 caves, but all of the text and pointers are already being used in the game, so I have no free text to use for them.

One way to design your way around that limitation would be designate where the three paths lead to in the overworld screen above the shortcut cave.

Numbers 1, 2, 3                            OR    rock, forest, water                   OR    statue, grave, forest

Of course this assumes that you want to redesign the overworld, and it also assumes that you are willing to let accessibility / convienience dictate the design of 4 overworld screens.

[ShadowOne333]

One way to design your way around that limitation would be designate where the three paths lead to in the overworld screen above the shortcut cave.

Numbers 1, 2, 3                            OR    rock, forest, water                   OR    statue, grave, forest

Of course this assumes that you want to redesign the overworld, and it also assumes that you are willing to let accessibility / convienience dictate the design of 4 overworld screens.

Sounds like a good workaround, but Zelda's limitations come again to screw things over.
You are limited to either two palettes for a particular screen, and those are specifically either one color for the outer or the perimeter of the screen, and another for the inner portion of it.

Take some of the Fairy ponds in Lost Woods as an example.
The perimeter is brown having brown/orange trees, while the color in the section where you can walk around has green trees.
That's how the screens work in Zelda 1. You can't have much variety in each screen outside of 2 colors, one for perimeter and one for inside, or one solid color for the whole screen.
The colors You can use are red, green, orange and grey, and only two of those can be used in one screen. Orange, green and gray are used in Zelda 1, while red is never used anywhere in the overworld in vanilla Zelda, only romhacks use it.

There's also me not wanting to change the design of the overworld, but if I were to make it into an optional patch for those that want it, the limitation just drops that option dead, sadly.
Though, I could probably just make them have all the same colors, but I'll leave that for others to decide.

[iridium_ionizer]

Sounds like a good workaround, but Zelda's limitations come again to screw things over.
You are limited to either two palettes for a particular screen, and those are specifically either one color for the outer or the perimeter of the screen, and another for the inner portion of it.

Yeah, I know. I was just trying to get full resolution screengrabs from the ZeldaTech editor in a hurry.

[ShadowOne333]

Yeah, I know. I was just trying to get full resolution screengrabs from the ZeldaTech editor in a hurry.

Ah I see.
It's okay though
I'll see what I can do about that in the upcoming days.


Out of that, I found a bug related to the new column definitions hack I made some days ago.
It's a really small thing, but it kinda bothered me enough to do something about it lol

I noticed that when you got out of Dungeons or Caves with special statues for entrances, that if you went up as soon as you exit the dungeon/cave, you would hit the top of the other tile, and if you tried to go back, Link would go back to the Dungeon/cave he just exited from. This was caused because of the redesigned cave entrances to have an arc, so I changed the entrances tiles that shared that tile to use another ($0D instead of the original's $0C). This caused the collision of the tile to be broken and all walk-through ($0D doesn't have collision in all its 16x16 pixels), while $0C does have collision in the upper 8 pixels of the 16x16 tile.

Another side-effect of this, is that in the passageway screens inside Dungeons, you could kind of walk to the side of the stairs in the air for a bit due to the tile not having proper collision.

I ended up repurposing tile $04 from the column definitions.
I noticed this particular tile ended up not being used in the final release of Zelda 1, so I changed its tile definitions to be similar to the original $0C to use for special dungeon/cave entrances, and I changed $0C to be the new arched cave entrances.

For reference, tile $04 is the one after the brick tile in this image:



While doing this, I also noticed tiles $38-$3F all show garbled data, and that's because the 16x16 tile definition table ends at tile $37, and the following data is the one for the individual 8x8 tile definitions. The garbled $38-$3F tiles that show up as glitched is because that data overflows into the individual 8x8 tile definitions.
Repointing the table would fix this and allow for 8 more 16x16 tiles to be used for the overworld, but I have no use for this for Redux, so I left it as is.

I did add comments and code inside "overworld_screens.asm" to properly repoint it if others do require this feature in the future.

[illuminerdi]

This is an awesome patch, thanks to everyone for their hard work on it.

Is there any possibility for an optional patch with "less visible" (but still different) clues?

I feel like the cave wall cracks and the "withered" trees are still pretty easy to spot. I even turned on blargg's NTSC filter and I could still see them pretty clearly - especially the cave wall cracks, I feel like those are practically smacking the player in the face. I'm sure some people like the more visible clues, so I'm not lobbying to get rid of those, just looking for a more challenging option that uses some of the previously-posted suggestions for those of us looking for a challenge but who don't feel like having to randomly bomb walls and burn trees.

That was such a pain when I was a kid - I remember actually sticking my face right up next to the screen trying to see if there WAS some kind of very slight pixel difference on those tiles so that I could learn to "spot" them, so even 7 year old me felt like there *should* be a difference...

[ShadowOne333]

This is an awesome patch, thanks to everyone for their hard work on it.

Is there any possibility for an optional patch with "less visible" (but still different) clues?

I feel like the cave wall cracks and the "withered" trees are still pretty easy to spot. I even turned on blargg's NTSC filter and I could still see them pretty clearly - especially the cave wall cracks, I feel like those are practically smacking the player in the face. I'm sure some people like the more visible clues, so I'm not lobbying to get rid of those, just looking for a more challenging option that uses some of the previously-posted suggestions for those of us looking for a challenge but who don't feel like having to randomly bomb walls and burn trees.

That was such a pain when I was a kid - I remember actually sticking my face right up next to the screen trying to see if there WAS some kind of very slight pixel difference on those tiles so that I could learn to "spot" them, so even 7 year old me felt like there *should* be a difference...

It can be done quite easily by opening the patched ROM up with YY-CHR and changing the Burned Tree/Cracked walls graphics to what you see fit.
Or better yet, simply download the source, go to "code/gfx/" and open up the "OverworldAssets.bin" file in YY-CHR for editing. Then, once you are finished with the changes, put your base ROM in the "rom/" folder, and double click on the "make.bat" file (if on Windows). That should compile your ROM with the graphical changes.


Aside from that, I decided to post the current work that's done for the MMC5 conversion.
You can download it here:
https://www.dropbox.com/s/61aztzpemsprl92/MMC5_Redux.zip?dl=0

It should have my dumb sta.b/sta.w mistake fixed.
Just remember that the Automap's minimap isn't there yet, so you won't have an overworld map.

For those that want to test, do it with this version. And do let us know if there's any bugs of any sort.

[bogaabogaa]

I been working on the Automap file. I changed it to use name table so I had to restructure a lot of things. The file works with MMC1 and MMC5. I also added that the map will disappear in caves.



- Shadow removed the MAP from CHR instead the name table stuff. This need to be added to the CHR.
- The move_maps.asm did have the nametable and did overwrite it. This is added in the automap.asm So you need just to patch the pointer in the movemaps file.
- There been also change to the MMC5 Patch. Mainly to make space in the last bank. I also disabled settings I think are not necessary.

This are all the changes I can recall you need to change on your side @shadow. A other good thing I added in the new Automap file that I copy stuff to different RAM pages. The coded is not needed. I also put some ascii text so people get a idea where they can put code when they view it in the debugger.
I think most caves will remove the map to be viewed. But not for the cave where you access different areas.



This could be a other project to hack something in that room that will tell you where it goes. There could be some code added to remove the map. All it needs is a flag. Writing $01 to CPU $7f02 will draw the map. Making it $ff will make it blank.

Still early stage so I am glad when people find more bugs and report them.

- I did not test with the optional patches!
- In the patch folder is a Redux.ips with MMC5 added and all the normal patches applied. If anyone feels like testing early stuff 

Patch Download
https://www.dropbox.com/s/8g8d2d7n80o3tg9/The-Legend-of-Zelda-Redux-PRG0.zip?dl=0

Update:
- I think it would be cool to have some extra columns used in a optional patch. I do think people might use this as a base for a hack so it is nice to have things working properly and may be provide a example.

- The teleport room is probably not a easy change but a good challenge. If you code it in you could put a sprite over his head that changes accordingly when you get near the stairs. Sure it is a lot of work to do.

Update2:
- I tested the optional patch that rearranges bosses. That one would need a different CHR arrangement. Or CHR Swap Fixing.

Update3:
This looks bad too. There should be a flag to stop the animation when needed. And then have something to stop it for that room.


Not really happy with the current tile arrangement. Would be cool to have water in one in two rows. Then have the next rows for something else. Like this you could have animations just turned on when a special event happen. Or have a second one with a different speed.
Sure might be more a thing for a actual hack..

Update4:
- Looking at it I was thinking to take the Bank animation out of the MMC5.asm and make a MMC5Features.asm in the gameplay folder. Do you feel comfortable to do some programing around the MMC5? Here some ideas. The space after CPU $700-800 seems empty. So you could allocate values to start and stop animations there. May be have a value for the animation speed. I would do that for all 4 quarters. And may be have a extra value what you like to put in the empty sprite page in RAM.
Later on there might be ideas for other features of the MMC5 so it would be good to have a extra file beside the base conversion. I could imagen that this one might get big rather quick. The SRAM think I made could go in there too.

[ShadowOne333]

I been working on the Automap file. I changed it to use name table so I had to restructure a lot of things. The file works with MMC1 and MMC5. I also added that the map will disappear in caves.



- Shadow removed the MAP from CHR instead the name table stuff. This need to be added to the CHR.
- The move_maps.asm did have the nametable and did overwrite it. This is added in the automap.asm. So you need just to patch the pointer in the movemaps file.
- There been also changes to the MMC5 Patch. Mainly to make space in the last bank. I also disabled settings I think are not necessary.

This are all the changes I can recall you need to change on your side @shadow. A other good thing I added in the new Automap file that I copy stuff to different RAM pages. The coded is not needed. I also put some ascii text so people get a idea where they can put code when they view it in the debugger.
I think most caves will remove the map to be viewed. But not for the cave where you access different areas.



This could be a other project to hack something in that room that will tell you where it goes. There could be some code added to remove the map. All it needs is a flag. Writing $01 to CPU $7f02 will draw the map. Making it $ff will make it blank.

Still early stage so I am glad when people find more bugs and report them.

- I did not test with the optional patches!
- In the patch folder is a Redux.ips with MMC5 added and all the normal patches applied. If anyone feels like testing early stuff 

https://www.dropbox.com/s/8g8d2d7n80o3tg9/The-Legend-of-Zelda-Redux-PRG0.zip?dl=0

Update:
- I think it would be cool to have some extra columns used in a optional patch. I do think people might use this as a base for a hack so it is nice to have things working properly and may be provide a example.

- The teleport room is probably not a easy change but a good challenge. If you code it in you could put a sprite over his head that changes accordingly when you get near the stairs. Sure it is a lot of work to do.

Update2:
- I tested the optional patch that rearranges bosses. That one would need a different CHR arrangement. Or CHR Swap Fixing.

Update3:
This looks bad too. There should be a flag to stop the animation when needed. And then have something to stop it for that room.


Not really happy with the current tile arrangement. Would be cool to have water in one in two rows. Then have the next rows for something else. Like this you could have animations just turned on when a special event happen. Or have a second one with a different speed.
Sure might be more a thing for a actual hack..

Fantastic! I see you reworked the entirety of Automap, and it's quite amazing!
I'll be testing this during the week and let you know what I find. Right now, the only thing I noticed is that the Automap draws 8x8 tiles instead of the minitiles (4x4) from the original Automap, but I assume this is a caveat from the MMC5 conversion and the bank swapping.

Now, to address your points in the updates:

• Automap Tiles in CHR: I noticed you mentioned including the Automap tiles right into the CHR binaries. While this does work properly, I think it'd be better to specify the addresses where to include the Automap tiles specifically. I added the following at the end of the new Automap code you made:

Code: [Select]

// This is needed for Original MMC1
bank 2;
org $8A7F
incbin code/gameplay/automap_tiles.bin

// Automap tiles for MMC5
bank 8; org $22B00
incbin code/gameplay/automap_tiles.bin
bank 10; org $29300
incbin code/gameplay/automap_tiles.bin
org $2A300
incbin code/gameplay/automap_tiles.bin
org $2B300
incbin code/gameplay/automap_tiles.bin
bank 11; org $2C300
incbin code/gameplay/automap_tiles.bin
By doing it this way, I found that this makes the Automap tiles to be included, no matter what CHR the user selects, be it original NES GFX, new Redux GFX or LA's GFX. Small thing, but saves up time doing all the copy-pasting for all the graphics versions and options.

• Update 1a: I think it would be cool to have some extra columns used in a optional patch. I do think people might use this as a base for a hack so it is nice to have things working properly and may be provide a example.
  R- Indeed, this would be a good optional patch to add. I didn't think of that. I'll see what I can do to make the original columns layout an optional patch.
  
• Update 1b: The teleport room is probably not a easy change but a good challenge. If you code it in you could put a sprite over his head that changes accordingly when you get near the stairs. Sure it is a lot of work to do.
  R- A way to specify where the staircases warp you to could be troublesome to accomplish for sure. Though to be honest, I think it'd be way too much work for such a minor thing
  
• Update 2: I tested the optional patch that rearranges bosses. That one would need a different CHR arrangement. Or CHR Swap Fixing.
  R- Oh you might be right. I completely forgot that one changes pointers to the Dungeon graphics. Although, the pointers there aren't modified by the MMC5 stuff, or are they?
  This is the code I believe might need changing for that from the Rearranged Bosses patch:

Code: [Select]

// Dungeons 1-9 1st Quest
bank 3;
org $8006 // 0x0C016
// Graphics pointer for Dungeon 3
dw $9A9B // Dungeon 3 GFX, Originally $987B (D8 7B)
org $8022 // 0x0C032
// Graphics pointer for Dungeon 7
dw $A7DB // Dungeon 7 GFX, Originally $9FDB (DF DB)
I'll look into it to see how it could be fixed.

• Update 3: This looks bad too. There should be a flag to stop the animation when needed. And then have something to stop it for that room.
  R- I did notice that in one of my tests, but forgot to mention it. Whenever you use the Flute into one of the ponds that get drained, the black dots still keep moving after being drained.
  Perhaps hijacking the routine that makes the ponds be drained could help in some way, though I'm unsure how exactly. Maybe make the animation play frames 2 & 4 for that particular case instead of always 1-2-3-4 could help, as frames 2 & 4 are the same graphics. The routine for playing the Flute seems to be around 0x1EF81 in ROM, or $1EF71 in PRG (NES). I'll see what else I can come up with for this particular case.

[bogaabogaa]

In this patch I Fixed the most game breaking Bugs.
**deleted** out of date

Also added Different Text to the path guy.


The animation stuff mentioned above is not done.. Still glad for feedback on bugs.
 
I did share code in my old post. Since there are some dependency's for many patches by now. This is true without MMC5 too. There should be a group of redux patches that need to be patched.

Then you can list the once where it is not a issue to swap in and out. Else it can be confusing for the user why things just break. The main reason why this exist are the expanded tables. For example I moved the Hud preset layout so I could expand it. By bow many patches make use of that or need the location where the old table was and find garbage..

MMC5 will not be dependent for the people that worry. A goal is to make as many patches work independent as possible.

[ifightdragons]

In this patch I Fixed the most game breaking Bugs.
https://www.dropbox.com/s/5zdbm0gtdro9e7h/Zelda1_Redux.ips?dl=0

Also added Different Text to the path guy.


The animation stuff mentioned above is not done.. Still glad for feedback on bugs.
 
I did share code in my old post. Since there are some dependency's for many patches by now. This is true without MMC5 too. There should be a group of redux patches that need to be patched.

Then you can list the once where it is not a issue to swap in and out. Else it can be confusing for the user why things just break. The main reason why this exist are the expanded tables. For example I moved the Hud preset layout so I could expand it. By bow many patches make use of that or need the location where the old table was and find garbage..

MMC5 will not be dependent for the people that worry. A goal is to make as many patches work independent as possible.

I believe a standing ovation is in order. Merry Yuletide.

[bogaabogaa]

Marry Xmas to everyone. Also I been not coding extra sprites to indicate and update where you go so it was not that difficult. The most difficult part to handle about this project is the amount of patches and the interaction. Possible bugs through some changes.

This video might be useful if anyone likes to program a charge attack for the sword. It is done very well and might give many a deeper look what is going on when hacking content.

https://youtu.be/FBk-QkzMeIk

Thanks everyone for the support and interests of this project.

[The Count]

Amazing!

I especially love the multiple staircase cave actually telling you where you are headed.

There are so many modifications done to this project that just blow my mind.

Thumbs way up to everyone and their dedication! 

[ShadowOne333]

In this patch I Fixed the most game breaking Bugs.
https://www.dropbox.com/s/5zdbm0gtdro9e7h/Zelda1_Redux.ips?dl=0

Also added Different Text to the path guy.


The animation stuff mentioned above is not done.. Still glad for feedback on bugs.
 
I did share code in my old post. Since there are some dependency's for many patches by now. This is true without MMC5 too. There should be a group of redux patches that need to be patched.

Then you can list the once where it is not a issue to swap in and out. Else it can be confusing for the user why things just break. The main reason why this exist are the expanded tables. For example I moved the Hud preset layout so I could expand it. By bow many patches make use of that or need the location where the old table was and find garbage..

MMC5 will not be dependent for the people that worry. A goal is to make as many patches work independent as possible.

What can I say?
Just wonders all around, thanks again for this, bogaa!

I reworked the text a little bit, and this is what I have right now:


I might change the "WEST/EAST" instances so it's just "W/E" to save text space, but I'm up for suggestions. Just remember that we don't have parenthesis in the font.

With that said, I wish everyone a very good Christmas' Eve, and hope you guys enjoy the holiday with your family and/or beloved ones, with proper precautions given the current state of affairs.

Best of wishes to everyone!

[Trax]

To be honest, I think this 1-2-3 text is somewhat lame. It really feels shoehorned. Also, do you have different texts for each screen? Because shortcuts don't have the same order for staircases, depending on what screen you come from. Having little icons for each staircase would be better, in my opinion, but I understand that it would likely mean 3 more screens, new columns and some code hacking to select the correct screen accordingly.

Or, use "left", "center" and "right" to designate the destinations, instead of 1-2-3. Also, I would call the west shortcut screen "graveyard", and the bottom one "ocean" or "beach".