Difference between revisions of "Underworld"

Revision as of 05:16, 8 September 2016

The underworld refers to all indoor locations; including dungeons, caves, and houses.

Important Hex Addresses

Room Headers

• $027502-$027781 - Pointer Table, 2 byte local addresses, indexed by room ID.
• $027781-$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: gets stored to $00AE ("Tag1" in Hyrule Magic)

• byte 6: gets stored to $00AF ("Tag2" in Hyrule Magic)

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-$04D92E - Pointer Table, 2 byte local addresses, indexed by room.
• $04D92E-$04EC9D - Data

Sprite data is formatted thusly:

• First Byte: Stored to $0FB3. Not sure what the purpose of that is yet.

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

• First Byte:
  • 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

• Second Byte:
  • 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

• 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.

Object Data

• $0F8000-$0F83BF - Pointer Table, 3 byte long addresses, indexed by room ID.

Byte layout:

• byte0: 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

• byte1: 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):

• Third Byte: 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 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, 1st, 2nd, & 3rd bytes:
  • Third Byte: ffdd dddd
  • Second Byte: eeee cccc
  • First Byte: 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:
  • 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 - "
  • 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 (e.g. Agahnim's room with the curtain door you have to slash)
  • 0x46 - warp door?

Dungeon Secrets Data

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

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

• First two bytes: 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.
• Third byte: identifies the type of item that is hiding there. e.g. $08 is a key

Push Block Data

• $0271DE-$027369 - Data

4 bytes per entry

• 1st word: Room that the block exists in.
• 2nd word: Position of the block (expressed as tilemap coordinate)

(Inter Room) Torch Data

• $02736A-$027489 - Data

Consists of variable length segments consisting of:

• 1st word: Room that the torches belong in
• After this is a series of words, each one being a tilemap address for a torch.

This list of torches is terminated by the word value 0xFFFF

Chest Contents

• $00E96E - $00EB65 - Data

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.

Rooms

Main Map

The main underworld map consists of $FF (decimal: 256) rooms.

Secondary Map