Underworld:Important Hex Addresses

This is a subpage of Underworld

Room Data

Room Headers

• $027502 to $027781 = Pointer Table, 2 byte local addresses, indexed by room ID.
• $027781 to $027FEF = Data

Headers are $0E (Decimal: 14) bytes formatted thusly:

• Byte 0: aaab bbcd
  • The a bits are transformed into 0000 0aaa and stored to $0414 ("BG2" in Hyrule Magic)
  • The b bits are transformed into 0000 0bbb and stored to $046C ("Collision" in Hyrule Magic)
  • The c bit is unused
  • The d bit is stored to $7EC005 (If set, use a lights out routine in the room transition)

• Byte 1: aabb bbbb
  • The a bits are unused
  • The b bits are transformed into bbbb bb00, thus making them a multiple of 4.

This value is used to load 4 different palettes for the dungeon, and corresponds to, you guessed it, Palette # in Hyrule Magic!

The resulting index is used to load values for $0AB6, $0AAC, $0AAD, and $0AAE

• Byte 2: gets stored to $0AA2 (GFX # in Hyrule Magic)
• Byte 3: value + #$40 gets stored to $0AA3 (Sprite GFX # in Hyrule Magic)
• Byte 4: gets stored to $00AD ("Effect" in Hyrule Magic)
• Byte 5: aabb bbbb
  • a = ?
  • The b bits are "Tag1" in Hyrule Magic and gets stored to $00AE.
• Byte 6: aabb bbbb
  • a = ?
  • The b bits are "Tag2" in Hyrule Magic and get stored to $00AF

These are the planes to use for bytes 9 through D. This determines which BG you appear on, and possibly more.

• Byte 7: aabb ccdd
  • The a bits are transformed into 0000 00aa and stored to $063F
  • The b bits are transformed into 0000 00bb and stored to $063E
  • The c bits are transformed into 0000 00cc and stored to $063D
  • The d bits are transformed into 0000 00dd and stored to $063C

Note, the only safe values for a plane seem to be 0,1, or 2. Hyrule Magic appears to violate this rule by letting you put 3 down, but nothing higher.

• Byte 8: aaaa aabb
  • The a bits are unused
  • The b bits are transformed into 0000 00bb and stored to $0640

• Byte 9: stored to $7EC000 These are all room numbers that you could possibly exit to.
• Byte A: stored to $7EC001
• Byte B: stored to $7EC002
• Byte C: stored to $7EC003
• Byte D: stored to $7EC004

Sprite Data

• $04D62E to $04D92E = Pointer Table, 2 byte local addresses, indexed by room.
• $04D92E to $04EC9D = Data

Sprite data is formatted thusly:

• Byte 0: Stored to $0FB3. Corresponds with "Sort Spr" in Hyrule Magic. In a layered room this indicates sprites in the foreground are to be drawn on top of sprites in the background.
  • Bit 0 - If 0, sprites will sort
  • Bits 7,6,5,4,3,2,1 - Unknown, should all be 1

After the byte 0, you will see 3 byte clusters that break down thus:

• Byte 0:
  • Bits 4,3,2,1,0 - Y coordinate (in pixels from the top, starting at 0) of the sprite divided by 16.
  • Bits 6,5 - If these are set, they will be used to generate a subtype, stored to $0E30, X.
  • Bit 7 - If set, the sprite is on BG2, if not it's on BG1
• Byte 1:
  • Bits 4,3,2,1,0 - X coordinate (in pixels from the far left, starting at 0) of the sprite divided by 16.
  • Bits 7,6,5 - 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
• Byte 2: 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.

Object Data

Data location

• $0F8000 to $0F83BF = Pointer Table, 3 byte long addresses, indexed by room ID.
• $01EBA0 to $01FFF4 = Data
• $050000 to $053729 = Data
• $0F8780 to $0FFF4D = Data

Byte layout

• Byte 0: aaaa bbbb.
  • The a bits are transformed to aaaa0000 and select the type of empty space to fill in. Hyrule Magic calls this 'Floor 1' - Gets stored to $7E0490
  • The b bits are transformed to bbbb0000 and are the what Hyrule Magic calls 'Floor 2' - Gets stored to $7E046A

• Byte 1: aaab bbcd
  • The a bits are unused and should not be used
  • The b bits determine the room's layout type, ranging from 0 to 7.
  • The c and d bits are unknown, but I have a feeling it's related to $AA and $A9

After that the bytes come in 3 or 2 byte object structures, used by routine $01:88E4. Objects are loaded until an object with value 0xFFFF occurs. If a value 0xFFF0 is loaded, the game will start loading Type 2 objects and will not go back to loading Type 1 objects until it is time to load the next layer. (Layer as in HM, not to be confused with the SNES' Backgrounds.) A value of 0xFFFF will also terminate the loading of Type 2 objects. The routine immediately terminates if that happens during the loading of either object type.

Type 1 Object structure: (3 bytes)

• Byte 3: Routine to use. 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 Byte 3 * 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 ‍×​ 32 pixels. (⟸ last part is questionable)

Subtype 2 Objects, 1st, 2nd, & 3rd bytes

• • Byte 3: ffdd dddd
  • Byte 2: eeee cccc
  • Byte 1: 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 indices 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.

Type 2 Object Structure: (2 bytes)

• High Byte: cccc cccc
• Low Byte: 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:

ID	Description
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. Ex. if Link starts on BG0 in the next room he'll be on BG1.
0x20	Locked door specifically for BG0.
0x22
0x24	Locked door for either BG0 or BG1
0x26
0x30	Large exploded pathway resulting from a switch being pulled (unusual to have as a door as it's huge)
0x32	Sword activated door. Ex. Agahnim's room with the curtain door you have to slash.
0x46	warp door?

</blockquote>

Dungeon Secrets Data

• $00DB69 to $00DDE8 = Pointer Table, 2 byte local addresses, indexed by room ID.
• $00DDE9 to $00E6B1 = Data

Data comes in 3 byte chunks and is terminated by an instance of $FFFF

• Bytes 0, 1: A word that denotes the VRAM address that the item is found at. This identifies the item as belonging to that part of the screen.
• Byte 2: Identifies the type of item that is hiding there. E.g. $08 is a key

Push Block Data

The block data has three primary pointer locations. The pointer is stored as a long address.

Primary pointer location

USA	JP	GER
0x15AFA, 0x15B01, 0x15B08, 0x15B0F	0x1585E, 0x15865, 0x1586C, 0x15873	0x15B7C, 0x15B83, 0x15B8A, 0x15B91

The data has a total max in little endian at:

Total max location

USA
0x8896 (2)

• In the USA version, the data is located at $0271DE to $027369.

4 bytes per entry: a a x y

• a: Room number (byte swapped)
• x: X Position of the block (expressed as tilemap coordinate)
• y: Y Position of the block (expressed as tilemap coordinate)

(Inter Room) Torch Data

The torch data has three primary pointer locations. The pointers are stored as a long address.

Primary pointer location

USA	JP	GER
0x15B16, 0x15B1D, 0x15B24	0x1587A, 0x15881, 0x15888	0x15B98, 0x15B9F, 0x15BA6

• In the USA version, the data goes from 0x2736A to 0x27489.

Consists of variable length segments consisting of:

a a x y x y ... $FFFF

• a: Room number (byte swapped)
• x: X Position of the torch (expressed as tilemap coordinate)
• y: Y Position of the torch (expressed as tilemap coordinate)
• $FFFF: Delimeter

Chest Contents

The chest contents have three primary pointer locations. The values at each location point to the same pointer. Yes, you read that right. The pointer is stored as a long address.

Primary pointer location

USA	JP	GER
0xEBFB, 0xEC0A, 0xEC10	0xEC08, 0xEC17, 0xEC26	0xEBD5, 0xEBE4, 0xEBF3

The addresses below contain the size limit for the data for each region:

Max Size

USA	JP	GER
0xEBF6	0xEBF4	0xEBD0

• In the original USA version the data goes from $00E96E to $00EB65.

Array of chest information in 3 byte chunks. 168 entries in all (0xA8)

• First word - Room number it is located in. MSB determines whether it is a big chest or not. (big chest if set)
• Last byte - index of the type of item contained in the chest.

Room layout

In Hyrule Magic, there's a label and textbox for room layouts. The layout value goes from $0 to $7

The location:

USA	JP
0x26F2F	0x26C0F

In the aforementioned location, there are 8 long pointers (Lo-Hi-Bank).

Entrance Data

There are $85 (Decimal: 133) normal entrances to the underworld from the overworld, and $7 (Decimal: 7) starting locations. Normal entrances and starting locations use mostly the same types of data formatted the same, however they are located in different places in the ROM. They are located and formatted thus:

Entrance Room

• $014813 to $01491C = Normal Entrance Data
• $015B6E to $015B7B = Starting Location Data

Each entry is a 2 byte Room ID where the player is placed after using an entrance.

Scroll Edges

• $01491D to $014D44 = Normal Entrance Data
• $015B7C to $015BB3 = Starting Location Data

Unsure about what these do exactly. Each entry is 8 bytes long.

• Format: 1 byte each. Corresponds to hyrule magic values in the "More" a.k.a. Entrance Properties dialog box.
  • HU -
  • FU -
  • HD -
  • FD -
  • HL -
  • FL -
  • HR -
  • FR -

X Scroll

• $014D45 to $014E4E = Normal Entrance Data
• $015BB4 to $015BC1 = Starting Location Data

Y Scroll

• $014E4F to $014F58 = Normal Entrance Data
• $015BC2 to $015BCF = Starting Location Data

X Coordinate

• $014F59 to $015062 = Normal Entrance Data
• $015BD0 to $015BDD = Starting Location Data

Each entry is a 2 byte X coordinate where the player starts after using the corresponding entrance.

Y Coordinate

• $015063 to $01516C = Normal Entrance Data
• $015BDE to $015BEB = Starting Location Data

Each entry is a 2 byte y coordinate where the player starts after using the corresponding entrance.

X Camera Coordinate

• $01516D to $015276 = Normal Entrance Data
• $015BEC to $015BF9 = Starting Location Data

Lower bounds for scrolling (upper bounds = this plus 2) 2 bytes each.

Y Camera Coordinate

• $015277 to $015380 = Normal Entrance Data
• $015BFA to $015C07 = Starting Location Data

Lower bounds for scrolling (upper bounds = this plus 2) 2 bytes each.

Entrance Blockset

• $015381 to $015405 = Normal Entrance Data
• $015C08 to $015C0E = Starting Location Data

1 byte each. This blockset affects walls and a few other things and persists through all rooms the player accesses from this entrance.

Floor Values

• $015406 to $01548A = Normal Entrance Data
• $015C0F to $015C15 = Starting Location Data

This tells us what kind of properties the floor has. 1 byte each:

• 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, ????

Dungeon Values

• $01548B to $01550F = Normal Entrance Data
• $015C16 to $015C1C = Starting Location Data

1 Byte each. Dungeons actually in the game are numbered like so $00, $02, $04, ..., $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.

A value of $FF (-1) denotes it doesn't belong to a dungeon.

Doorway Type

• $015510 to $015594 = Normal Entrance Data
• $015C2B to $015C31 = Starting Location 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.

• 1 byte:
  • 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.

Ladder And BG Settings

• $015595 to $015619 = Normal Entrance Data
• $015C1D to $015C23 = Starting Location Data

• 1 byte each, 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.

Horizontal And Vertical Scroll Properties

• $01561A to $01569E = Normal Entrance Data
• $015C24 to $015C2A = Starting Location Data

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

Scroll Quadrant

• $01569F to $015723 = Normal Entrance Data

• 1 byte each, has four different expected values:
  • 0h, 2h, 10h, 12h

Exit Door Location

• $015724 to $01582D = Normal Entrance Data
• $015C32 to $015C3F = Starting Location Data

1 word each. Denotes X and Y coordinates for overworld?

Music

• $01582E to $0158B2 = Normal Entrance Data (JP: 15592 - 15616)
• $015C4E to $015C54 = Starting Location Data

1 byte each. A value of $FF plays the same music as the overworld screen from which the player entered.

Entrance Values

• $015C40 to $015C4D = Starting Location Data

1 word each. Since the starting locations have to reference an entrance, this is necessary.