Parallel Worlds buggy staircases

I'm in the process of trying to iron out the last major bug on my list for the PW DX (aka PW v1.2) release, the buggy spiral staircases, but first, I need to understand the problem a little bit better.  Here's how Puzzledude explained it to me

Puzzledude wrote:The other visual problem in the guardhouse are a round staircase, which puts you to another floor - this is a false element issue - but the correct element is missing the upper line of the door. This is a result of false wall-blockset choice - which will not allow round staircases on bg2 (so no way to fix unless the different blockset is choosen - or the gfx of the door is edited).

However, this explanation doesn't really seem to make sense.  For one thing, it's not an issue with the upper line of the door, you walk in front of the entire thing.  See the last few frames, you walk in front of the sides as well.



As for the blockset choice, I went ahead and cataloged all of the staircases in the game, by blockset, bg layer, and object #, to see if I could find any patterns.  The one in the image is in room 82.  Blockset is 3, the staircase is object #139, and it is on BG2.  There aren't any other staircases that use this configuration.  However, room 65 (in the Guardhouse sewers) uses blockset 3, object #139, on BG1, and that one is not glitched.



So, it does sound like the issue is related to putting the door on BG2, rather than with the blockset.  I've made a little bit of headway moving the door to BG1 manually in hex, as well as placing it in front of the wall tile that's behind it on BG1, but I'm unable to actually walk through the door.  Also, I have to shrink one of the BG3 regions or else it covers the door, but doing so causes graphical glitches.



I'm rather limited in what I can do, edit-wise, because I'm currently working directly in hex, but I've at least gotten to the point where I understand how different edits in HM look in hex, so I'm able to do things like moving objects to different layers, relocating, resizing, etc.  Now, I'm just at the point of not really understanding how different layers affect the objects, such as why I can't walk through the staircase after moving it to BG1.

For now, I want to concentrate on this one staircase in room 82.  If I manage to figure it out, I'll move on to others that I've found.  Like I said, I've cataloged all of the staircases in the game, and I'm about halfway through testing them all to mark the buggy ones.  So far, I've found 4 with this same issue, and 2 others with slightly different problems.

Any help would be greatly appreciated. I'm starting to see the light at the end of this tunnel...

So, it does sound like the issue is related to putting the door on BG2, rather than with the blockset.

This is one and the same problem.

You see, Guardhouse has a House blockset, yet houses were not planned to have staircases on bg2. Take a look at the element - it does not match the bg2 walls at all. This is the bg1 element and it should work on bg1, but there are many types of round staircases. The correct coresponding stairse needs to be bg2 staircase. I believe they also exist on the House blockset, but the upper line of the door is all black.

Moving this element to bg1 is a smart choice, since it was meant to be there, but the type should be changed to the "normal" staircase type.

The second problem of this room is sprite priority when going through the staircase. Usually this is fixed automatically if the correct staircase is choosen, since the game then knows to put Link and all sprite behind the staircase, and thus the walls are on top, the way it should be (so you don't see Link walking inside the wall). Another proof that this element is completely wrong, since it doesn't do that (however it was probably the only working choice for Euclid to use).

Puzzledude wrote:Take a look at the element - it does not match the bg2 walls at all.

Those are BG1 walls.  The stairs are intended to match the outer border on the room, the way the other doors do, and they do so perfectly.  I don't really care that the tiny upper corner pieces don't look right, it's just the layer priority that I'm concerned with.

Puzzledude wrote:The correct coresponding stairse needs to be bg2 staircase. I believe they also exist on the House blockset, but the upper line of the door is all black.

I'm not sure what you mean, these are the 4 different stair types available for blockset 3.  No black line here.

Puzzledude wrote:Moving this element to bg1 is a smart choice, since it was meant to be there, but the type should be changed to the "normal" staircase type.

After cataloging every staircase in PW, as well as in LoZ3, it definitely seems that type 139 *is* the "normal" staircase type.

Puzzledude wrote:but there are many types of round staircases.

I've found exactly 4.  Two up and two down.  In HM, it numbers them 138, 139, 13A, and 13B.  The one in question is type 139, in a room using blockset 3.  Room 65 also uses blockset 3, and type 139 and it works perfectly.  The only difference is that it is placed on BG1 instead of BG2.  So I feel like that's the fix that needs to be made, and I attempted to do that, but it results in the staircase acting like a wall, I can't walk down it.  I realize this is probably due to the fact that I did this manually in hex, so is there perhaps any further info I need to understand about the room data format, i.e. something else I need to change elsewhere to indicate that the staircase is on BG1?

Ok, so I found a better example/reference room. Room #1 in LoZ3 has staircase type 13B on BG2, which is directly on top of a BG1 wall block. This is essentially identical to the room setup of the problematic room 82 in PW. They use different blocksets, but that shouldn't affect the layer priority. To test, I switched the stairs to type 139, and it still worked correctly, so the stair type doesn't seem to be the issue.

qwerty, I saw you have the wish to fix PW and maybe I did not explain it right, or you didn't understand, so I fixed this for you!
It takes a lot of explaining and before I could explain all that, it is just easier for me to do it.



Here are the Hex changes (first remove the file Header!):


1.)
at 27A2C,
change byte 08 to 00
(previous transit to plain2= bg2 gets reverted to normal plane0= bg1 in room 80), ie when going back up into this room.


2.)
at 4E034,
change bytes 98 05 to 18 03

fixes the Knight sprite in room 82, which was now trapped in bg2 indefinitely (18 is bg1 again), as well as his location (2 units left, so he doesn't start on the newly inserted decoration element),


3.)
at 111673,
inserts new room code for room 82 (fixes problem, edits room, logic is now from bg1 to bg1, before it was from bg2 to bg1, fixes Link sprite priority)

copy this and at 111673 press ctrl+B (= paste overwrite)
63 00 BC 1C DC 9C 1C DC 03 06 01 AC 20 DC B8 24 B2 A0 1F B2 AA A1 61 41 38 64 01 23 63 5C 20 64 68 15 62 FD A0 42 40 A2 62 0B 84 C0 FD 02 8F FC 01 08 00 6B 02 11 5D 04 50 29 04 12 11 03 FC 05 C9 FD 05 CB FD 71 0A 19 91 01 FC 29 00 40 A7 62 51 90 C0 52 8E C0 5C 38 22 D1 C7 FC D1 DB FC FE AE 81 89 CA C0 89 93 C0 FE A9 00 C8 13 FD A0 47 FD C8 2B FD C8 2F FD C8 47 FD C8 4B FD A0 4B FD A0 2B FD A0 2F FD 9B 63 FA C8 58 FD E3 63 FA A0 13 FD EC 9E 82 5C 38 22 1B E3 FA 5C 38 22 5C 38 22 60 58 3D 52 39 69 52 39 69 50 5C 69 FD AB C2 FC 99 39 19 DF FD FD 0B C6 FD 09 02 FD 72 8B 50 2B F9 DF A2 FD 27 B6 FD FF FF 28 20 E2 1C 20 E2 FC 8A A0 FC CA A0 FC 99 F9 25 20 FB 28 2C E2 20 2C E2 12 4B FD 16 43 FD 12 2B FD 12 23 FD 1D 38 34 38 22 71 1C 22 71 FC E4 A1 FC C5 21 FC E5 21 FF FF FC 79 E0 FC D9 E0 00 4D C6 13 2F C6 3A 15 C6 03 13 C6 50 BF 01 F0 FF 61 00 81 00 80 00 62 36 FF FF


PS
I never bothered to edit this in the Remodel, since it seemed to much work for little effect, but at least I've done it now.

Note: upper is valid for the Remodel too, except the sprite (in Remodel this sprites was NOPed out).

The strategy I used:
Find room pointer, go to code, 111673 (block is 123), copy to another Rom (blank Alttp editable with HM, I used room 54 here, edit room but keep block length 123, ie use existing elements only, when everything was fixed, copy back to PW= upper code and test). I used RT for header and sprite info.

PPS
Euclid actually fixed that black line above door on blockset-3= house if the door is on bg2 in the PW hack. You can see when you insert this element into regular Alttp. I decided to use the normal transit door on bg1 (element 139).

On your picture above 138, 139, 13A, 13B (in order= go up on bg1, go down on bg1, go up on bg2, go down on bg2)= these are the 4 staircases.

Room #1 in LoZ3 has staircase type 13B on BG2,

Exactly, since this is how it needs to be, element 13B is for going down while you are on bg2 (lower level of the same room). And in this case you indeed are on the lower level of the same room, ie bg2. So you need bg2 saircase leading down, ie 13B. And as you can see Nintendo fixed this door completely (the door has a line above it pointing down on this blockset). Do the same on blocket 3 (house) on native Alttp and you will see a black line above the door.

Wow, thank you!  That really helps a ton.

maybe I did not explain it right, or you didn't understand

A little of both, probably... it's a lot to wrap my head around all at once.  Having a working example goes a LONG way towards understanding how to proceed with the remaining problem rooms.

I never bothered to edit this in the Remodel, since it seemed to much work for little effect, but at least I've done it now.

Totally understandable.  It was just one of those "I've come this far, and I'm so close, it would be a shame not to add that last bit of polish" things...

Euclid actually fixed that black line above door on blockset-3= house if the door is on bg2 in the PW hack.

Well, that would explain it then

at 27A2C,
change byte 08 to 00
(previous transit to plain2= bg2 gets reverted to normal plane0= bg1 in room 80), ie when going back up into this room.

Can you explain this a little more, or if it's documented somewhere, can you point me to that so I can understand a little better?  I get what's happening, essentially it's saying "this is the setting of the room you're travelling to", but I don't know the details like how to find the byte to edit for a different room, or what the valid values are.

I used RT for header and sprite info.

RT?

at 27A2C,
change byte 08 to 00
(previous transit to plain2= bg2 gets reverted to normal plane0= bg1 in room 80), ie when going back up into this room.

Can you explain this a little more, or if it's documented somewhere, can you point me to that so I can understand a little better?  I get what's happening, essentially it's saying "this is the setting of the room you're travelling to", but I don't know the details like how to find the byte to edit for a different room, or what the valid values are.

What's happening here is that you are editing the game's header data. From my dungeon hex document you can see the primary pointer points to a segment around 27000. This is where the data for header is. In the upper case you need to tell the game to "go from room 80 back to 82, but on plane0= normal. In PW it was plane1= bg2. This is easy fixable with HM, but in PW you need to track the byte down in hex.
This needs to be done, since I decided to fix this by going from bg1 (room82) to bg1 (room 80) rather than the complex bg2 (room 82) to bg1 (room 80).


Yes it is documented under my Dungeon hex data document.
https://www.zeldix.net/t886-zelda3_ultra_documents
under
DOC PACK-2 ADVANCED
01 Zelda3 DUNGEON HEX Data (by Puzzledude) txt

RT?

This is the Room Transfer program, made by XaserLe, which can help you a lot for what you are doing. With this program you can quickly "hunt down" what to change in hex. The program is capable to read all the pointers based on my Dungeon hex document and do things automated (so you don't have to calculate pointers and search for data manually).
In addition it will "drop" all data towards the end of the file in hex (must use a copy of the rom for this) and with room numbers displayed before the code.
https://www.zeldix.net/t141-unlimited-room-header-and-the-rt-room-transfer-program

This is dos based. Run CMD and then type RT.exe PW.smc and it will bring all rooms data of PW towards the end of the expanded 3MB file. Now search in hex under txt and type room 82. It will find room 82 sprites, items, header and data(layers). Now copy a segment of this code and search it in original PW (under hex search) and you will find where the code is. This is how I found the sprite code and the header code for rooms 82 and 80 in PW.

If you then go to native Alttp and go to a any room which has staircase1 in effect and edit it to plane2= 1 (instead of 0), you can hex compare native Alttp and your edit. You'll see one byte change was from 00 to 08. So the reversed is 08 to 00. There was only one byte 08 in the header code for room 80. So this has to go to 00.

Similar with sprites, Knight as byte 98 must go to 18 if the same sprite is on bg1 and X any Y are right after. So the 05 was the X location, if this goes to 03 it will go one unit left etc.
Process is the same, I used native Alttp and hex comparing to see that. (I could use the same method to see what to do with the byte, so that the sprite would change to Useless sprite and thus remove the soldier altogether - which I did in PR).

I have to say that I believe the main problem of room 82 was the fact which type of wall there was behind this door. It definitely should be element 13B instead of 139. I tracked this byte down as well, changed it, and the element was now ok, but not the sprite priority.

I believe the wall behind this door was inserted on the wrong bg/layer (ie when you have the options 1, 2, 3 when inserting layers). It was inserted on layer-1. It should be inserted on layer-3 (ie bg3). Namely when you want to make the lower part of the same room, it is wise to insert all lower-walls on layer-3 and all upper walls on layer-1 (this is how it is usually done). The element 13B should then also be inserted on layer-3, but everything was inserted on layer-1, which I believe was the problem for false sprite priority for Link.
Same problem appears in the church (when you transit from sewers to back church area).
But since I change everything to normal transit from bg1 to bg1 and re-inserted everything on layer-1, the game knew what to do.


Like said this would be easy fixable in "normal" Alttp, but this is PW, where you need to edit in hex.
There is also a bat in that back church area, which is on bg1, should be on bg2, so it seems it flies through you and you can not hurt it. Again easy fixeable in native Alttp, but in PW, you need to track the byte down in hex (which is not so easy).

at 27A2C,
change byte 08 to 00
(previous transit to plain2= bg2 gets reverted to normal plane0= bg1 in room 80), ie when going back up into this room.

Can you explain this a little more, or if it's documented somewhere, can you point me to that so I can understand a little better?  I get what's happening, essentially it's saying "this is the setting of the room you're travelling to", but I don't know the details like how to find the byte to edit for a different room, or what the valid values are.

Essential reading in this case (from my Dungeon Hex document)

Code:



***********************************************
6.) ROOM HEADER PROPERTIES
***********************************************


*Primary pointer at B5DC
Code BF, 02 F5 04, 85 0D, E2 20 C2 10, A9 04

02 F5 04 points to 27502

04 defines the global bank. Can be realocated anywhere between 0 and 400000.
For instance BF, 02 F5 24, 85 0D, E2 20 C2 10, A9 24; new address is 127502.


*Secondary pointers at:
27502 (block is 280)

*Data at:
27782 (block is 87E)

*Pointers + data
27502 (block is AFE)

*Pointer read
82 F7 = F7 82 = 04 F7 82 = 27782


*Header code (14 bytes maximum)

1st byte,
bg properties + collision

2nd byte,   3rd byte,   4th byte,   5th byte,     6th byte,   7th byte
PAL         BLK         EnemyBLK    Room effect   Tag1        Tag2


8th byte
Plane properties for hole/warp and staircase 1, 2, 3

9th byte
Plane properties for staircase 4

10th byte,   11th byte,    12th byte,    13th byte,    14th byte.
hole/warp    staircase1    staircase2    staircase3    staircase4.

This is essentialy related to room transit values as a part of a room header.


at 27A2C,
change byte 08 to 00
(previous transit to plain2= bg2 gets reverted to normal plane0= bg1 in room 80), ie when going back up into this room.

Can you explain this a little more, or if it's documented somewhere, can you point me to that so I can understand a little better?  I get what's happening, essentially it's saying "this is the setting of the room you're travelling to", but I don't know the details like how to find the byte to edit for a different room, or what the valid values are.

Now let's track down the header data of room 80 of PW.

Primary pointer at B5DC in PW is
BF 02 F5 04
This is (reversed) 04F502 (ie Snes address), use Lunar address or Snestuff to convert to PC address= 027502.

So at 27502 there is a start for secondary pointers (in this case 2 byte pointers). Your room is 80. The code starts: pointer for room 0, 1, 2, ... 320. So now you add 1= room 0. So 80+1= 81. Now 81x2 is 162 in dec.

Go to address 27502 and choose command in hex editor: "select block" of data, choose "dec" and "length= 162".
It will select 162 bytes in dec. Last 2 bytes are your pointer for room 80, In PW it is 25 FA.
Reverse 25 FA to FA 25 and add 04 (current bank)= 04 FA 25= Snes address= convert to PC address= 027A25.
Next pointer is FA 30= 027A30.

Header for room 80= at 27A25 and it goes to 27A2F (since 27A30 is next room).
At 27A25, there is the code
C0 02 03 04 00 17 00 08 00 00 52

In order: bg properties, Pal of the room, BLK, enemy BLK (04),
room effect, tag1, tag2, plane properties on transit, hole warp room to drop to, staircase1 (and also 2, 3, 4 but not for this room).
Last byte is 52 in hex= room 82 in dec. This is the room where the staircase1 will take you. No further staicases are defined.

If you run the game through RT, and then search for room 80. It will show the same code for room 80 (header) at the back of the rom.
C0 02 03 04 00 17 00 08 00 00 52


Now you need native Alttp and a copy of Native Alttp. Both must be opened in HM and saved once! In the copy change the properties (plane 0= to plane 1 for any room). Then load both file in hex editor and choose file-compare. It will find one single byte that has been changed, 00=08 (if indeed staircase1 plane is edited).

The plane is actually bit vise. You have 1 byte for defining plane for 3 staircases and one more for the 4th staircase. So the 9th byte in the row should almost always be 00. 8th byte 00 means plane for staircase1, 2, 3 = 00 (ie normal). But you also have combos of 1 and 0. Plane 1 means spawn Link in another room and put him to bg2. If staircase is choose, and not hole, the games will also know to put him on the lesser Y coordinate (since bg2 needs bg1 wall and bg2 wall underneath it).

Try not to fix (change this byte) from 08 to 00 and start the game and go back up. You'll see Link spawn to low and he will disappear (ie spawned to bg2, as it previously was).

I actually found another room in aLttP that's an even better approximation of room 82.  It has the player enter the room on BG1, then has the in-room ladders that bring you down to BG2, and there are staircases on the lower floor part.  It uses a different blockset, but that shouldn't make a difference when it comes to layer priority, right?




Observations:

The wall behind the staircase is on BG1, and the staircase itself is on BG2 (object 13B).  There is also a BG3 layer encompassing the staircase, the wall behind it, and the floor in front of it, just like the BG3 layer in room 82.  So I guess the question now is, why does the priority work properly there but not in PW room 82?

Yes, I have to say I examined further with this room and surprizingly found out that Euclid did everything correct (except the element type 139 which is irrelevant), as you observed. The staircase on bg2 is indeed correctly placed (it just needs to be 13B instead of 139 element), but changing it to 13B doesn't fix the problem.

The wall behind it must indeed be on bg1, and the definition of the lower level, aka bg2, must be defined with 0C3 element inserted on bg3 (as it is normal when making the lower level).

So if you change the element to 13B, everything is correctly made, yet the sprite priority if false.
Which makes me believe this is thus a coding/ASM problem, ie something, which you can not fix with Hyrule Magic.

I wonder if it's an object ordering issue like the trapdoor walking through when closed. I've found a few more rooms with the problem, and all but one of them are the same arrangement, lower floor, BG1 wall, BG2 stairs, BG3 floor. The last one is the entrance to Favore's Isle, room 135, same arrangement, except not on the lower floor.

Puzzledude wrote:PPS
Euclid actually fixed that black line above door on blockset-3= house if the door is on bg2 in the PW hack.

WAIT A MINUTE IS THIS THE PROBLEM?

When you edit a blockset, there's the "In Front" checkbox.  Is it possible that when Euclid edited this element for blockset 3 that he didn't check that box?

Edit: Nope, nevermind.  All 4 staircases for that blockset look right

Also, I tried importing the room into aLttP, and the stairs work perfectly, so that's interesting...

WAIT A MINUTE IS THIS THE PROBLEM?

When you edit a blockset, there's the "In Front" checkbox. Is it possible that when Euclid edited this element for blockset 3 that he didn't check that box?

Edit: Nope, nevermind. All 4 staircases for that blockset look right Sad

Also, I tried importing the room into aLttP, and the stairs work perfectly, so that's interesting...

That's actually just a Gfx edit. Like said there is something unknown and ASM related in the PW, that's causing this. Similar to that room of the Level-1 dungeon of the light world.

Enter the dungeon and go right and then the path leads down. Go through the bottom door, then go back up, you will notice a palette swap, which can not be edited of fixed with HM and there is no logical explanation why this is happening.

It appears that these are small ASM issues which could not be fixed.

Actually, I think I might be right.  Or at least on the right track. The staircase is made up of 12 blocks, in a 4x3 arrangement:

Code:

1234
5678
9ABC

If you view the blocks in OAM, the priority bit on a properly built staircase should be set on blocks 1,2,3,4,5, and 8.  In the non-working staircases, it's only set on 2 and 3 (as seen in no$snes).  I'd be willing to bet money that the OAM priority bit corresponds to this checkbox in HM.



However, like I said, in HM, it seems to indicate that the correct blocks have the "in front" box checked, so I wonder if this is a case of data being moved, so what's shown in HM isn't what's actually used in-game.

I know it's probably silly, but I want to fix this so badly...

And now, when I tried to copy the fixed copy of that blockset from PW into aLttP to get rid of the black bar, it said "not enough room to save blockset" so that basically confirms that the data WAS relocated, so there's an extremely good chance that what HM is showing isn't actually accurate (which isn't a huge surprise, since it can't display a lot of PW stuff accurately). I think I'm on the right track

And now, when I tried to copy the fixed copy of that blockset from PW into aLttP to get rid of the black bar, it said "not enough room to save blockset"

That's because this is a Gfx edit and HM might not allow that. Usually gfx is edited with YYchr and there is space at the end of the gfx string, so you should be able to correctly fix this bar in Alttp (original authors did not do this since houses don't use doors on bg2).
"Not enought room to save blockset" means (in this case) that PW does not use the same gfx as Alttp, which is indeed true, however the "fillling" of the element as well as the properties for them remain intact in PW (and are the same as is Alttp).

So, this is also not the problem. PW and ALTTP have the data on this on the same place.

You can verify like so:
The tile 13B, the upper row of 4 elements, has the infront priority:

Infront properties
at 2CE3= 28
at 2CE9= 28
at 2CEF= 68 (X mirrored)
at 2CF5= 68 (X mirrored)

Not-Infront properties
at 2CE3= 08
at 2CE9= 08
at 2CEF= 48
at 2CF5= 48


So if you check Parallel Worlds and Parallel Remodel, you can see that they have the 28, 28, 68, 68, so all infront.
You can however change them to 08, 08, 48, 48, which should be not-infront, to test things further. But this will obviously not solve anything, since then it will infact not be infront. However this applies only for these 4 tiles, yet the problem is that Link is entirely ontop of the entire wall, so something else undocumented is wrong here, definitely fixable only with ASM tracing.

Woo, I think I found it, for real this time.  I haven't *fixed* it, but I have *found* it.

LoZ3

Code:

068361 jsl $09b06e

ZPW

Code:

068361 jsl $248000
248000 jsr $8008
248003 jsl $09b06e

So, the issue is the extra call to $248008, as I've confirmed by nop-ing it out, which fixes the staircase, but I'm not really sure exactly what the subroutine at $248008 is actually doing, so in order to avoid any side effects, I need to figure that out.

Code:

248008 lda $10       [000010] A:0140 X:0040 Y:000c S:01eb D:0000 DB:06 nvMXdizC V: 37 H: 746 F:12
24800a cmp #$07               A:0107 X:0040 Y:000c S:01eb D:0000 DB:06 nvMXdizC V: 37 H: 770 F:12
24800c beq $802d     [24802d] A:0107 X:0040 Y:000c S:01eb D:0000 DB:06 nvMXdiZC V: 37 H: 786 F:12
24802d nop                    A:0107 X:0040 Y:000c S:01eb D:0000 DB:06 nvMXdiZC V: 37 H: 808 F:12
24802e jsr $8310     [248310] A:0107 X:0040 Y:000c S:01eb D:0000 DB:06 nvMXdiZC V: 37 H: 822 F:12
248310 jsr $8320     [248320] A:0107 X:0040 Y:000c S:01e9 D:0000 DB:06 nvMXdiZC V: 37 H: 868 F:12
248320 lda $7ef273   [7ef273] A:0107 X:0040 Y:000c S:01e7 D:0000 DB:06 nvMXdiZC V: 37 H: 914 F:12
248324 inc                    A:013b X:0040 Y:000c S:01e7 D:0000 DB:06 nvMXdizC V: 37 H: 954 F:12
248325 sta $7ef273   [7ef273] A:013c X:0040 Y:000c S:01e7 D:0000 DB:06 nvMXdizC V: 37 H: 968 F:12
248329 cmp #$3c               A:013c X:0040 Y:000c S:01e7 D:0000 DB:06 nvMXdizC V: 37 H:1008 F:12
24832b beq $832e     [24832e] A:013c X:0040 Y:000c S:01e7 D:0000 DB:06 nvMXdiZC V: 37 H:1024 F:12
24832e lda #$00               A:013c X:0040 Y:000c S:01e7 D:0000 DB:06 nvMXdiZC V: 37 H:1046 F:12
248330 sta $7ef273   [7ef273] A:0100 X:0040 Y:000c S:01e7 D:0000 DB:06 nvMXdiZC V: 37 H:1062 F:12
248334 lda $7ef272   [7ef272] A:0100 X:0040 Y:000c S:01e7 D:0000 DB:06 nvMXdiZC V: 37 H:1102 F:12
248338 inc                    A:0135 X:0040 Y:000c S:01e7 D:0000 DB:06 nvMXdizC V: 37 H:1142 F:12
248339 sta $7ef272   [7ef272] A:0136 X:0040 Y:000c S:01e7 D:0000 DB:06 nvMXdizC V: 37 H:1156 F:12
24833d cmp #$3c               A:0136 X:0040 Y:000c S:01e7 D:0000 DB:06 nvMXdizC V: 37 H:1196 F:12
24833f bpl $8342     [248342] A:0136 X:0040 Y:000c S:01e7 D:0000 DB:06 NvMXdizc V: 37 H:1212 F:12
248341 rts                    A:0136 X:0040 Y:000c S:01e7 D:0000 DB:06 NvMXdizc V: 37 H:1228 F:12
248313 jsr $8371     [248371] A:0136 X:0040 Y:000c S:01e9 D:0000 DB:06 NvMXdizc V: 37 H:1270 F:12
248371 lda $1b       [00001b] A:0136 X:0040 Y:000c S:01e7 D:0000 DB:06 NvMXdizc V: 37 H:1316 F:12
248373 bne $8376     [248376] A:0101 X:0040 Y:000c S:01e7 D:0000 DB:06 nvMXdizc V: 37 H:1340 F:12
248376 lda $f2       [0000f2] A:0101 X:0040 Y:000c S:01e7 D:0000 DB:06 nvMXdizc V: 37 H:1362 F:12
248378 and #$70               A:0100 X:0040 Y:000c S:01e7 D:0000 DB:06 nvMXdiZc V: 38 H:  22 F:12
24837a cmp #$50               A:0100 X:0040 Y:000c S:01e7 D:0000 DB:06 nvMXdiZc V: 38 H:  38 F:12
24837c bne $8383     [248383] A:0100 X:0040 Y:000c S:01e7 D:0000 DB:06 NvMXdizc V: 38 H:  54 F:12
248383 cmp #$60               A:0100 X:0040 Y:000c S:01e7 D:0000 DB:06 NvMXdizc V: 38 H:  76 F:12
248385 beq $838b     [24838b] A:0100 X:0040 Y:000c S:01e7 D:0000 DB:06 NvMXdizc V: 38 H:  92 F:12
248387 jsr $8390     [248390] A:0100 X:0040 Y:000c S:01e7 D:0000 DB:06 NvMXdizc V: 38 H: 108 F:12
248390 ldy #$16               A:0100 X:0040 Y:000c S:01e5 D:0000 DB:06 NvMXdizc V: 38 H: 154 F:12
248392 ldx $0414     [060414] A:0100 X:0040 Y:0016 S:01e5 D:0000 DB:06 nvMXdizc V: 38 H: 170 F:12
248395 lda $02894c,x [028952] A:0100 X:0006 Y:0016 S:01e5 D:0000 DB:06 nvMXdizc V: 38 H: 202 F:12
248399 bpl $839f     [24839f] A:0101 X:0006 Y:0016 S:01e5 D:0000 DB:06 nvMXdizc V: 38 H: 242 F:12
24839f cpx #$02               A:0101 X:0006 Y:0016 S:01e5 D:0000 DB:06 nvMXdizc V: 38 H: 264 F:12
2483a1 bne $83a5     [2483a5] A:0101 X:0006 Y:0016 S:01e5 D:0000 DB:06 nvMXdizC V: 38 H: 280 F:12
2483a5 sty $1c       [00001c] A:0101 X:0006 Y:0016 S:01e5 D:0000 DB:06 nvMXdizC V: 38 H: 302 F:12
2483a7 rts                    A:0101 X:0006 Y:0016 S:01e5 D:0000 DB:06 nvMXdizC V: 38 H: 326 F:12
24838a rts                    A:0101 X:0006 Y:0016 S:01e7 D:0000 DB:06 nvMXdizC V: 38 H: 368 F:12
248316 jsl $02ff8c   [02ff8c] A:0101 X:0006 Y:0016 S:01e9 D:0000 DB:06 nvMXdizC V: 38 H: 410 F:12
02ff8c rep #$30               A:0101 X:0006 Y:0016 S:01e6 D:0000 DB:06 nvMXdizC V: 38 H: 472 F:12
02ff8e lda $7ef3e5   [7ef3e5] A:0101 X:0006 Y:0016 S:01e6 D:0000 DB:06 nvmxdizC V: 38 H: 494 F:12
02ff92 cmp #$9210             A:9210 X:0006 Y:0016 S:01e6 D:0000 DB:06 NvmxdizC V: 38 H: 582 F:12
02ff95 bne $ff9c     [02ff9c] A:9210 X:0006 Y:0016 S:01e6 D:0000 DB:06 nvmxdiZC V: 38 H: 606 F:12
02ff97 lda $7ee003   [7ee003] A:9210 X:0006 Y:0016 S:01e6 D:0000 DB:06 nvmxdiZC V: 38 H: 622 F:12
02ff9b rtl                    A:0002 X:0006 Y:0016 S:01e6 D:0000 DB:06 nvmxdizC V: 38 H: 670 F:12
24831a sep #$30               A:0002 X:0006 Y:0016 S:01e9 D:0000 DB:06 nvmxdizC V: 38 H: 714 F:12
24831c rts                    A:0002 X:0006 Y:0016 S:01e9 D:0000 DB:06 nvMXdizC V: 38 H: 736 F:12
248031 inc                    A:0002 X:0006 Y:0016 S:01eb D:0000 DB:06 nvMXdizC V: 38 H: 778 F:12
248032 sta $7ee003   [7ee003] A:0003 X:0006 Y:0016 S:01eb D:0000 DB:06 nvMXdizC V: 38 H: 792 F:12
248036 cmp #$03               A:0003 X:0006 Y:0016 S:01eb D:0000 DB:06 nvMXdizC V: 38 H: 832 F:12
248038 beq $803b     [24803b] A:0003 X:0006 Y:0016 S:01eb D:0000 DB:06 nvMXdiZC V: 38 H: 848 F:12
24803b lda #$00               A:0003 X:0006 Y:0016 S:01eb D:0000 DB:06 nvMXdiZC V: 38 H: 870 F:12
24803d sta $7ee003   [7ee003] A:0000 X:0006 Y:0016 S:01eb D:0000 DB:06 nvMXdiZC V: 38 H: 886 F:12
248041 lda $7ee002   [7ee002] A:0000 X:0006 Y:0016 S:01eb D:0000 DB:06 nvMXdiZC V: 38 H: 926 F:12
248045 inc                    A:003b X:0006 Y:0016 S:01eb D:0000 DB:06 nvMXdizC V: 38 H: 966 F:12
248046 sta $7ee002   [7ee002] A:003c X:0006 Y:0016 S:01eb D:0000 DB:06 nvMXdizC V: 38 H: 980 F:12
24804a cmp #$3c               A:003c X:0006 Y:0016 S:01eb D:0000 DB:06 nvMXdizC V: 38 H:1020 F:12
24804c bpl $804f     [24804f] A:003c X:0006 Y:0016 S:01eb D:0000 DB:06 nvMXdiZC V: 38 H:1036 F:12
24804f lda #$00               A:003c X:0006 Y:0016 S:01eb D:0000 DB:06 nvMXdiZC V: 38 H:1058 F:12
248051 sta $7ee002   [7ee002] A:0000 X:0006 Y:0016 S:01eb D:0000 DB:06 nvMXdiZC V: 38 H:1074 F:12
248055 lda $7ee001   [7ee001] A:0000 X:0006 Y:0016 S:01eb D:0000 DB:06 nvMXdiZC V: 38 H:1114 F:12
248059 inc                    A:0025 X:0006 Y:0016 S:01eb D:0000 DB:06 nvMXdizC V: 38 H:1154 F:12
24805a sta $7ee001   [7ee001] A:0026 X:0006 Y:0016 S:01eb D:0000 DB:06 nvMXdizC V: 38 H:1168 F:12
24805e cmp #$3c               A:0026 X:0006 Y:0016 S:01eb D:0000 DB:06 nvMXdizC V: 38 H:1208 F:12
248060 bpl $8063     [248063] A:0026 X:0006 Y:0016 S:01eb D:0000 DB:06 NvMXdizc V: 38 H:1224 F:12
248062 rts                    A:0026 X:0006 Y:0016 S:01eb D:0000 DB:06 NvMXdizc V: 38 H:1240 F:12
248003 jsl $09b06e   [09b06e] A:0026 X:0006 Y:0016 S:01ed D:0000 DB:06 NvMXdizc V: 38 H:1282 F:12

...and then there was one

Code:

$2483A5: sty $1c -> nop nop

Nixing that one instruction fixes the stairs, but I don't know what $1c is actually being used for, so I still need to do some more poking around to check for side effects.  Initial tracing shows that $1c gets lda'd inside of the NMI routine, then stored to $212c, so that's probably where the bug is manifesting.  So, now I need to try and pick through the code leading up to $2483A5 and try and figure out the correct conditional branch.

Nice find qwerty, I tested this out and indeed on hex address 1203A5 there is a 84 1C and if changed to EA EA, the stairse in the guardhouse and farore's isle have normal sprite priority (and I assume for all staircases of this type of element).

Also, who knows what this code is, since it is beyond 1MB and can not be compared to original Alttp.

Puzzledude wrote:Also, who knows what this code is, since it is beyond 1MB and can not be compared to original Alttp.

Yeah, that's the problem.  My next step is to disassemble the full block, then start comparing it to the known patches listed here, like the 24-item HUD and things like that, to see if I can figure out where that code is coming from, and what it's doing.  Because of the way $1c is accessed in NMI

Code:

008174 lda $1c
008176 sta $212c

which is the same in aLttP, I'm going to assume that $1c is a global variable used to update $212c, and not a local scratchpad value, which may potentially help, as I can skim through the aLttP code and see how it uses that variable, even though the code isn't directly comparable.

Ok, looks like I was right about $1c.  From MoN's disassembly RAM log:

$1C[0x01] - (NMI)
   
   Main Screen Designation (TM / $212C)

   uuusabcd
   
   u - Unused
   s - Sprite layer enabled
   a - BG4 enabled
   b - BG3 enabled
   c - BG2 enabled
   d - BG1 enabled