[ShadowOne333]

Well, don't know what it was, but it's fixed. However, I have found a minor glitch in Q1LVL6 with the map, a few rooms don't show as visited when they have been. See screenshot.
https://www.dropbox.com/s/nrny3zmm7wkjoki/LOZ1-Redux-LAGFX%5B20-11-8%5D_001.png?dl=0

That's caused by the "move_maps.asm" hack I did (which flips the Hearts and Map in the HUD).
Without it, the map shows up properly.
I'll see what could be causing this issue with that map precisely. I have tested 1st Quest maps 1-7 so far and none of them except 6 present this issue, I will test the rest and 2nd Quest today.

Also, in a coincidental manner while testing the Dungeon 6 map issue, I bumped into yet another bug which no one has mentioned yet.



That issue seems to be a carried bug from Automap by Snarflam.
I tested it on a clean ROM with only Automap applied over it, and indeed, it's an issue with Automap alone, not Redux. The issue happens whenever Link goes into any dungeon stairs, and when you get out, a particular colour in Palette #4 of the background palettes isn't properly being restored to its normal value when doing the fade-out effect when transitioning between stairs and normal dungeon play.

I did some testing yesterday, and it seems that this issue is caused because Automap tends to store $00 at RAM address $6C00 when the fade out occurs.
By intuition, I think this is the problematic code that is causing that particular issue from Automap:
https://github.com/ShadowOne333/The-Legend-of-Zelda-Redux/blob/master/code/gameplay/automap.asm#L376-L392

You can see that particular routine loading address $10 (RAM address for world location, overworld or dungeon), and it checks it against $00 (Overworld value). If it's not $00 (01 = Dungeon I believe), then it branches to the LDA #$00 -> STA $6C00. I believe this is the exact part that screws up the palette value when fading inside dungeons. Still, though, I have no clue as to how to fix this issue. If someone is willing to give a helping hand, I'll be deeply grateful. I will try fixing it on my end as well.

I haven't debugged the issue with the Dungeon 6 map properly yet, but at least I know it has something to do with my move_maps.asm code, so I know where to start looking. I'll test the rest of the dungeon maps just to be sure the others don't have the same issue.

[gzip]

Here's how I addressed the automap palette bug:
http://www.romhacking.net/forum/index.php?topic=30626.msg394459#msg394459

[ShadowOne333]

Here's how I addressed the automap palette bug:
http://www.romhacking.net/forum/index.php?topic=30626.msg394459#msg394459

Oh I didn't know you tackled this issue already. You NOP (x3) the STA $6C00 at 0x19D99, correct?
I added the 3 NOPs in place of that STA, and sadly it's still not working for me.
As soon as I start a game and Pause to check the Subscreen, the Subscreen starts flickering like crazy.
If I manually add $00 to $6C00, then it stops doing that.

I tried with standalone Automap, and it seems to work there, but for some reason that solution doesn't seem to be working with Redux :/
I also tried disabling all the other ASM files, except Automap, and that seems to work, but as soon as I active either the Arrows/Rupees ASM files, the flickering returns.

I will see what can be the issue here.


EDIT:
I went ahead and took a peek at the Automap source released by Snarfblam some years ago, and I rewrote the entirety of the automap.asm file on my end to match his notes and definitions. I just did this to cleanup the file, though, that wasn't done to fix the issue or anthing.

But aside from the cleanup, I think I found a possible solution for this issue, but still haven't pinpointed how to properly implement it, as I need to find 6 free bytes near $6C00 in RAM.
The RAM Address that's at fault here seems to be $6C00.
I did some slight research, and apparently the section before and after $6C00 gets loaded with Overworld/Dungeon data  found at bank 6. From the slight section of data around $6C00, I think I found a section that doesn't seem to be used by either Overworld nor Dungeon data, which I could repurpose for the Automap Tile Flag ($6C00).

From my quick tests between dungeons, it seems the range from $6BE1-$6BF9 goes unused in vanilla Zelda 1, but this range seems to be used by some PPU transfers with Automap itself, so I need to find 6 bytes of unused RAM around that section to be able to change Automap's code (and the STA $6C00) to work properly, without it clashing with either Overworld data or Dungeon data.


EDIT #2:
I went for RAM Address $6CB4 for the Tile Flag (and its 6 bytes).
I noticed $6CB4 goes right after the end of a routine in the Rupee ASM, around $0D bytes of dummy $FF bytes, so that seems to be a good place to put it at the moment. Will check if something borks or not with that later on.

I also found the culprit of the issue with the Subscreen map for Level 6 not showing up.
Seems to be this code precisely that makes it screw up:

Code: [Select]

org $992D // 0x1993D
db $10 // Originally $F1 ($10)
Such a small change, and it seems to be what borks up the map for Level 6 specifically.
All others are untouched.
I don't know why this value was originally added. I know Bogaa helped me with some stuff in this move_maps.asm file, and this value was added alongside the value to move the dot for the overworld automap to the right of the screen.

That specific change at 0x1993D seems to be modifying the table for the Drawn Map Data for Level 6. It changed the $F1 there for $10 for some reason. Dunno why.

I'll remove that code in the meanwhile, as I have confirmed and verified it does nothing but bork the map for Level 6, I'll still check with Bogaa to be absolutely sure, though.

In the meanwhile, all the fixes and revamped code for Automap has been updated in the GitHub repo.
The latest commit should also have the fixes for both the Palette bug with Automap, and the Dungeon 6 Map not having certain tiles appearing.

[An0n_Cyph3r]

I've been testing this on 3DS via CIA injections.

The previous versions of the IPS mod worked. However, the latest version doesn't for some reason. It either crashes once I press start, or it works fine with major srpite glitches...

EDIT: I figured out why it's been doing that. I also tested it out on an emu.

So, if you input a one letter name for your character (like just "A" for example), the game starts going AWOl for some reason. But, if you input more characters (like using "LINK" or "ZELDA" as a name), the game starts playing normally. Not sure why it's doing that.

It's still an issue, though. Dying hard-locks the game, so the only thing I can do is reset from the beginning.

[ShadowOne333]

I've been working on something quite big this week. Although, it might not be AS big to some people, as the feature is quite minimal aesthetically, but means quite a lot for Zelda 1 hacking in general.

One thing that always bothered me from the original Zelda was how blocky some parts of the game looked.
Like, the rocky terrain is supposed to be that, rocky and jagged, yet it had straight 90 degree sections which kinda threw me off a bit.

I decided to try to tackle that, and I tried to delve into the realms of screen data and column definitions for Zelda 1. And with that being said...

I was completely successfully at not only repointing the entire column definitions, but I was also able to EXPAND the amount of available column definitions!
Previously, the game had around unique 160 columns. Now with my expanded columns code, the user can now implement up to 255 unique columns! The only limitation, of course, being the available free space you have and how good you are at optimizing the column definitions to save up space (which I'm  not, lol)

I was able to implement manually around 40+ new columns.
The casual Zelda player might not catch them on first sight, but those experienced in the game will definitely notice the difference, as I tried to polish the whole overworld, screen-by-screen, with detail wherever I was able to.

Here's an image of an almost finished version of the overworld map with the new 40+ column definitions, courtesy of user @gzip. (Note: The image is not how it looks in the final game, as I polished it a bit more after that):



With that being said, I encourage everyone to try out the new patch, and test out the overworld in its entirety to see if you can pinpoint the small but nifty polished columns for the overworld.

Also, as a side note, to everyone who tests the latest beta available at GitHub, please pay close attention to Item Toggle (press Select to change B button item), Automap and the 999 Rupee/Arrow implementations. I move some code related to those hacks around to make sufficient space for the new columns.
From my initial tests, Automap and Item Toggle worked fine, but I didn't test the 999 Rupees nor the Arrow counter hacks, so please make sure to confirm if those are working properly.

Enjoy!

[ifightdragons]

This seems great, but I honestly don't know what to look for with regards to "columns". The map you posted just looks like the normal map to me, even though you've told us it's not.

If you could post a comparison screenshot that shows the difference before and after your improvement, that would be very helpful. Doesn't have to be the entire map.

[CoolCatBomberMan]

This seems great, but I honestly don't know what to look for with regards to "columns". The map you posted just looks like the normal map to me, even though you've told us it's not.

If you could post a comparison screenshot that shows the difference before and after your improvement, that would be very helpful. Doesn't have to be the entire map.

No idea how to post pictures, but see the island with the first dungeon? Check the corners.

[ifightdragons]

No idea how to post pictures, but see the island with the first dungeon? Check the corners.

Thanks! Now I've seen the light 

[ShadowOne333]

@CoolCatBomberMan is in the right track
As I mentioned, the changes are REALLY minimal, and are only aesthetic, but this brings great potential so that other hackers can expand the default columns and rework them however they see fit.
With my implementation, users can add up to 96+ new columns out of the ~144 that are used by default in the vanilla game, giving the final columns count to 255 as a maximum.

For those really interested in pinpointing the changes, you guys can open up the following two images in a tab each, and then compare them by switching tabs. That should make it easier to detect the changes for the columns I did exclusively for Redux (Note: The changes are not the final ones, I added some 10 more new columns today, but this is pretty close to the final version we have right now). Images courtesy of @gzip:

[An0n_Cyph3r]

Does this work on all Emus or just FCEUX?

[lexluthermiester]

Does this work on all Emus or just FCEUX?

FCEUX is only being used for debug functionality. The mod will work in any emulators.

[ShadowOne333]

Does this work on all Emus or just FCEUX?

This should work on most NES emulators.
FCEUX is the one I use because of debugging and compatibility, but I have tried Nestopia as well and it works in that one too, same for FCEUMM through RetroArch.


Given my experience with the revamped column definitions and screens, I wanted to see if I could revamp also the cave entrances, which looked really blocky, and behold:



I had to do some clever reworking of tiles to make this work so it doesn't affect Dungeon entrances and also other tiles inside Dungeons, but it now works without screwing other tiles.
However, I still bumped into an issue. When a bombable wall is blown up, the tiles that appear are still a squared 16x16 tile ($24,$24,$24,$24). If I enter and exit the cave, then the proper tiles (as in the image above) appear. It's only when you just bombed the wall that they don't appear.



I tried tacking down the code that is in charge of setting the tiles after bombing a wall, and I think this could be related:

Code: [Select]

16A73: C9 E6 CMP #$E6 ; E6 = Bombable Wall
16A75: F0 0C BEQ $16A83

16A77: C9 EA CMP #$EA ; EA = Armos Statue
16A79: D0 0C BNE $16A87

16A7B: A9 10 LDA #$10 ; A = 10
16A7D: 85 0D STA $0D
16A7F: A9 70 LDA #$70 ; A = 70 (Code for Stairway)
16A81: D0 04 BNE $16A87

16A83: A9 0C LDA #$0C ; A = 0C (Code for Cave Entrance)
16A85: 85 0D STA $0D
The LDA #$0C at $16A83 is the one I think does that, but the curious thing is that said tile definition is the very same as the one from the column definitions ($0C being the one for entrances).

If anyone has a clue as to how to fix this, please let me know!


I also tried giving the water/lava tiles inside Dungeons some slight pixels to match the overworld water, but this seems to break the tile special setting of being walk-through once you get the ladder. With my custom tiles I either have them be solid, or completely walkthrough without ladder.



I might not pursue this, though, as I believe it's not worth the effort.

[Cyneprepou4uk]

If anyone has a clue as to how to fix this, please let me know!

Set breakpoint to the nametable and trace written values when you blow up this wall.

[ShadowOne333]

Set breakpoint to the nametable and trace written values when you blow up this wall.

The problem with doing PPU traces is that they often break at a similar routine.
I have that issue whenever I try tracing PPU stuff.

If you don't mind me asking, how do you debug stuff like that?
Or from the Name Table like you mention.

[Cyneprepou4uk]

If routine is the same, then the game most likely copying bytes from some common PPU buffer, which is located in RAM. Basically you need to find a routine which writes to that buffer.

You can start Trace Logger a couple of frames before your PPU breakpoint gets hit, and then search output log text file for the address which holds #$24 and transfers to $2007. You will probably see this address in debugger somewhere nearby after PPU breakpoint hits.

Or you can just set a write breakpoint to that RAM address. Condition W==#24 can filter unwanted write hits if you're using one of the latest FCEUX builds.
https://ci.appveyor.com/project/zeromus/fceux/build/artifacts

[ShadowOne333]

If routine is the same, then the game most likely copying bytes from some common PPU buffer, which is located in RAM. Basically you need to find a routine which writes to that buffer.

You can start Trace Logger a couple of frames before your PPU breakpoint gets hit, and then search output log text file for the address which holds #$24 and transfers to $2007. You will probably see this address in debugger somewhere nearby after PPU breakpoint hits.

Or you can just set a write breakpoint to that RAM address. Condition W==#24 can filter unwanted write hits if you're using one of the latest FCEUX builds.
https://ci.appveyor.com/project/zeromus/fceux/build/artifacts

That helped a lot! Thanks!
I managed to find the actual opcode that sets the $24 when the bomb has been recently bombed:

Code: [Select]

bank 4; org $8F08 // 0x10F18
lda.b #$24
jmp $8F34
Changing the LDA #$24 to LDA #$54 makes it load the proper tiles for the new arc'd rock cave entrance ($54-$57).
However, I stumbled upon another issue.

When the change is done, the tiles lose their properties and Link cannot enter the bombed wall.
The new tiles are set to be completely solid and Link cannot pass through them.
If I change the collision code I have for the cracked walls so that all 4 tiles from $54 up to $57 have no collision, then Link simply walks over it, but doesn't enter the cave.

So all that's left is fix the properties for those 4 tiles so they act the same way as the $24 ones when used there.

[jimstrom]

Something that hit me, are you planing to make an optional patch to make level 7 and 8 a little bit harder? After the ordeal that is level 6, 7 and 8 feels like a breeze.

Maybe changing some of the weaker monsters to some harder ones if possilbe?

[ShadowOne333]

Something that hit me, are you planing to make an optional patch to make level 7 and 8 a little bit harder? After the ordeal that is level 6, 7 and 8 feels like a breeze.

Maybe changing some of the weaker monsters to some harder ones if possilbe?

Well, depends on what you'd mean for harder.
I think the balance of the game itself inside dungeons, enemies and such is quite okay for an overall audience, but I'm open for suggestions for possible optional patches.


Out of that, I haven't found a way to make the new recently bombed wall cave entrance ($54-$57) to work with the tile definition of $24 so that Link can enter the cave without having to leave the screen and come back.
(Referenced here: https://www.romhacking.net/forum/index.php?topic=29403.msg404505#msg404505 )


I've been thinking about how to deal with the animated tiles stuff without doing mapper conversions, and I think maybe reusing the currently loaded tiles from the PPU and mirroring them or changing them for another loaded tile in PPU could be a possibility. However, I am not sure how feasible this is.

I know it is possible to change tiles on the fly with CHR-RAM, but with a very limited amount of bytes/tiles before VBlank fills up. I think the limit is around 10 8x8 tiles, or around 2 1/2 16x16 tiles.
Bogaa did something like this with the waterfall PoC he showcased some pages ago, and that's what gave me the idea of doing it this way.

Bogaa's Waterfall animation:
https://www.romhacking.net/forum/index.php?topic=29403.msg398928#msg398928

So what I'm thinking here, is instead of switching tiles for new ones, maybe change the currently loaded tile for another one already loaded, so we would only be loading tiles already loaded in PPU, and not loading any new tiles/bytes into the PPU/RAM.

Hopefully this way we can make the whole water stuff be animated without much trouble, but I'm still unsure of the feasibility of this. Here's an example of what I mean:
         

On that example, I'm reusing the tiles of the waterfall, so the top 16x16 tiles are switched with the 16x16 tiles from below, giving the illusion of water running. As for the bottom 8x16 tiles, I am simply mirroring them horizontally to give an animation to those tiles, so they're still the same tiles, simply mirrored, similar to what the Fire sprite does inside caves, to give an example.

In the following example, I took all of the water tiles that are being used for column definitions (overworld), and all I did is simply mirror them horizontally to give them an animation (except for the waterfall tiles, which are following the previous example):


This is just a random idea I had, but still far from knowing if it can be done within the CHR-RAM limitations.
If anyone has any experience with this and/or knows if this idea can actually be achieved, please let me know!

[Cyneprepou4uk]

NES can't mirror background tiles. You either redraw them by writting at PPU, or change a tile bank via mapper registers.

Or you can do both
https://wiki.nesdev.com/w/index.php/MMC3_with_CHR_ROM_and_CHR_RAM

[ShadowOne333]

NES can't mirror background tiles. You either redraw them by writting at PPU, or change a tile bank via mapper registers.

Or you can do both
https://wiki.nesdev.com/w/index.php/MMC3_with_CHR_ROM_and_CHR_RAM

Damn, that's a shame :/
I could probably rework Bogaa's PoC to work per screen. And only modify a set number of tiles to have animation.
I would probably have to sacrifice water corners from having animation at all to possibly make that implementation work.

There's that option, and there's also changing the ROM to CHR-ROM or MMC3 as originally planned.
What mapper does Zelda 2 use? I think that one allows for some CHR pages on their own, and then an NMI hijack like it was done in Zelda 2 by Jasp.