Metroid/Room data format

This is a sub-page of Metroid.

Room data formats
Game	Metroid
Start Address	Varies by bank. See ROM Map
End Address	Varies by bank. See ROM Map
# of Entries	Varies with room data.
Entry Length	Varies by individual room.
Total Length	Varies by bank. See ROM Map
Back to the ROM map

The information contained herein serves as a guide to the specific detailed inner workings of the ROM addresses for Metroid in regards to the data that the game uses to create the individual rooms that it uses to make up it various hallways, tunnels, and chutes. This data is valid for all of the game's five areas...Brinstar, Norfair, Tourian, Kraid, and Ridley. The data contained herein is to be used in conjunction with Metroid's ROM Map and serves as an overall guide and reference.

Room Data Format

CA OA OA OA OB OB OB OC OC OC FD 02 DA 02 DB EA EA EA EB EB EB EC EC EC FF

• CA: Color attribute table variable.
• OA, OB, OC: Room object variables.
• FD: Data splitter, always a value of FD.
• 02 DA, 02 DB: Doors, 02 followed by variable.
• EA, EB, EC: Enemy data variables.
• FF: End of room data, always a value of FF.

Color Attribute Table (CA)

• The first byte of room data is the color attribute table to be used by that room, usually set to the dominant color pallette. This is a value between 00 and 03 which represents one of the four pallettes used for room objects.

Room Object Data (OA, OB, OC)

• Immediately following the attribute table are any number of sets of three bytes which represent room objects and determine a particular object's location, the object to be used, and the color pallette it uses, in that order. This continues until room data either encounters FD (End Object Data, Begin Door/Enemy Data) or FF (End Data For Entire Room). Though it is technically possible to immediately follow the attribute table with FD or FF and have no objects in a given room, this method is rarely, if ever, put into practice by Metroid hackers.

Data Splitter (FD)

• This variable, if it exists in a particular room's data, is always set to a value of FD. It indicates the end of room object data and the beginning of door and enemy data for that room. If there are no doors or enemies to be used in that room then FD does not need to be used. It is, however, possible within the Metroid ROM to have a legitimate and working room where FD is present immediately followed by FF, which ends overall room data and creates no doors or enemies. This is an interesting technique for one to know when they need to fill out a little extra "space" in a room's data and don't wish to mess around too much with pointers.

Door Data (02 DA, 02 DB)

• Any doors in a given room are represented by instances of "02 XY", where 02 is an absolute value and XY is a variable, immediately after FD and before enemy data begins. X determines whether the door is on the left side (X="B") or right side (X="A") of the screen, and Y determines what type of door it is (Y="0" for 5-Missile/Red Door, Y="1" for Normal/Blue Door, Y="2" for 10-Missile/Yellow/Purple Door). Door data, if present, continues until FF (End Of Data) is encountered or until enemy data begins.

Enemy Data (EA, EB, EC)

• Enemies are represented by any number of sets of three bytes following FD and any relevant door data, and these three bytes are indicative of sprite number assignment, enemy type, and location, in that order. The first digit (nybble) of the enemy type variable differentiates between easy/hard/boss enemies, and the second digit (nybble) of the enemy type variable indicates the particular enemy to be used. The first and second digits of the location byte indicate separate Y (vertical) and X (horizontal) screen coordinates respectively. Enemy data, if present, continues until FF (End Of Data) is encountered.

End Of Data (FF)

• This is always indicated by the value FF, and signifies the end of overall data for any given room.

Examples

• The following example rooms are placed here as a learning aid and a reference. Individual sections are highlighted for convenience.

• 00 A0 0B 00 C7 09 00 E1 29 00 FD 02 A1 02 B0 01 85 47 11 05 BA 21 05 BC FF

This room contains three objects, a red door on the left, a blue door on the right, and three enemies.

• 03 00 0B 03 0E 0B 03 50 0B 03 5E 0B 03 A0 0B 03 FF

This room contains five objects, nothing nore.

• 02 00 0B 03 02 09 03 0E 0B 03 50 0B 03 56 0A 03 5F 03 02 8B 0A 03 FD 02 B0 02 B1 FF

This room contains seven objects and a single blue door on the left. In this weird little example, left-side door data is defined twice, to fill out a little bit of "space" used by the program area. In all cases of this, the last door defined in a given space (left/right) will always take precedence over earlier doors and thus overwrite them.

• 03 00 0B 03 04 0A 03 0E 0B 03 47 09 03 FD 41 03 45 51 03 BB 31 05 39 FF

This room contains four objects and three enemies, and no doors.

• 01 FD 02 A2 O2 B2 01 03 B3 11 03 3C 21 05 A8 31 05 64 51 85 7B 41 05 28 FF

This room contains two 10-Missile doors, one on the left and one on the right, and six enemies. This is a room with absolutely no sbjects in it. One will rarely, if ever, see this type of room in a Metroid hack, as the creation and use of which defies logical reasoning. It is possible to create one, however...