ROM/Bank 02

This is a subpage of ROM

• 0x12475 to 0x1252C (----) = Code
• 0x1252D to 0x1253B (----)
• 0x1253C to 0x125EB (----) = Code
• 0x125EC to 0x129C3 (----)
• 0x125EC to 0x1262B (----) = (0x40 entries, 1 byte each)
  • Actual OW location to use for conglomerated OW areas
• 0x1262C to 0x12633 (----) = (0x04 entries, 2 bytes each)
  • adjustment for $84
• 0x12634 to 0x12833 (----) = (0x100 entries, 2 bytes each)
• 0x12834 to 0x1283B (----) = (0x04 entries, 2 bytes each)
• 0x1283C to 0x12843 (----) = (0x04 entries, 2 bytes each)
• 0x12844 to 0x12883 (----) = (0x40 entries, 1 byte each) = Size of overworld areas
  • 0x00 = 512‍×​512 pixel map
  • 0x20 = 4‍×​1024 pixel map
  • All other values are not considered.
• 0x12884 to 0x128C3 (----) = (0x40 entries, 1 byte each)
  •  ???? Gets written to $0717, whatever that does.

Note that the following two arrays overlap in the middle (by a range of 0x80 entries)

• 0x12884 to 0x128C3 (----) = (0x80 entries, 1 byte each) = Y / X?
• 0x128C4 to 0x129C3 (----) = (0x80 entries, 1 byte each) = Y / X? fill in later
• 0x129C4 to 0x12CD9 (----) = Code
• 0x12CDA to 0x12D49 (006F) = 1 word each, Tile Type listings for use in drawing dungeons
• 0x12D4A to 0x135AB (----) = Code
• 0x135AC to 0x135DB (----) = (0x30 entries, 1 byte each) unknown data indexed by $7E00A8
• 0x135DC to 0x139CB (----) = Code
• 0x139CC to 0x139DB (----) = unknown data
• 0x139DC to 0x13B87 (----) = Code
• 0x13B88 to 0x13B8F (----) = Bitmasks for the routine below it
• 0x13B90 to 0x13DBF (----) = Code
• 0x13DC0 to 0x13DC7 (----) = Data used for setting $0614 to $061B (----)

Normal Entrances: 0h = 84h Pointers to rooms for each entrance. So entrance number one points to the first word value in this array.

• 0x14813 (----) = $1491C (word values)

size = 10Ah

Recall, room numbers are 16 bits, typically ranging from 0-295. Expansion will hopefully bump that up to 320 total rooms (0-319)

Scroll Edges - unsure about what these do exactly

• 0x1491D to 0x14D44 (----)

size = 428h Each entry is 8 bytes long. Format: 1 byte each. Corresponds to hyrule magic values in the "More" aka Entrance Properties dialog box. HU, FU, HD, FD, HL, FL, HR, FR

Normal Entrance Y Scroll

• 0x14D45 to 0x14E4E (F) 2 bytes each

Normal entrance X Scroll

• 0x14E4F to 0x14F58 (F) 2 bytes each

Normal entrance Y Coordinates

This is where Link starts off at in the dungeon when he enters

• 0x14F59 to 0x15062 (----)

size = 10Ah 2 bytes each

Normal entrance X Coordinates

• 0x15063 to 0x1516C (----)

size = 10Ah 2 bytes each

Normal entrance X Camera Coordinates

• 0x1516D to 0x15276 (----)

Lower bounds for scrolling (upper bounds = this plus 2) size = 10Ah 6102 bytes each

Normal entrance Y Camera Coordinates

• 0x15277 to 0x15380 (----)

Lower bounds for scrolling (upper bounds = this plus 2) size = 10Ah 2 bytes each

Normal entrance Blocksets

• 0x15381 to 0x15405 (----)

size = 85h 1 byte each

Normal entrance Floor values This tells us what kind of properties the floor has. If 1, then it has floors that you can fall through to the next level If 0, I think it means it can be fallen down to If -1, has no pits If -2, ????

• 0x15406 to 0x1548A (84)

1 Byte each

Normal entrance Dungeon Values Dungeons actually in the game are numbered like so 0, 2, 4, ..., 18, 1A 1C and 1E are unused (and hence could potentially be added.) Notice they are all even numbers. In asm routines these values are divided by two sometimes to provide an index into other arrays. That's why. The definition of a "dungeon" is something with a key, compass, and map.

• 0x1548B to 0x1550F (84)

1 Byte each FF = -1 denotes it doesn't belong to a dungeon.

Normal Entrance Doorway Type Data This is used only when you exit the given room. For example, let's say you enter through a skull doorway in Skullwoods. But that's not really a door way, it's just a set of tiles that are no different from a hole you might create after picking up a big rock. But if you entered from a building door, the game has to know whether to put the door frame when you exit.

• 0x15510 to 0x15594 (84) 1 Byte each
  • 0 = no doorway when exiting
  • 1 = draws a door frame upon exiting
  • 2 = ????

HM says vertical doorframe. But in the original game, no doorway is vertical. It appears the designers may have intended doorways where you enter from the left or right... fits in well with my idea to implement that. And technically, I believe it should be the other way around. 1 should be vertical and 2 should be horizontal.

• 0x15595 to 0x15619 (84) = (1 byte each) Normal Entrance Ladder and BG Settings, with the following 2 bit layout
  • xxxaxxxb
  • x = unimportant
  • a = if set, then Link enters on the lower level (BG2)
  • b = if set... not sure what happens exactly. Check the game engine to be sure.

Normal Entrance Horizontal and Vertical Scroll Properties

• 0x1561A to 0x1569E (84) = For these, I guess if the flags in the appropriate places are set, then the room will be able to scroll in those directions. 1 byte each, with the following layout:

xxaxxxbx a = Horizontal flag b = Vertical flag

• 0x1569F to 0x15723 (84)

Normal Entrance Scroll Quandrant 1 byte each has four different expected values 0h, 2h, 10h, 12h Whether the HM interpretation of this is correct, I need to check.

• 0x15724 to 0x1582D (F) = Normal Entrance EXIT Door location
  • 1 word each. Denotes, um X and Y coordinates for overworld?

• 0x1582E (----) = same

See ZeldaFlow for more information on values under $012C

• 0x158B3 (----) = I assume these are sequencing variables to tell the camera where

to go? Writes to $0628 and $0629 (Ukn2 in HM)

• 0x16367 to 0x16404 (----) = (0x4F entries, 2 bytes each)}} = Door type setting 1. Writes to $0696 (See Zelda_RAM.log for in-

depth description) 0x0000: no change bmmmmmmm mmmmmmmm: (bit pattern) b}} = if set, it's a bombable exit, otherwise it's a wooden exit. m}} = (15-bit number) map16 address of the exit

• 0x16405 to 0x164A2 (----) = (0x4F entries, 2 bytes each)}} = Door type setting 2. Write to $0698.

0x0000: no change smmmmmmm mmmmmmmm: (bit pattern) s}} = if set, it's a palace exit, otherwise it's a sanctuary exit. m}} = (15-bit number) map16 address of the exit

• {{address|0x|164A3|166E0 Code

• {{address|0x|166E1|167E0

Size = 100h thingamajig with scroll ranges but for ending sequence too tired right now to do. 0x20 bytes per section. 1 byte per entry in each section. The sections are interlaced and are written like so: Section -> Address

• {{address|0x|166E1, Y -> $0600
• {{address|0x|16701, Y -> $0602
• {{address|0x|16721, Y -> $0604

618$16741, Y ->

• {{address|0x|16761, Y ->
• {{address|0x|167A1, Y ->
• {{address|0x|16781, Y ->
• {{address|0x|167C1, Y ->
• {{address|0x|0606
• {{address|0x|0610
• {{address|0x|0612
• {{address|0x|0614
• {{address|0x|0616

• {{address|0x|167E1|16800?

?????? 1 word each Gets written to $0708

• {{address|0x|16801|16850 Exit Data (the ones that warp between overworld areas)
• 0x16801 to 0x16810 (----) = Direction Link is facing when entering
• 0x16811 to 0x16820 (----) = Sprite graphics index for the new area.
• 0x16821 to 0x16830 (----) = Graphics index for the new area
• {{address|0x|16831|16840 -

• {{address|0x|16851|16AE4 Code

• {{address|0x|16AE5|16C38

Size = 154h Ending Sequence (again?) Each entry in all arrays is 1 word long.

• {{address|0x|16AE5|16B06

Ending Sequence Overworld Areas to load.

• {{address|0x|16B07|16B28

Ending Sequence VRAM locations for link.

• {{address|0x|16B29|16B4A

Ending Sequence Y Scroll Data

• {{address|0x|16B4B|16B6C

619Ending Sequence X Scroll Data

• {{address|0x|16B6D|16B8E

Ending Sequence Link Y Coordinate

• {{address|0x|16B8F|16BB0

Ending Sequence Link X Coordinate

• {{address|0x|16BB1|16BD2

Ending Sequence Camera Y Coordinate

• {{address|0x|16BD3|16BF4

Ending Sequence Camera X Coordinate

• {{address|0x|16BF5|16C16

Ending Sequence ????? Gets stored to $0624

• {{address|0x|16C17|16C38

Ending Sequence ????? Gets stored to $0628

• {{address|0x|16C39|16CF7 Code

• {{address|0x|16CF8|16D07

Size = 10h Overworld Whirlpool Locations 1 word each

• {{address|0x|16D08|16DC4 Code

• 0x16DC5 (----) = Crystal

Weathervane stuff Note: A word about overworld coordinates. The coordinate for 0,0 is at the top left corner OF THE WHOLE OVERWORLD (this applies to areas 0 through 0x7F, not the others). Just because you are looking at something in hyrule magic, doesn't mean that top left corner of that map section is (0,0). For example, look at the bird's coordinates below. Looking at it in Hyrule Magic, you'd assume that they are roughly the same, but area #$18 happens to be on the left edge of the map, whereas it is about 2-3 whole screens down in terms of Y position. Hence the bird's Y coordinate is about 4 times the size of it's X coordinate.

• 0x48CD5 to 0x48D10 (----) = Initial position data for the weathervane piece sprites (12 of them)
• {{address|0x|48CD5 ???
• {{address|0x|48CE1 ???
• 0x48CED (----) = 12 bytes. Lower Y coordinate for all 12 pieces
• 0x48CF9 (----) = 12 bytes. Lower X coordinate for all 12 pieces
• {{address|0x|48D05 ???
• 0x48D65 (----) = 1 byte. Upper Y coordinate byte for all 12 pieces. Normally #$07
• 0x48D72 (----) = 1 byte. Upper X coordinate byte for all 12 pieces. Normally #$02

Caution: edits to these must be exact and careful, because they are embedded in code. Or rather, they are actually part of the code itself.

• {{address|0x|48DC2 16bit Y coordinate for the bird to initialize to. Normally #$0788
• {{address|0x|48DC7 16bit X coordinate for the bird to initialize to. Normally #$0200
• 0x3A425 (----) = 1 byte. Overworld area to use with the weathervane. Normally this reads #$18. Make sure to use hex.
• 0x3A42C (----) = 2 bytes. Overworld Y coordinate lower boundary for triggering the weather vane. Normally reads #$0760
• 0x3A431 (----) = 2 bytes. Overworld Y coordinate upper boundary " ... Normally reads #$07E0
• 0x3A438 (----) = 2 bytes. "

X " lower " " ... Normally reads #$01CF

• 0x3A43D (----) = 2 bytes. "

X " upper boundary " ... Normally reads #$0230 ^So basically that defines a square that is $60 by $80 pixels, that serves as a trigger location, given the right conditions. Edit these to your heart's content.

• 0x4C635 to 0x4C6F4 (----) = Overworld widths of areas?

size = 0xC0 bytes, one per Overworld area values of either 0x04 or 0x02 626 "Beginning" corresponds to values of $7EF3C5 of 0 or 1. "First Part" corresponds to a value of $7EF3C5 at 2. "Second Part" corresponds to values of $7EF3C5 at 3.

• 0x4C881 to 0x4C900 (----) = Array of pointers to OVERWORLD sprite and overlord information, for "Beginning" mode.

It has information for ONLY areas $0|3F. (Notice that means light world, and hence why Dark World enemies use light world enemies if you warp there during the beginning. They're reading the wrong data. In fact, it's Light world "First Part" data that it is inadvertently reading. The sprite / overlord information comes in 3 byte clusters. The game reads until it spots a $FF byte. (The $FF after the last cluster) Since the overworld utilizes a sprite map, there can be many more than 16 sprites in memory in one overworld area. They are killed off and created as they come into view. First Byte: Y coordinate, which will be converted into pixel units later. Second Byte: X coordinate, which will be converted into pixel units later. Third Byte: Sprite or Overlord type. If a sprite, this will get loaded into a slot at $0E20, X. If an Overlord, will get loaded to $0B00, X. This operates a bit differently from Dungeon overlords and sprites. Any value greater than or equal to $F3 will be considered an Overlord. $F3 is then chopped off of that value and used as the Overlord index.

• 0x4C901 to 0x4CA20 (----) = Array of pointers to Overworld sprite and overlord information, for "First Part" mode.

Basically the same as the array above, but for a later point in the game.

• 0x4CA21 to 0x4CB40 (----) = Array of pointers to Overworld sprite and overlord information, for "Second Part" mode.

Basically the same as the array above, but for a later point in the game.

• 0x4D62E to 0x4D92E (----) = Array of pointers to DUNGEON sprite and overlord information. Pointers are local, and each room has

a listing of sprites. They are in order of rooms. size = 300h Each entry is 2 bytes long. NOTE: Interesting to note that this pointer list seems to have space for $180 rooms, whereas the built in limit is $128. That's the first I've seen of an allocated array in the rom being larger than necessary. O_o. Layout of these listings: First Byte: Stored to $0FB3. Not sure what the purpose of that is yet. 627After the first byte, you will see 3 byte clusters that break down thus: First Byte: 7 6 5 4 3 2 1 0 | | | | | | | | | | | \--+--+--+--+-- Y coordinate (in pixels from the top, starting at 0) of the sprite divided by 16. | | | | \--+-------------- If these are set, they will be used to generate a subtype, stored to $0E30, X. | \--+--+----------- If set, the sprite is on BG2, if not it's on BG1 Second Byte: 7 6 5 4 3 2 1 0 | | | | | | | | | | | \--+--+--+--+-- X coordinate (in pixels from the far left, starting at 0) of the sprite divided by 16. | | | \--+--+----------- If all these bits are set then this is an Overlord, otherwise it's a normal sprite. If only some of them are set they can be used to generate a subtype, stored at $0E30, X Third Byte: Sprite or Overlord type. If a sprite, this will get loaded into a slot at $0E20, X. If an Overlord, will get loaded to $0B00, X. The array is terminated with a byte of $FF.

Sprite Statistics. All of the following arrays are $F3 bytes long (as expected, since there are $F3 different sprite types).

• 0x6B080, X (----) = ??? Gets stored to $0E40, X.
• 0x6B173, X (----) = Initial HP for all sprites. Gets stored to $0E50, X
• 0x6B266, X (----) = Amount of damage the sprite can cause to Link.
• 0x6B359, X (----) = Possibly a main palette index. Stored to $0E60, X
• {{address|0x|6B4CC, X -
• {{address|0x|6B8F1[0x???]
• 0x70000 to 0x70FFF (----) = BG3 VWF graphics (uncompressed)

View this area in a tile editor and you'll see the text characters for the VWF.

• 0x74703 to 0x747C6 (----) = Pointers for dictionary entries. (Start point and upper bound)
• 0x75460 (----) = location of palette indices (grouped in 4's)

These get mapped to $0AB6, $0AAC, $0AAD, and $0AAE respectively.

• 0x78000 (----) = Map16 to Map8 conversions (comes in groups of 8 bytes, 4 Map8 tiles each)

628*

• 0x7902A (----) = ??? Gets mapped to $7EFF40 to $7EFFBF
• 0x80000 to 0x86FFF (----) = 4bpp graphics sets for all of Link's animations
• 0x87000 to 0x8B7FF (----) = 3bpp graphics sets (uncompressed)

3bpp?

• 0xC0D64 (----) = location of compressed graphics for action sprites, (shields and shovel)

2bpp

• 0xC2F0D (----) = location of compressed graphics for the menu screen,

and overlaps with graphics for the dungeon map screen. (includes text for items, and the map icon) 2bpp

• 0xC3520 (----) = location of compressed graphics for the menu screen (bug catching net, medallions, etc)

2bpp

• 0xC3953 (----) = location of compressed graphics for the menu screen (magic mirror, book of mudora, etc)
• 0xDB800 to 0xDB85F (----) = Hole Data
• 0xDB800 to 0xDB825 (----) = (0x13 entries, 2 bytes each) modified (less 0x400) map16 coordinates for each hole
• 0xDB826 to 0xDB84B (----) = (0x13 entries, 2 bytes each) corresponding area numbers for each hole
• 0xDB84C to 0xDB85F (----) = (0x13 entries, 1 byte each) corresponding entrance numbers

!*

• {{address|0x|DB860|DB8BE Code

!*

• {{address|0x|DB8BF|DBBF3 Overworld accessible entrances (other entrances are accessible via other methods, like game startup)
• 0xDB8BF (0x2C entries, 2 bytes each) (----) = valid map8 (CHR) values for entrances (left side)
• 0xDB917 (0x2C entries, 2 bytes each) (----) = valid map8 (CHR) values for entrances (right side)
• 0xDB96F (0x81 entries, 2 bytes each) (----) = area numbers for each entrance
• 0xDBA71 (0x81 entries, 2 bytes each) (----) = map16 coordinates for each entrance
• 0xDBB73 (0x81 entries, 1 byte each) (----) = entrance numbers (ranging from 0x00 to 0x84)

!* 629$DBBF4|DBF4B Code

• {{address|0x|DBF4C|DBF63 Data (unknown type)
• {{address|0x|DBF64|DC2F8 Code

!*

• 0xDC2F9 to 0xDC8A3 (----) = Overworld Secrets (Item) Data
• 0xDC2F9 to 0xDC3F8 (----) = Local pointer table (2 bytes, 0x80 entries) to the data for each Area
• 0xDC3F9 to 0xDC89B (----) = The actual data, each entry being 3 bytes.

The first two bytes are the map16 coordinate for the secret. The last byte is the value of the secret. Valid values are 0x00 to 0x16, and 0x80, 0x82, 0x84, 0x86, 0x88

• 0xDC89C to 0xDC8A3 (4 entries, 2 bytes each) (----) = replacement map16 values. E.g. a hole secret would have a hole map16 as

the replacement Note: Areas 0x80 and above don't have items.

• {{address|0x|DC8A4|?????

• 0xE0000 to 0xE7F29 (----) = Text / Dialogue Data

(see also $76E20 for a bit more text data in this same format) Some quick notes: the text box is 0x15 tiles (horiz.) by 0x06 tiles (vert.) Each tile consists of 0x10 bytes, as they are 2bpp. Characters:

• {{address|0x|0 to $19: 'A' through 'Z'
• {{address|0x|1A to $33: 'a' through 'z'
• {{address|0x|34 to $3D: '0' through '9'
• {{address|0x|3E:

'!'

• {{address|0x|3F:

'?'

• {{address|0x|40:

'-'

• {{address|0x|41:

'.'

• {{address|0x|42:

','

• {{address|0x|43:

'...'

• {{address|0x|44:

|> (arrow pointing right)

• {{address|0x|45:

'('

• {{address|0x|46:

')'

• {{address|0x|47:

Ahnk (used in Hylian script) 630$48: three waves (used in Hylian script)

• {{address|0x|49:

snake? (used in Hylian script)

• {{address|0x|4A:

picture of Link's head in the kidnapper signs (left half)

• {{address|0x|4B:

picture of Link's head in the kidnapper signs (right half)

• {{address|0x|4C:

'"' (left orientation)

• {{address|0x|4D:

small arrow pointing up

• {{address|0x|4E:

small arrow pointing down

• {{address|0x|4F:

small arrow poitning left

• {{address|0x|50:

small arrow pointing right

• {{address|0x|51:

(apostrophe)

• {{address|0x|52:

heart piece upper left filled (just left side)

• {{address|0x|53:

heart piece empty (just right side)

• {{address|0x|54:

heart piece left filled (just left side)

• {{address|0x|55:

heart piece 3/4 filled (just left side)

• {{address|0x|56:

heart piece upper right filled (just right side)

• {{address|0x|57:

heart piece all filled (just left side)

• {{address|0x|58:

heart piece all filled (just right side)

• {{address|0x|59:

space (as in  )

• {{address|0x|5A:

<| (arrow pointing left)

• {{address|0x|5B:

'A' in bold. (indicates the A button)

• {{address|0x|5C:

'B' in bold. (indicates the B button)

• {{address|0x|5D:

'X' in bold. (indicates the X button)

• {{address|0x|5E:

'Y' in bold. (indicates the Y button)

• {{address|0x|5F:

alternate "l" or "I"? (apparently not used)

• {{address|0x|60:

alternate "!" (apparently not used)

• {{address|0x|61:

upside down "!" (apparently not used)

• {{address|0x|62 to $65: apparently tab characters or space characters? (apparently not used)
• {{address|0x|66:

strange red and white '.' (apparently not used) Commands: as)

• {{address|0x|67 [NextPic] command
• {{address|0x|68 [Choose] command
• {{address|0x|69 [Item] command (for waterfall of wishing)
• {{address|0x|6A [Name] command (insert's player's name)
• {{address|0x|6B [Window XX] command (takes next byte as argument)
• {{address|0x|6C [Number XX] command (takes next byte as argument)
• {{address|0x|6D [Position XX] command (takes next byte as argument)
• {{address|0x|6E [ScrollSpd XX] command (takes next byte as argument)
• {{address|0x|6F [SelChng] command
• {{address|0x|70 [Crash] command (obviously that's probably not what it's intended to do but that's what HM lists it
• {{address|0x|71 [Choose2] command
• {{address|0x|72 [Choose3] command
• {{address|0x|73 [Scroll] command
• {{address|0x|74 [1] command (aka [Line1])
• {{address|0x|75 [2] command (aka [Line2])
• {{address|0x|76 [3] command (aka [Line3])
• {{address|0x|77 [Color XX] command (takes next byte as argument)
• {{address|0x|78 [Wait XX] command (takes next byte as argument)
• {{address|0x|79 [Sound XX] command (takes next byte as argument)
• {{address|0x|7A [Speed XX] command (takes next byte as argument)

631these. Ever) (this will be the Black Magic syntax for the following three codes. simple eh? Do NOT use

• {{address|0x|7B [Command 7B]
• {{address|0x|7C [Command 7C]
• {{address|0x|7D [Command 7D]
• {{address|0x|7E [Waitkey] command
• {{address|0x|7F stop command (ends the whole message)
• {{address|0x|80 signals to switch to the second set of text data (much saller)
• {{address|0x|81|87 unused (don't use these!)
• 0x88 (----) = ??? Dictionary encoding bytes. Represents longer strings
• 0xF4EBC (----) = Message IDs for Maidens

-- fill in later.

• 0x---- (----) = If this byte is >= 0xF8 and < 0xFC, then it is a subtype 3 object.

- If the index is >= FC, it is a subtype 2 object. If not, it is a subtype 1 object. Subtype 1 Objects ------------------------------------------------------ First and Second Byte: High Byte yyyy yycc Low Byte xxxx xxaa The a bits are stored to $B2 The c bits are stored to $B4 The x and y bits are transformed into: 000y yyyy yxxx xxx0 This is a tilemap address that indexes into $7E2000 and / or $7E4000 Use the third byte * 2 as an index into the table at $8200 This is the routine that is used to draw and otherwise handle the object. Subtype 1 objects have a maximum width and height of 4. width and height are measured in terms of 32 x 32 pixels. (<-- last part is questionable) Subtype 2 Objects ------------------------------------------------------ Subtype 2 objects are those with an index >= 0xFC 1st, 2nd, & 3rd bytes: Bank Byte High Byte Low Byte ffdd dddd eeee cccc aaaa aabb The a bits are unused, but after all they are the marker for this type of object subtype. The b, c, e, and f bits are transformed into a VRAM tilemap address: 000c cccf fbbe eee0 Might I add this is one messed up format? The d bits are used as an index into the table at $8470. Since such indicies are going to be even, the d bits are transformed into: 0000 0000 0ddd ddd0

Subtype 3 Objects ------------------------------------------------------

Similar to Subtype 1, with a few small exceptions. The vram address is calculated the same way. However, $B2 and $B4 are not used as length or width dimensions here. The routine that is used is determined as follows: Take the original index (times two) that a Subtype 1 would have used. AND that with 0x000E. Then shift left 3 times to produce 0000 0000 0eee 0000. Then, OR in $B2 and $B4 and shift left once, so the final result is: 0000 0000 eeea abb0. Also, this value indexes into $85F0 instead of $8200. 633Type 2 Object Structure: (2 bytes) High Byte Low Byte cccc cccc bbbb ddaa The a bits form a 2-bit value (0000 0aa0) that determines the routine to use for the object. In Hyrule Magic, corresponds to the "direction" of the door. The b bits are transformed into 000b bbb0 and stored to $02 -> X. Corresponds to "Pos" of door objects in the Hyrule Magic. Note that these range from 0x00 to 0x16 (always even) which if you halve those values is 0 = 11 in decimal. This is easily verifiable in Hyrule Magic. The c bits are shifted into the lower byte and stored to $04 -> A and $0A. This is later used to grab the tiles used to draw the door and the area below it. In Hyrule Magic, corresponds to "type". Note the type is 1/2 of the number listed here. This is because to avoid using an ASL A command, the c bits are always even. The d bits are unused. Next I'll go into the nitty gritty of the various types (the value of $04). Again note that we'll only be dealing with even values b/c that's what you'll see in the code. To convert between here [as well as the code] and Hyrule Magic, take the hex value here and divide by two. Convert to decimal and that's your Hyrule Magic "type." Types:

• 0x00 = Basic door. Index = $0460
• 0x02 = Normal door?
• 0x04 = ???
• 0x06 = ???
• 0x08 = Waterfall door (only used in Swamp palace; in one room at that!)
• 0x0A = ???
• 0x0C = Trap door (probably other types but this seems to be most common)
• 0x12 = Adds a property to some doors allowing you to exit to the overworld (this is accomplished by writing to the tile attribute map)
• 0x14 = Transition to dark room?
• 0x16 = Toggles the target BG Link will emerge on. e.g. if Link starts on BG0 in the next room he'll be on BG1.
• 0x20 = Locked door specifically for BG0.
• 0x22 = Locked door specifically for BG0.
• 0x24 = Locked door for either BG0 or BG1
• 0x26 = Locked door for either BG0 or BG1
• 0x30 = Large exploded pathway resulting from a switch being pulled (unusual to have as a door as it's huge)
• 0x32 = Sword activated door (e.g. Agahnim's room with the curtain door you have to slash)
• 0x46 = warp door?

• 0xF83C0 (----) = Loaded when the header is loaded for each dungeon room. These appear to be the direct offset to where the door objects appear. The normal objects and the door objects are separated by the byte sequence $FFF0. Apparently the offsets in this set are just there for convenience?