Level Data Format

From Super Mario World Speedrunning Wiki
Jump to: navigation, search

LM-related information is accurate as of version 2.51.

Pointer Tables

Address Description Format
$05E000 Layer 1 data 0x200 levels, 3 bytes each (1,536 bytes)
$05E600 Layer 2 data 0x200 levels, 3 bytes1 each (1,536 bytes)
$05EC00 Sprite data 0x200 levels, 2 bytes2 each (1,024 bytes)

1 In the original SMW, if the long byte of the Layer 2 pointer is 0xFF, it will be replaced by 0x0C and the data will be interpreted as a BG tilemap rather than object data. Lunar Magic changes this so full 24-bit addresses are used either way; see the section on background data for more details.
2 In the original SMW, all sprite data is in bank 7. Lunar Magic adds a 512-byte table for the bank byte at $0EF100.


Primary Level Header

The first five bytes of object data for Layer 1 is the primary level header, which dictates various information about the level. Layer 2 object data also contains this header, but it is skipped over and ignored.

Format
BBBLLLLL CCCOOOOO 3MMMSSSS TTPPPFFF IIVVZZZZ
BBB BG palette
LLLLL Length of level (number of screens, -1)
CCC Back area color
OOOOO Level mode
3 Layer 3 priority
MMM Music
SSSS Sprite GFX setting
TT Timer setting
PPP Sprite palette
FFF FG palette
II Item memory setting
VV Vertical scroll setting
ZZZZ FG/BG GFX setting


Secondary Level Header

The secondary level header consists of four bytes, spread across four seperate tables with one byte per level. Lunar Magic adds a fifth byte as well, at $05DE00.

Format
$05F000 $05F200 $05F400 $05F600 $05DE001
SSSSyyyy 33AAAxxx MMMMFFBB IUVEEEEE LWPYX---
SSSS Layer 2 scroll setting
(Y)yyyy Level entrance Y position2
33 Layer 3 setting
AAA Level entrance Mario action
(X)xxx Level entrance X position2
MMMM Midway entrance screen number
FF FG initial position
BB BG initial position
I Disable No-Yoshi Intro flag
U Unknown/unused vertical position flag
V Vertical positioning flag
EEEEE Level entrance screen number
L Slippery flag1
W Water flag1
P Flag to use X/Y position method 21

In vertical levels, the X and Y position values are swapped.

1 Added by Lunar Magic; not used in the original game.
2 The capitalized Y and X bits are added by Lunar Magic when using X/Y position method 2, but are unused in the original game.


Midway Entrances

Lunar Magic also adds similar data for midway entrances when they're set to have seperate settings. This data is stored in a dynamically-located set of tables, however; they can be found in order at read3(read3($05D9E4)+$0A).

Format
Table 1 Table 2 Table 3
LWIMYAAA yyyyXXXX ----FFBB
L Slippery flag
W Water flag
I Flag to use seperate midway entrance (only the M bit is used otherwise)
M Bit 5 of midway screen number
Yyyyy Midway entrance Y position
AAA Midway entrance Mario action
XXXX Midway entrance X position
MMMM Midway entrance screen number
FF Midway FG initial position
BB Midway BG initial position
---- Currently unused


Sprite Header

The first byte of sprite data is the sprite header, which handles some miscellaneous sprite-related information.

Format
SBMMMMMM
S Sprite buoyancy1
B Sprite buoyancy (disable sprite-Layer 2 interaction)
MMMMMM Sprite memory2

1 Sprite buoyancy is a pair of flags that controls how sprites interact with water or lava. It is required for some sprites to behave correctly. Enabling this can cause lag if too many sprites are onscreen at once. Disabling Layer 2 interaction can mitigate this lag.
2 Although values up to #$3F are possible, only up to #$12 are actually intended for use.

Object Data

Object data is used to define Layer 1 and Layer 2 foreground data. The Z order of the objects is determined by the order they're written; an object earlier in the data, for instance, will appear below an object written later.

The data consists of a five byte header, followed by a list of all the objects. If the first byte of an object is #$FF, it indicates the end of the data has been reached.

The "new screen" flag described in most of the below formats increases the high X position of it and all following objects by one. In order to decrease it or increase it by a larger amount, a screen jump must be used.


Standard Objects

Standard objects are 3 bytes long. The 'settings byte' usage varies depending on the object, but generally specifies the height and width of the object.

Format
NBBYYYYY bbbbXXXX SSSSSSSS
N New Screen flag
BBbbbb Standard object number
YYYYY Y position
XXXX X position
SSSSSSSS Settings

In vertical levels, the X and Y position values are swapped.

Standard Object List
ID Object name Settings byte usage
00 (Extended Objects) Extended object ID
01 Water (Blue) Height Width
02 Invisible coin blocks Height Width
03 Invisible note blocks Height Width
04 Invisible POW coins Height Width
05 Coins Height Width
06 Walk-through dirt Height Width
07 Water (Other color) Height Width
08 Note blocks Height Width
09 Turn blocks Height Width
0A Coin ? blocks Height Width
0B Throw blocks Height Width
0C Black piranha plants Height Width
0D Cement blocks Height Width
0E Brown blocks Height Width
0F Vertical pipes Height Type
10 Horizontal pipes Type Width
11 Bullet shooter Height Unused
12 Slopes Height Type
13 Ledge edges Height Type
14 Ground ledge Height Width
15 Midway/Goal point Height Type
16 Blue coins Height Width
17 Rope/Clouds Type Width
18 Water surface (ani) Height Width
19 Water surface (not ani) Height Width
1A Lava surface (ani) Height Width
1B Net top edge Height Width
1C Donut bridge Unused Width
1D Net bottom edge Height Width
1E Net vertical edge Height Type
1F Vert. Pipe/Bone/Log Height Unused
20 Horiz. Pipe/Bone/Log Unused Width
21 Long ground ledge Width
22 LM - Direct Map16 page 0 Special handling
23 LM - Direct Map16 page 1 Special handling
24 LM - Old FG/BG/SP bypass Special handling
25 LM - Old AN2 bypass Special handling
26 LM - Music bypass Special handling
27 LM - Direct Map16 object Special handling
28 LM - Time limit bypass Special handling
29 LM - Reserved N/A
2A LM - Reserved N/A
2B LM - Reserved N/A
2C LM - Reserved N/A
2D LM - Reserved N/A
2E Tileset Specific 1 Various
2F Tileset Specific 2 Various
30 Tileset Specific 3 Various
31 Tileset Specific 4 Various
32 Tileset Specific 5 Various
33 Tileset Specific 6 Various
34 Tileset Specific 7 Various
35 Tileset Specific 8 Various
36 Tileset Specific 9 Various
37 Tileset Specific 10 Various
38 Tileset Specific 11 Various
39 Tileset Specific 12 Various
3A Tileset Specific 13 Various
3B Tileset Specific 14 Various
3C Tileset Specific 15 Various
3D Tileset Specific 16 Various
3E Tileset Specific 17 Various
3F Tileset Specific 18 Various

The above list shows the usage of the settings byte for each standard object; when an object has two columns for the usage, the right column is the lower nibble while the left is the higher nibble (i.e. #$HW for most objects). The usage can also be seen in Lunar Magic's object window, next to the object ID, though LM displays them in reverse order.


Extended Objects

Extended objects function as standard object 00, and are also 3 bytes long.

Format
N00YYYYY 0000XXXX BBBBBBBB
N New Screen flag
YYYYY Y position
XXXX X position
BBBBBBBB Extended object number

In vertical levels, the X and Y position values are swapped.

Extended Object List
ID Object name
00 Special - Screen Exit
01 Special - Screen Jump
02-0F Unused
10 Small door
11 Invisible ? block (1-UP)
12 Invisible note block
13 Top left corner edge tile 1
14 Top right corner edge tile 1
15 Small POW door
16 Invisible POW ? block
17 Green star block
18 3-UP moon
19 Invisible 1-UP #1
1A Invisible 1-UP #2
1B Invisible 1-UP #3
1C Invisible 1-UP #4
1D Red berry
1E Pink berry
1F Green berry
20 Always turning block
21 Bottom right of midway point (unused)
22 Bottom right of midway point (unused)
23 Note block (flower/feather/star)
24 ON/OFF block
25 Direction coins ? block
26 Note block
27 Note block, bounce on all sides
28 Turn block (Flower)
29 Turn block (Feather)
2A Turn block (Star)
2B Turn block (Star 2/1-UP/Vine)
2C Turn block (Multiple coins)
2D Turn block (Coin)
2E Turn block (Nothing)
2F Turn block (POW)
30  ? block (Flower)
31  ? block (Feather)
32  ? block (Star)
33  ? block (Star 2)
34  ? block (Multiple coins)
35  ? block (Key/Wings/Balloon/Shell)
36  ? block (Yoshi)
37  ? block (Shell)
38  ? block (Shell)
39 Turn block, unbreakable (Feather)
3A Top left corner edge tile 2
3B Top right corner edge tile 2
3C Top left corner edge tile 3
3D Top right corner edge tile 3
3E Top left corner edge tile 4
3F Top right corner edge tile 4
40 Transculent block
41 Yoshi Coin
42 Top left slope
43 Top right slope
44 Purple triangle, left
45 Purple triangle, right
46 Midway point rope
47 Door
48 Invisible POW door
49 Ghost house exit
4A Climbing net door
4B Conveyor end tile 1
4C Conveyor end tile 2
4D Line guide, top left 1/4 large circle
4E Line guide, top right 1/4 large circle
4F Line guide, bottom left 1/4 large circle
50 Line guide, bottom right 1/4 large circle
51 Line guide, top left 1/4 small circle
52 Line guide, top right 1/4 small circle
53 Line guide, bottom left 1/4 small circle
54 Line guide, bottom right 1/4 small circle
55 Line guide end, for horizontal line
56 Line guide end, for vertical line
57 Switch palace bottom right corner tile
58 Switch palace bottom left corner tile
59 Switch palace top right corner tile
5A Switch palace top left corner tile
5B Bit of brick background tile 1
5C Bit of brick background tile 2
5D Bit of brick background tile 3
5E Bit of brick background tile 4
5F Large background area
60 Lava/mud top right corner edge
61 Ghost house clock
62 Ghost house top left to bottom right beam 1
63 Ghost house top right to bottom left beam 1
64 Ghost house cobweb, top right
65 Ghost house cobweb, top left
66 Ghost house top right to bottom left beam 2
67 Ghost house top left to bottom right beam 2
68 Cloud fringe, bottom and right edge
69 Cloud fringe, bottom and left edge
6A Cloud fringe, bottom right
6B Cloud fringe, bottom left
6C Cloud fringe on white, bottom and right edge
6D Cloud fringe on white, bottom and left edge
6E Cloud fringe on white, bottom right
6F Cloud fringe on white, bottom left
70 Bit of canvass 1
71 Canvass 1
72 Canvass 2
73 Canvass 3
74 Canvass 4
75 Canvass tile 1
76 Canvass tile 2
77 Canvass tile 3
78 Canvass tile 4
79 Canvass tile 5
7A Canvass tile 6
7B Canvass tile 7
7C Bit of canvas 2
7D Bit of canvas 3
7E Bit of canvas 4
7F Torpedo launcher
80 Ghost house entrance
81 Water weed
82 Big bush 1
83 Big bush 2
84 Castle entrance
85 Yoshi's house
86 Arrow sign
87  ! block, green
88 Tree branch, left
89 Tree branch, right
8A Switch, green
8B Switch, yellow
8C Switch, blue
8D Switch, red
8E  ! block, yellow
8F Ghost house window
90 Boss door
91 Steep left slope (vert. lev.)
92 Steep right slope (vert. lev.)
93 Normal left slope (vert. lev.)
94 Normal right slope (vert. lev.)
95 Very steep left slope (vert. lev.)
96 Very steep right slope (vert. lev.)
97 Switch palace right and bottom edge tile
98-FF Unused


Screen Exits

Screen exits function as extended object 00. Unlike the rest of object data, they're 4 bytes long rather than 3.

Format
000ppppp 0000wush 00000000 dddddddd
ppppp Screen number
w Midway / Water flag1,2
u LM-modified flag1,3
s Secondary exit flag
hdddddddd Destination level / secondary exit ID

1 Added by Lunar Magic; not used in the original game.
2 If the secondary exit flag is clear, links to the destination level's midway entrance. Else, makes the destination level a water level.
3 Indicates the screen exit uses the secondary exit flag added by LM rather than SMW's default functionality.

In an unmodified SMW, if the last screen exit in the data has the secondary exit flag set, all screen exits in the level will be interpreted as secondary exits.
Additionally, in an unmodified SMW, the high bit of the current level is used as the high bit of the destination level / secondary exit ID.

As of Lunar Magic v2.50, an alternate version of this object also exists as extended object 02. This version adds an extra byte to the data, for the purpose of having 15-bit destinations (0000-1FFF) instead of 9-bit (000-1FF). It's used for the secondary exit expansion hijack.


Screen Jump

Screen jumps function as extended object 01, and change the high X position of proceding objects to a specified screen. They can be used to skip over screens if no objects exist on them, or to move back a screen to change the Z ordering of an object crossing over a screen boundary. Like standard and extended objects, they consist of three bytes.

Format
000PPPPP 0000---- 00000001
PPPPP Screen number
---- Currently unused


Lunar Magic Objects

Lunar Magic adds some additional objects under standard IDs 22-28, with 29-2C additionally reserved for future use, and object 2D reserved for user-defined objects.

Object 22/23

Object 22 and 23 are used for direct tiles from Map16 pages 0 and 1 respectively. They're four bytes long rather than three.

Format
N10YYYYY 001BXXXX HHHHWWWW bbbbbbbb
N New Screen flag
Bbbbbbbbb Map16 tile number
YYYYY Y position
XXXX X position
HHHH Height
WWWW Width

In vertical levels, the X and Y position values are swapped.


Object 24/25

Objects 24 and 25 are deprecated objects used to handle the old GFX bypass system, which used a list system for specifying ExGFX files. The new Super GFX bypass renders these unnecessary.

Format
Object 24 N10-SSSS 0100ssss FFFFFFFF
Object 25 N10-UUUU 0101uuuu AAAAAAAA
N New Screen flag
SSSSssss GFX list to use for sprite GFX, plus 1
FFFFFFFF GFX list to use for FG/BG GFX, plus 1
UUUUuuuu Unused? Stored to $FA.
AAAAAAAA GFX file for AN2, plus 1
- Currently unused

Note: the GFX list for FG/BG graphics does not include the extra files BG2 and BG3.


Object 26

Object 26 handles the music bypass.

Format
N10-UUUU 0101uuuu MMMMMMMM
N New Screen flag
MMMMMMMM Song ID to use, plus one.
UUUUuuuu Unused? Functions identical to the M bits.
- Currently unused


Object 27/29

Objects 27 and 29 handles Map16 objects other than those handled by object 22/23. Object 27 in particular handles Map16 pages 00-3F, while object 29 handles 40-7F. There are four different forms of the objects, depending on how the tiles are selected and stretched.

Format (for object 27)
Single-screen, single tile N10YYYYY 0111XXXX HHHHWWWW 00BBBBBB bbbbbbbb
Multiple tiles unstretched N10YYYYY 0111XXXX hhhhwwww 01BBBBBB bbbbbbbb
Single-screen, multiple tiles N10YYYYY 0111XXXX HHHHWWWW 10BBBBBB bbbbbbbb hhhhwwww
Multi-screen N10YYYYY 0111XXXX WWWWWWWW 11BBBBBB bbbbbbbb hhhhwwww HHHHHHHH

* Object 29 is handled identically, except the high 4 bits of the second byte are 1001 instead of 0111.

N New Screen flag
BBBBBBbbbbbbbb Base Map16 tile number
YYYYY Y position
XXXX X position
HHHH(HHHH) Height1
WWWW(WWWW) Width1
hhhh Height of Map16 selection
wwww Width of Map16 selection

In vertical levels, the X and Y position values are swapped.

1 Although the height and width of multi-screen objects are 8-bit, only values up to #$80 are valid due to the way their routine is coded.


Object 28

Object 28 handles the time limit bypass.

Format
N10-BBBB 0001CCCC R---AAAA
N New Screen flag
AAAA Ones
BBBB Tens
CCCC Hundreds
R Force timer reset flag
---- Currently unused


Object 2D

Object 2D is reserved by Lunar Magic for 5-byte custom user-defined objects. Although it's parsed by LM's hijacks, it's not actually tied to any routines normally.

Format
N10YYYYY 1101XXXX SSSSSSSS AAAAAAAA BBBBBBBB
N New Screen flag
YYYYY Y position
XXXX X position
SSSSSSSS Settings
AAAAAAAA Extension byte A
BBBBBBBB Extension byte B

ObjecTool uses extension byte A as the custom object number, while byte B is left free for use.

In vertical levels, the X and Y position values are swapped.


Extended Object 02

Extended object 02 serves as an expansion to the standard screen exit object. It's mostly identical to the original object, except byte 2 is moved to end to allow its high bits to be used.

Format
000ppppp 0000---- 00000010 dddddddd HHHHw11h
ppppp Screen number
w Water flag
HHHHhdddddddd Secondary exit ID
---- Currently unused


Background Data

When Layer 2 is stored as a background tilemap, it's compressed in the LC_RLE1 format:

Format
RLLLLLLL ...
R RLE flag
LLLLLLL Length
... If the RLE flag is clear, the following (length + 1) bytes are intepreted as direct tile data.
If the RLE flag is set, the following byte is repeated (length + 1) times.

A command of FF FF indicates the end of the data.

In its decompressed form, the tilemap data is written as direct 8-bit Map16 tiles numbers, with the entire left half of the BG written first, then the right half; in LM-modified ROMs, these sections extend a full 32 tiles vertically, although in the original game they only are 27 tiles tall. Additionally, in the original game, the high byte of each tile is then determined by where the data is actually located (page 0 if less than $0CE8FE, page 1 if greater), while in a LM-modified ROM, the high bytes of the tiles are just written in a second (identically-formatted) block following the low bytes.


Lastly, in the original game, whether or not Layer 2 is a BG tilemap or object data is determined by the bank byte of the data's pointer; if #$FF, it gets interpreted as a BG (and the byte is changed to #$0C), whereas any other value indicates object data. Lunar Magic changes this functionality so that BG tilemaps use the full 24-bit pointer, and instead moves the flag to determine its format to $0EF310:

Format
bBBB-FD-
D Data type; object (0) or tilemap (1)
F Flag to indicate the usage of the high nibble
BBB F bit set: Map16 bank to use for the BG
bBBB F bit clear: high byte for all BG Map16 tiles (only used for compatability with the original system)
-- Unused


Sprite Data

Sprite data consists of a single-byte header, followed by a list of all the sprites. If the first byte of a sprite is #$FF, it indicates the end of the data has been reached.

Format
yyyyEESY XXXXssss NNNNNNNN
Yyyyy Y position
EE Extra bits
XXXX X position
Sssss Screen number
NNNNNNNN Sprite ID

In vertical levels, the X and Y position values are swapped.

Note, however, that sprite data may not be limited to 3 bytes per sprite. As of Lunar Magic v1.80, any sprite may have up to four additional extension bytes defined, which immediately follow the relevant sprite's data (for up to 7 bytes per sprite). You can determine if any sprites do this by checking if read1($0EF30F) equals 0x42; if so, then a 0x400-byte table of each sprite's data size can be found at read3($0EF30C). The first 0x100 bytes of this table correspond to extra bit 0, the next 0x100 correspond to extra bit 1, etc.


Secondary Entrances

Secondary entrance data consists of four bytes, spread across four seperate 512-byte tables with one byte per secondary exit ID.

Format
$05F800 $05FA00 $05FC00 $05FE00
DDDDDDDD BBFFyyyy xxxSSSSS LPYXHAAA
DDDDDDDD Low byte of destination level
BB BG initial position
FF FG initial position
(Y)yyyy Entrance Y position2
(X)xxx Entrance X position2
SSSSS Entrance screen number
L Slippery level flag1
P Uses X/Y position method 21
H High bit of destination level1
AAA Entrance Mario action

In vertical levels, the X and Y position values are swapped.

1 Added by Lunar Magic; not used in the original game.
2 The capitalized Y and X bits are added by Lunar Magic when using X/Y position method 2, but are unused otherwise.


As of Lunar Magic v2.50, the secondary entrance tables may also be dynamically moved to expand their size. They can be found at:

$05F800 read3($0DE191)
$05FA00 read3($0DE198)
$05FC00 read3($0DE19F)
$05FE00 read3($05DC81)


ExAnimation Data

ExAnimation data is stored in two parts, the first being the general animation information and the second being the individual animation information. Note that, unlike most other data on this page, the below values are being described in hexadecimal rather than binary.

General Animation Format
SS EE cc CC ii II mm MM FF... dd DD...
SS Highest used animation slot, plus 1
EE Which alternate GFX file the level uses
CCcc Which custom triggers start uninitialized, bitwise
IIii Initial states for each custom trigger, when initialized
MMmm Which manual triggers are initialized, bitwise
FF... Frame numbers to initialize each of the specified manual triggers to
DDdd... Indices to each animation slot's data1 (with #$0002 referring to the byte after this value)

1 Indices are included up to the highest used slot. If a slot before that isn't used, its indice is 0000.

Individual Animation Format
AA TT FF dd DD mm MM...
AA Animation type
TT Trigger
FF Number of frames (-1)
DDdd Tiles only: VRAM destination1
DD Colors only: number of colors to animate (-1)1
dd Colors only: palette destination
MMmm... Memory address for each frame's tile/color data, or direct SNES RGB values when animating a single color

1 The highest bit being 1 indicates the slot uses the level's alternative GFX file.

Global ExAnimation data can be found with read1(read3($0583AE)+$5C)<<8+(read2(read3($0583AE)+$65)). If read2(read3($0583ae)+$5B) returns #$0000, the ROM has no global ExAnimation data.

The 24-bit pointers to level ExAnimation data can be found with read3(read3($0583ae)+$EA). If the second byte of the pointer is zero, then that level doesn't have animation data.


Additionally, there's a 512-byte table at $03FE00 that stores each level's animation settings.

Format
PTLG----
P Disable original game's palette animations
T Disable original game's tile animations
L Disable LM's level animations
G Disable LM's global animations
---- Currently unused


ExGFX Files

ExGFX files can be found in a large table at read3($0FF7FF), with 32 bytes per level. The files are listed in 16-bit, in the order:

AN2 LT3 BG3 BG2 FG3 BG1 FG2 FG1 SP4 SP3 SP2 SP1 LG4 LG3 LG2 LG1

Additionally, the high bytes of some of these files contain extra information:

Format
AN2 G3T?----
LT3 DDFF----
SP1 SCXX----
LG4 y?IB----
LG3 YYYY----
LG2 HHHH----
LG1 VVVV----
G Enable Super GFX Bypass
3 Enable Layer 3 Bypass
T Enable Layer 3 Tilemap Bypass
DD Layer 3 destination for file
FF Layer 3 file size
C Enable CGADSUB for Layer 3
S Move Layer 3 to subscreen
XX Initial Layer 3 X position
B Enable advanced bypass of Layer 3
I Fix layer 3 scroll sync issue
YYYYy Initial Layer 3 Y position
HHHH Layer 3 horizontal scroll setting
VVVV Layer 3 vertical scroll setting
 ?? Unused?
---- Normal high byte of GFX files


Note that the actual GFX data pointers can be found in various places:

File Pointer location
00-31 $00B992 (low), $00B9C4 (high), $00B9F6 (bank)
80-FF $0FF600 (24-bit pointers)
100-FFF read3($0FF937) (24-bit pointers)


Palette Data

Palette data is normally handled by the primary level header. More information on parsing the data there can be found here.

Lunar Magic determines whether a level uses SMW's original palette system or a custom palette by a 24-bit table at $0EF600. If a level's pointer is $000000, it does not use a custom palette, else the value is used as a pointer to the palette data. Custom palettes contain all 257 colors the level uses, with the first color being the back area color.

All palette data is stored as 16-bit SNES RGB values:

Format
-BBBBBGG GGGRRRRR
BBBBB Blue component (divided by 8)
GGGGG Green component (divided by 8)
RRRRR Red component (divided by 8)


Map16 Data

Map16 tilemap data is formatted fairly straightforward. The data consists of 8 bytes per 16x16, with 2 bytes for each 8x8 making it up. These two bytes are the tile number and the YXPCCCTT settings respectively for the tile, and the four tiles are ordered top left, bottom left, top right, bottom right.

Getting the location of this data requires a bit of work, however. Vanilla tiles (i.e. tiles on page 0 or 1) use a large pointer table in RAM at $0FBE; this table has two bytes per tile, which are used as a pointer to their full Map16 data in ROM (the bank byte is assumed to be 0x0D). Lunar Magic then writes custom tiles to a set of tables based on the page number the tile is on; unlike the vanilla tiles, these tables just contain the direct data rather than pointers to data. Each page's Map16 table can be found at the following locations:

Pages Location
02-0F read1($06F557)<<16|read2($06F553)
10-1F read1($06F560)<<16|read2($06F55C)
20-2F read1($06F56B)<<16|read2($06F567)+1
30-3F read1($06F574)<<16|read2($06F570)+1
40-4F read1($06F598)<<16|read2($06F594)
50-5F read1($06F5A1)<<16|read2($06F59D)
60-6F read1($06F5AC)<<16|read2($06F5A8)+1
70-7F read1($06F5B5)<<16|read2($06F5B1)+1

In addition to this, a ROM may have tileset-specific Map16 enabled on page 2, which can be determined by checking if read1($06F547) is non-zero. If this is the case, then page 2's Map16 can instead be found in a separate table located at (read1($06F58A)<<16|read2($06F586))+$1000. This table has 0x800 bytes per tileset; effectively, you can find each tile's Map16 with an index of 0ttttbbb bbbbb000, where tttt is the tilemap number and bbbbbbbb is the lower 8 bits of the tile number.

Acts-Like Setting

In addition to the visual aspect, each Map16 tile also has an "acts-like" setting which determines the base vanilla tile the block borrows interaction from. All the settings for pages 00-3F can be found at read3($06F624), while pages 40-7F can be found at read3($06F63A). Each block receives two bytes in these tables, for the 16-bit tile number they're set to act like. To get the true acts-like setting for a particular tile, repeat lookups in this table using each returned tile number until a tile less than 0x200 is found.

Background Map16 Tiles

Background Map16 data can be found using a pointer table located at $0EFD50, where each set of 0x10 pages receives one 24-bit pointer. The data itself is otherwise formatted the same as the foreground tiles.