Dragon Quest III (SNES)/ROM map

The following article is a ROM map for Dragon Quest III (SNES).

Notes

All values given are ROM offsets. They assume that a 512-byte copier header is not present. If there is a header present, you will have to add 512 ($200) to each offset lister here to get the correct offset in the ROM file.

Note that the ROM is mapped into the SNES address space starting at $C00000. Therefore, if you want to use one of these ROM offsets as a breakpoint, you should add $C00000 to it. I've given a few examples below that already do this.

Menu Size Data

Almost every menu has a 16-bit (2-byte) value that determines its starting position (X/Y coordinates) and its width. Menu size data is stored in the following binary format:

%1WWW WWYY YYYX XXXX

• WWWWW = menu width (not just usable space, this includes the edge characters)
• YYYYY = vertical tile offset from top of screen
• XXXXX = horizontal tile offset from left of screen

There is no value to determine the height of a menu. This is done internally by the drawing code for each individual menu.

Like almost everything else on the SNES, this data is in low-endian format. Thus, the YYYX XXXX byte comes first in the ROM, then the 1WWW WWYY byte.

Here are a few menu size values that I have found. Note again that this controls only menu width and position. Menu content string pointers are stored elsewhere.

• $30348-$30349: Introductory menu (contains Begin a New Quest, Continue Quest, Copy Quest, etc., etc.)
• $30378-$30379: Change Message Speed menu (opened from introductory menu)
• $30384-$30385: Mono/Stereo selector menu
• $30024-$30025: Main walkabout menu (contains Talk, Spell, Item, Search, Status, Tactics)
• $300FC-$300FD: Gold menu, associated with the main walkabout menu
• $3036C-$3036D: Change Message Speed menu (opened from Tactics)

What if the menu you want to expand (or contract!) isn't listed above? Here's how to find it.

• Open the menu you want, and take a screenshot of it. As an example, let's try the gold box that appears when you open the main menu.
• Open the screenshot in a paint program, and find out the X coordinate, Y coordinate, and width. Remember that these coordinates are in tiles, so you have to find the coordinate (or width) in pixels and then divide that number by 8.
• Convert these values to hexadecimal and write them down. In this case, our X coordinate is 21 ($15), the Y coordinate is 16 ($10), and the width (including borders) is 9 ($09).
• Open the ROM in a debugging emulator (I use Geiger's Snes9x debugging version).
• Prepare things so that it will only take 1 more button press to get into the menu you want.
• Set an execution breakpoint at $C90717.
• Open the menu — this should set off the breakpoint.
• Keep an eye on the A register.
• You might see something like this as the breakpoint is hit four times (On Geiger Snes9x, hit the "Run" button to get to the next breakpoint).
  • $C9/0717 08 PHP A:0000 X:0000 Y:0015 P:envmxdIZc
  • $C9/0717 08 PHP A:0015 X:0000 Y:0015 P:envmxdIzc
  • $C9/0717 08 PHP A:1015 X:0000 Y:0015 P:envmxdIzc
  • $C9/0717 08 PHP A:0009 X:0000 Y:0015 P:envmxdIzc
• This is for the gold menu. If you followed the steps above, you should see some familiar information here. Note how on the second iteration, we see the X coordinate in the accumulator, and on the third iteration, we can see both the X *and* Y coordinates in the top and bottom halves. And on the fifth iteration, there is the width.
• Don't proceed past the fifth iteration (the one where A = menu width). Instead, single step ("Step Into" button on Geiger Snes9x) until you get to $C902B1.
• You'll see something like this:
  • $C9/02B1 33 10 AND ($10,s),y[$C3:00FD] A:0F80 X:00C3 Y:0000 P:envmXdIzc
• See that [$C3:00FD]? Now just take that number and subtract $C00001 (yes, $C00001, not $C00000) from it.
• We now have the location of the menu size data; in this case, $300FC. Remember that the value at this address is two bytes long, and low-endian.
• Note that, in some cases, there will be unwanted $C90717 breakpoints before the one we're looking for. That's why you should monitor the A register and make sure we're looking at the right iteration. The method I detailed above works only if you check the address on the iteration that contains the menu width ($0009, in this case).

Menu Text Pointers

To change the menu text, you need to find the pointers for that text. In most cases, this pointer is actually the 16-bit operand of an LDA opcode. Pointers can usually only reference the 64K block of memory from which they are called; in other words, if a pointer is at $360D1 in the ROM, it can't reference anything above $3FFFF or below $30000. In some cases, a pointer can't be made to point backwards without further hacking, because of the way that they are referenced. (More to come...) Fortunately, this shouldn't really be a big issue, because there is a block of apparently unused space (solid $FFs) from $3F30A-$3FFFF. Most pointers are in the range of this memory. (Please let me know if I'm mistaken and this empty space actually serves a purpose!)

A list of menu pointers can be found at the Kojiro Translations wiki.

Menu Padding Routine

Some menu entries have extra spaces padded onto the end that is not accounted for by the data at the expected pointers. These spaces are inserted by the use of a special routine located at $32B70 in the ROM. When this routine is called, the X register contains the number of spaces to insert. If you're doing some menu expansion, you may have to set breakpoints at $C32B70. Single-step through until RTL is executed, so you can see where it came from, and then back up five bytes from the resulting address. If these padding spaces are throwing off your menu borders, replace the JSL $C32B70 opcode with four NOPs.

Calling $32B8D inserts a single dummy space. The "Change Message Speed" option on the "Tactics" menu uses this method, so look out for it if you're editing that menu item. There may be others I haven't found yet that do the same thing. Again, you can track down the originating JSL opcode by breaking on the subroutine start, stepping through until RTL is executed, and then subtracting five bytes from the program counter at that point.

Overworld Map

The overworld map is made up of a 64x64 grid of chunks which are a 4x4 grid of 16x16 pixel tiles which are really four 8x8 tiles. This results in a 4096x4096 pixel sized map.

Top level grid

Location in ROM: $2D8A00 - $2D9BE2

The top level of the overworld tilemap data is a 64x64 grid composed of a word length (2 byte) index indicating which chunk to use. This is $2000 bytes. Most of the data is just a counter that increments by one each time since most of the land chunks are unique. However the open parts of the sea are represented by chunk $0001 so you will see long runs of that index. Some other reused chunks are composed of all desert or all forest or all grass, that kind of thing. Values range from $0001 to $0A3C, and $0000 is not used although is a valid chunk made of zeros.

Decompression uses a $400 byte ring buffer that is all zeros at the beginning and a starting write position of $3BE. Every decompressed byte is written to the output and the ring buffer. The compressed data is composed of a command byte followed by 8 to 16 data bytes. For each bit in the command byte, if the bit is 1 then read and write one byte. If the bit is 0 then perform a copy operation from the ring buffer using the next two bytes of source data. The 10 lower bits are a pointer into the ring buffer that will be used as the source address. The number of bytes to copy is the upper 6 bits plus 3. Note that the copied bytes are written to the output and also into the ring buffer so if the buffer read address is close behind the buffer write address then you're copying what was just written. This is mostly used to generate long stretches of $0001 which represents the chunks of open sea.

Chunks

Location in ROM: $2DA49C - $2E486B‬

The chunks are 4x4 grids of tile indexes (1 byte) accessed with an index. The chunk data is in one contiguous area but is actually 16 different byte arrays, one after another and each one $A3D bytes long, so that all 16 tiles can be accessed with the same index.

The starting addresses for each array are shown in the layout the tiles appear on screen:

	X + 0	X + 1	X + 2	X + 3
Y + 0	$2DA49C	$2DAED9	$2DB916	$2DC353
Y + 1	$2DCD90	$2DD7CD	$2DE20A	$2DEC47
Y + 2	$2DF684	$2E00C1	$2E0AFE	$2E153B
Y + 3	$2E1F78	$2E29B5	$2E33F2	$2E3E2F

Values range from $00 to $EC because the definitions for tiles $ED to $FF are not loaded, although there is space in RAM for them.

Tiles

Location in ROM: $254F38 - $25569F

Each entry is 8 bytes with each 2 bytes representing one of the 4 tiles (8x8) that make up the larger 16x16 tile. These 2 byte parts are in the standard SNES tilemap format and are copied as is into VRAM.

Links

None currently.