Help:Rom Map

Below are the general guidelines and recommendations for ROM maps. These conventions should be followed when possible, but there is no one-size-fits-all solution. Use your best judgement.

Content

ROM maps are intended to identify the purpose of specific ROM locations. A brief description may also be provided for specific regions of the ROM. Detailed explanations of the data structures and any other explanatory text should be minimal. This additional content can go into a separate article.

For games that use a file system, the ROM map should serve as a catalog of files.

Format and Layout

• Place the {{rommap|game=name of game}} template at the top of every ROM map page.
• Avoid using HTML/wiki tables for large listings. These can be cumbersome to edit and don't copy and paste well. Tables can be created using pre-formatted text instead. Either use the HTML <pre></pre> tags, or precede each line in the listing with at least one space.
  • <pre></pre> tags can not contain links or wiki markup.
  • Pre-formatted text using a space before each line may include wiki markup and links.
• The ROM map should be organized into neat columns, with offsets on the left and descriptions on the right. Additional columns can be included in-between to specify data-block sizes or data types. Use column headings.
• Offsets should be specified in hexadecimal. Including prefixes such as "$" or "0x" is not necessary.
• Data sizes should generally be shown in hexadecimal. In any case, it is best to explicitly state the format and convention used.

Headers

Many ROMs include internal and/or external headers. Internal headers are part of the ROM image and don't present a problem for ROM maps. External headers (e.g. copier headers and iNES headers) are a source for confusion. The offsets provided in a ROM map may or may not account for headers. Follow these guidelines to minimize confusion.

• First and foremost, always, always specify whether or not the ROM map accounts for external headers. Use precise vocabulary. The phrasing "The offsets listed are for a ROM that does not include a copier header," avoids confusion about whether an internal or external header is being discussed.
• It's strongly recommended that text be added explaining how to convert offsets between the convention used and the convention not used, i.e. "Subtract $10 bytes from the value listed to get the un-headered offset."
• Generally, it's preferred that ROM maps not include the external header.
  • In particular, SNES ROM maps that include copier headers are strongly discouraged.
  • iNES and FDS headers are acceptable because these are near-universal and generally required for emulation.
• Be consistent throughout the entire document. Mixing headered and unheadered offsets in the same document virtually guarantees confusion.

Avoid converting ROM maps between un-headered and headered to suit your preference. One exception is that ROM maps may be updated to reflect ROMs without copier headers to conform with guidelines. Any other concerns about headers in ROM maps may be discussed in Talk pages or brought to the attention of staff.

Example ROM Map -- Hypothetical Game II, Bank 1
 
Address Size    Description
------- ----    -----------
 1010   2       Ptr to Level 1 meta-tile table
 1012   2       Ptr to Level 1 meta-meta-tile table
 1014   2       Ptr to Level 1 meta-meta-meta-tile table
 1016   2       Ptr to Level 1 map
 1018   2       Ptr to Level 1 object data
 123F   1       Level 1 start position - X
 1244   1       Level 1 start position - Y
  ...

Organization

ROM maps should be listed by offset in ascending order. This allows others to easily look up a specific address. If there is a compelling reason to do so, a secondary listing may be added, organized by function. (For example, a listing of memory locations that contain the player's properties and stats may be appropriate if the data is unorganized and spread out in the ROM.)

ROM maps can be divided by bank/level if the listing is long.