The game data (images, sounds, music, text, etc…) of Dungeon Master, Chaos Strikes Back and Dungeon Master II is stored in data files that share the same general file format. They are made of two main parts:
Each item contains a certain type of data. In this document and in the sample script, each data type was given a name like IMG1 or IMG2 for different image encodings, SND1 or SND2 for sound encodings, etc… Please refer to the “Item data formats” section below for a description of each data format.
A graphics item cannot be larger than 32 KB (32768 bytes). The item containing the portraits can be expanded to store up to 64 portraits instead of only 24 as in the original games. The image should then contain 8 lines of 8 portraits. It is not possible to add more portraits because of the 32 KB item size limitation. [Credits: Meynaf]
The following terms are used in this document for basic data types: a nibble (4 bits), a byte (8 bits), a word (16 bits, two bytes) and a dword (32 bits, four bytes).
There are three slightly different header formats depending on the game and version.
The header contains only words of data (and a dword in the DMII format). These words and dwords can be stored as little endian or big endian depending on the data file.
Please refer to the table below to know which endian and file format are used in each data file.
This format is used in earlier versions of Dungeon Master and Chaos Strikes Back. In this format, the header contains the number of items in the file and the compressed and decompressed sizes of each item.
This format is used in later versions of Dungeon Master and Chaos Strikes Back. In this format, the header contains the same information as in the DMCSB1 format as well as an additional file signature and two words of attributes for each item.
This format is used in all versions of Dungeon Master II. In this format, the header contains a file signature, the number of items in the file, the size of the first item stored as a double word and the size of all other items.
Here are the contents of items attributes in GRAPHICS.DAT DM PC v3.4 English and Multilingual:
The following table lists the endian and file format used in each data file:
| Data File | Number of Items | Endian | Format | Contains LZW compressed items |
|---|---|---|---|---|
| GRAPHICS.GAME DM Apple IIGS | 575 | LITTLE | DMCSB1 | - |
| GRAPHICS.DAT DM FM-Towns | 575 | LITTLE | DMCSB1 | - |
| GRAPHICS.DAT DM Amiga v2.0 | 575 | BIG | DMCSB1 | - |
| GRAPHICS.DAT DM Amiga v2.0 FR | 575 | BIG | DMCSB1 | - |
| GRAPHICS.DAT DM Amiga v2.2 GE | 575 | BIG | DMCSB1 | - |
| GRAPHICS.DAT DM Atari ST v1.0 EN, v1.1 EN, v1.2 EN, v1.2 GE, v1.3 FR | 563 | BIG | DMCSB1 | Yes |
| GRAPHICS.DAT CSB Atari ST v2.0 EN, v2.1 EN | 563 | BIG | DMCSB1 | Yes |
| ANIMATE.DAT CSB Atari ST | 87 | BIG | DMCSB1 | - |
| HCSB.DAT CSB Amiga English Release 1 and Atari ST v2.0 | 4 | BIG | DMCSB1 | - |
| HCSB.DAT CSB Amiga English Release 2 and 3 | 5 | BIG | DMCSB1 | - |
| HCSB.DAT CSB Amiga French Release | 5 | BIG | DMCSB1 | - |
| HCSB.DAT CSB Amiga German Release | 5 | BIG | DMCSB1 | - |
| NAKED.AMG CSB Amiga Utility Disk English | 6 | BIG | DMCSB1 | - |
| NAKED.AMG CSB Amiga Utility Disk French and German | 6 | BIG | DMCSB1 | - |
| SONG.DAT DM PC v3.4 | 10 | LITTLE | DMCSB2 | - |
| GRAPHICS.DAT DM PC v3.4 English | 713 | LITTLE | DMCSB2 | - |
| GRAPHICS.DAT DM PC v3.4 Multilingual | 748 | LITTLE | DMCSB2 | - |
| GRAPHICS.DAT DM Amiga v3.6 | 749 | BIG | DMCSB2 | - |
| GRAPHICS.DAT DM X68000 | 562 | BIG | DMCSB2 | - |
| GRAPHICS.DAT DM PC-9801 | 575 | LITTLE | DMCSB2 | - |
| GRAPHICS.DAT CSB Amiga v3.1 EN, vXX | 728 | BIG | DMCSB2 | - |
| GRAPHICS.DAT CSB Amiga v3.1 EN FR GE, v3.3 EN FR GE | 749 | BIG | DMCSB2 | - |
| GRAPHICS.DAT CSB X68000 | 732 | BIG | DMCSB2 | - |
| GRAPHICS.DAT CSB FM-Towns EN | 728 | LITTLE | DMCSB2 | - |
| GRAPHICS.DAT CSB FM-Towns JP | 728 | LITTLE | DMCSB2 | - |
| GRAPHICS.DAT CSB PC-9801 | 728 | LITTLE | DMCSB2 | - |
| GRAPHICS.DAT DMII PC 0.9 Beta This file is split in two parts. You can join them with the following command line: copy /b graphics.dat + graphic2.dat dm2pcb.dat. | 3965 | LITTLE | DMII | - |
| GRAPHICS.DAT DMII PC English | 5624 | LITTLE | DMII | - |
| GRAPHICS.DAT DMII PC German | 5630 | LITTLE | DMII | - |
| GRAPHICS.DAT DMII PC French | 5636 | LITTLE | DMII | - |
| GRAPHICS.DAT DMII PC Demo | 3332 | LITTLE | DMII | - |
| GRAPHICS.DAT DMII PC-9801 This file is split in two parts. You can join them with the following command line: copy /b graphics.dat + graphic2.dat dm2pc9801.dat. | 3483 | LITTLE | DMII | - |
| GRAPHICS.DAT DMII IBM PC-9821 | 3491 | LITTLE | DMII | - |
| GRAPHICS.DAT DMII IBM PS/V This file is split in two parts. You can join them with the following command line: copy /b graph1.dat + graph2.dat dm2ibmpsv.dat. | 3491 | LITTLE | DMII | - |
| GRAPHICS.DAT DMII Amiga | 4630 | BIG | DMII | - |
| GRAPHICS.DAT DMII Macintosh EN | 4902 | BIG | DMII | - |
| GRAPHICS.DAT DMII Macintosh EN Demo | 2680 | BIG | DMII | - |
| GRAPHICS.DAT DMII Macintosh JP | 3399 | BIG | DMII | - |
| GRAPHICS.DAT DMII Sega CD EN | 3153 | BIG | DMII | - |
| GRAPHICS.DAT DMII Sega CD JP | 3163 | BIG | DMII | - |
| GRAPHICS.DAT DMII FM-Towns | 3407 | LITTLE | DMII (File signature is 8004h instead of 8005h) | - |
The data section contains all items stored one after the other, until the end of the file. The size of each item is specified in the header section. The type of each item is not specified in the data file. That is the reason why the sample script uses .map files to know how to decode each item.
Please refer to the “Item data formats” section below for a complete description of each data format.
The following list will tell you which item data formats are used in each data file:
Items 558-562 are not used (the data is also found directly inside the executable). The developers probably forgot to remove them when porting the game from Atari ST. They were removed from all other Amiga versions.
IMG1 and IMG2 items contain images. The only difference between these two formats is the endian of the first two words that define the size of the image:
IMG1 and IMG2 data is used to store 16 colors images compressed with some sort of RLE algorithm (Run Length Encoding). The data is divided in nibbles (4 bits). Nibbles are grouped into blocks of variable length (at least 2 and always an even number). Each block defines a set of pixels to add to the image.
The image is considered as a single sequence of pixels starting at the top left corner of the image and going line by line to the bottom right corner.
Here is the algorithm to decode a block:
Read two nibbles: Nibble1 and Nibble2
Depending on the hexadecimal value of Nibble1, several cases are possible:
0, 1, 2, 3, 4, 5, 6, 7: Add ‘Nibble1 + 1’ pixels of the color specified in Nibble2.
8: Read the next byte (2 nibbles) in Byte1. Add ‘Byte1 + 1’ pixels of the color specified in Nibble2.
C: Read the next word (4 nibbles) in Word1. Add ‘Word1 + 1’ pixels of the color specified in Nibble2.
B: Read the next byte (2 nibbles) in Byte1. Add ‘Byte1 + 1’ pixels by copying pixels from the previous line of the image (position of current pixel minus width of image). Then add one pixel of the color specified in Nibble2.
F: Read the next word (4 nibbles) in Word1. Add ‘Word1 + 1’ pixels by copying pixels from the previous line of the image (position of current pixel minus width of image). Then add one pixel of the color specified in Nibble2.
9: Read the next byte (2 nibbles) in Byte1.
If Byte1 is even,
If Byte1 is odd,
D: (similar to 9): Read the next 2 bytes (4 nibbles) in Word1.
If Word1 is even,
If Word1 is odd,
A: Add ‘Nibble2 + 1’ transparent pixels (only used in DL items in animation files)
E: Transparent pixels (only used in DL items in animation files)
Depending on the hexadecimal value of Nibble2, several cases are possible:
IMG3 and IMG4 items contain images. The only difference between these two formats is the endian of the first two words that define the size of the image:
IMG3 and IMG4 data is used to store 16 colors images compressed with some sort of RLE algorithm (Run Length Encoding). The data is divided in nibbles (4 bits). Nibbles are grouped into blocks of variable length (between 1 and 9 nibbles). Each block defines a set of pixels to add to the image and is made of:
The image is considered as a single sequence of pixels starting at the top left corner of the image and going line by line to the bottom right corner.
Here is the algorithm to decode a block:
Read the ‘Control’ nibble. This nibble specifies what to add to the image:
Determine how many pixels to add to the image:
If Bit 3 of the ‘Control’ nibble is set to 1, the number of pixels to add is specified in the next 1, 3 or 7 nibbles (called nibble1, nibble2, etc…). Use the following algorithm to get this number:
Read Nibble1
If Nibble1 < 0Fh then
NumberOfPixels = Nibble1 + 2
Else
Read Nibble2 and Nibble3
If Nibble2 * 16 + Nibble3 < FFh then
NumberOfPixels = Nibble2 * 16 + Nibble3 + 17
Else
Read Nibble4, Nibble5, Nibble6 and Nibble7
NumberOfPixels = Nibble4 * 4096 + Nibble5 * 256 + Nibble6 * 16 + Nibble7
End If
End If
IMG5 items contain images. This item format is used in Dungeon Master for Amiga 2.0 in the Swoosh file. There is no header.
IMG5 data is used to store 16 colors images decompressed in planar format. There are 4 planes stored one after the other.
In each plane, there is one bit for each pixel of the whole image, so each byte contains a bit for 8 pixels. The most significant bit of each byte is for the first pixel.
Each pixel is a color index in a 16 colors palette which is not part of the image data. The most significant bit of each pixel is located in the first plane, the next bit in the next plane, etc. and the less significant bit is located on the last plane.
Pixels are decoded from left to right and top to bottom of the image.
IMG6 items contain images. These items are used in Dungeon Master II for FM-Towns.
IMG6 data is used to store 16 colors images decompressed. The size of data for each image line must be a multiple of 16 bytes. Bytes with value 00 are used for padding if the image size if not a multiple of 32 pixels.
Each nibble of data represents a pixel. The most significant nibble of each byte is the first pixel.
Example:
If an image has a width of 83 pixels, you will need 83 / 2 = 42 bytes to store the data (2 pixels per byte). The last nibble is unused because the number of pixels if odd.
In order to achieve the mandatory 16 bytes alignment, you need to round up to the next multiple of 16, which is 48 bytes of data per line. When reading this data, you have to ignore the last 6.5 bytes of padding at the end of useful data.
IMG7 and IMG8 items contain images. The only difference between these two formats is the endian of the first two words that define the size of the image.
These items share the same format as IMG3 and IMG4 items, except for the size of the local palette which is only 5 nibbles instead of 6. These items are used in some Dungeon Master II versions (like PC version) for overlay images only (base images do not use these formats). An overlay image is always combined (using transparency) with an base image and optionally with other overlay images in order to produce a final image. You can consider a base image as a complete image. An overlay image only contains differences from a base image.
IMG7 and IMG8 data is identical to IMG3 and IMG4 data, check the IMG3 and IMG4 section for details.
The only differences are:
This item format is described by kentaro.k-21 in Dungeon Master II Data Files Notes.
This sound format is used in the Atari ST versions of Dungeon Master and Chaos Strikes Back.
The sound is encoded as PCM, 4 bit, mono, unsigned and is compressed with an RLE algorithm. Here is how to decode these sounds:
Repeat that process until there are no more nibbles to read
Note: if you want to convert the sound data to PCM 8 bit sound, you need to multiply each sample value by 17 (the maximum nibble value is 15 which multiplied by 17 gives 255, the maximum 8 bit value).
Playback frequency of Entrance door sound: 2.4576 MHz / (4 * 145) = 4237 Hz
Playback frequency of all other sounds: 2.4576 / (4 * 112) = 5486 Hz
In order to play digital sounds, the game engine programs Timer A of the MK68901 MFP chip so that an interrupt is triggered periodically.
A new sound sample is played during each interrupt until the sound playback is complete and the interrupt is disabled.
While the MFT chip itself is clocked at 4 MHz, it has a separate clock source for the reference signal used by the timers: a 2.4576 MHz crystal.
The game configures Timer A in the following way:
The Timer A control byte is set to $01 which means that it will work in delay mode and with prescaler = 4.
When the sound of the opening dungeon doors is played on the main screen (where you choose Prison / Resume), the Timer A data byte is set to 145 ($91).
When any other sound in the game is played, the Timer A data byte is set to 112 ($70).
If you listen carefully to the original game, you will notice that the door sound is not played at the same speed for the entrance door and for doors when playing in the dungeon.
Also, there is no difference in sound playback frequency between a US (NTSC) and European (PAL) Atari ST computers.
Playback rate: the playback rate is not the same for all SND2 items in all versions. Moreover, in Amiga versions, the exact sample rate is different on PAL (Europe) and NTSC (US) machines because the sound clock is based on the CPU clock which is different in PAL (7093790 Hz) and NTSC (7159090 Hz).
The game does not define the frequency but the period for the sound chip. The sample rate is (CPUclock / (2 * period)).
With a period of 334 (014Eh, used in the swoosh program in DM Amiga v2.x), the sample rate is:
PAL: (7093790/2) / 334 = 10619 Hz
NTSC: (7159090/2) / 334 = 10717 Hz
Each sound in the game is defined with a playback speed value (one byte). The period configured on the sound chip is set to: 72800 / playback speed.
With a playback speed of 112 (used for sound items 533-537, 539-547, 550-555, 572 in DM Amiga v2.x), the sample rate is:
PAL: (7093790/2) / (72800 / 112) = 5457 Hz
NTSC: (7159090/2) / (72800 / 112) = 5507 Hz
With a playback speed of 138 (used for sound items 549, 563-571, 573 in DM Amiga v2.x), the sample rate is:
PAL: (7093790/2) / (72800 / 138) = 6718 Hz
NTSC: (7159090/2) / (72800 / 138) = 6779 Hz
With a playback speed of 150 (used for sound item 574 in DM Amiga v2.x), the sample rate is:
PAL: (7093790/2) / (72800 / 150) = 7313 Hz
NTSC: (7159090/2) / (72800 / 150) = 7381 Hz
Playback rate: around 6000 Hz.
This sound format is used in the X68000 versions of Dungeon Master and Chaos Strikes Back.
You can open these sounds with Goldwave (as Telephony / Dialogic 4 bit VOX ADPCM mono).
Playback rate: around 7812.5 Hz.
If you want to decode these items, you need to read the detailed technical information about the Dialogic ADPCM Algorithm.
The SND5 sound format is used in the Amiga version of Dungeon Master II. The SND6 sound format is used in the PC versions of Dungeon Master II. The only difference between these two formats is the endian of the first word of data.
Playback rate: 11127 Hz (or maybe 11025 Hz which is more standard).
This sound format is used in the Sega CD version of Dungeon Master II.
Playback rate: around 6000 Hz.
This sound format is used in the PC version of Dungeon Master, in the SONG.DAT file.
Playback rate: 11025 Hz.
The sound data is encoded in a sort of DPCM (Differential PCM). Each signed nibble of data specifies the difference between the previous sample and the next one. There is one special nibble value (-8) which specifies that the sample difference is encoded in the next two nibbles (as a signed byte). Here is how to decode these sounds:
Read Nibble1 (the value is 0 to 15)
If Nibble1 > 7 Then Nibble1 = Nibble1 - 16
If Nibble1 <> -8 Then
Difference = Nibble1
Else
Read two more nibbles, Nibble2 and Nibble3
Difference = Nibble2 * 16 + Nibble3
If Difference > 127 Then Difference = Difference - 256
End If
Sample = PreviousSample + Difference
Repeat that process until there are no more nibbles to read
This sound format is used in the FM-Towns version of Dungeon Master II.
Playback rate: around 6000 Hz.
This sound format is used in the IBM PS/V version of Dungeon Master II.
Playback rate: around 6000 Hz.
MUS1 data contains a standard MIDI file.
FNT1 data contains a picture of 1 line of 128 characters of 5 pixels width and 6 pixels height. The three most significant bits of each byte of FNT1 data are not used and set to 0. The other 5 bits define one line of a character.
The first 128 bytes of data represent the first line of each character. The next 128 bytes are for the second line, and so on until the end of the data.
TXT1 data contains strings of 7 bit ASCII characters. Bit 7 (most significant bit) of each byte is always set to 0, except for the last character of each string which is marked with bit 7 set to 1.
TXT2 data contains strings of 8 bit ASCII characters. Each string is terminated by a 00h byte.
This item format is described by kentaro.k-21 in Dungeon Master II Data Files Notes.
P4B1 data contains a 16 colors (4 bits) palette. It is used in ANIMATE.DAT CSB Atari ST 2.0 and in the HCSB.DAT files.
Each P4B1 item consists of 32 bytes. There are 16 big endian words (one for each color). In each word, the first nibble (most significant) is always set to 0.
The other three nibbles specify respectively the red, green and blue levels (values range from 0 to 7, the most significant bit of each nibble is ignored).
Example: If a word has the value 0426h, then the color is like this:
SEQ1 data contains a sequence of music parts to be played, like a simple music score.
It consists of a list of bytes containing the music parts numbers (index of music parts in the data file). At the end of the list, two FFh bytes mark the end of the sequence. The music then loops indefinitely from beginning to end.
SEQ2 data contains a sequence of music parts to be played, like a simple music score.
It consists of a list of little endian words containing the music parts numbers (index of music parts in the data file). The last word in the list has bit 15 set to 1 to mark the end of the sequence. The music then loops indefinitely from beginning to end.
This item type is used in Dungeon Master and Chaos Strikes Back for Atari ST.
This is machine code for the 68000 processor (the processor in Atari ST) hidden as IMG1 graphics. This is used by the game’s copy protection system.
In order to decode these items, the IMG1 algorithm must be used, but afterwards, the resulting bitmap data must be converted to the planar format used by the graphics chip on the Atari ST. The resulting binary data is the hidden executable code.
When the game engine decodes an IMG1 item, it produces the planar format directly.
See Dungeon Master and Chaos Strikes Back Graphics.dat: Hidden code
This item type is used in Dungeon Master and Chaos Strikes Back for Amiga, Dungeon Master and Chaos Strikes Back for X68000, Dungeon Master for FM-Towns and Dungeon Master for PC-9801.
This is machine code for the 68000 processor (the processor in Amiga) hidden as IMG1 graphics. This is used by the game’s copy protection system.
As the code in these items is for the Amiga versions, the items found in X68000, FM-Towns and PC-9801 are probably unused leftovers from the porting of the game to these platforms.
COD2 items are decoded in the same way as COD1, but the resulting words need reordering to separate bitplanes:
Bitplane 0 consists of: 1st, 5th, 9th, etc. words
Bitplane 1 consists of: 2nd, 6th, 10th, etc. words
Bitplane 2 consists of: 3rd, 7th, 11th, etc. words
Bitplane 3 consists of: 4th, 8th, 12th, etc. words
See Dungeon Master and Chaos Strikes Back Graphics.dat: Hidden code
This item type is used in Chaos Strikes Back for FM-Towns and Chaos Strikes Back for PC-9801.
This is machine code for the 68000 processor (the processor in Amiga) hidden as IMG2 graphics. This is used by the game’s copy protection system.
As the code in these items is for the Amiga versions, these items are probably unused leftovers from the porting of the game to these platforms.
COD3 items are decoded in the same way as COD2, the only difference is that the dimensions of the image are in little endian (IMG2) instead of big endian (IMG1).
See Dungeon Master and Chaos Strikes Back Graphics.dat: Hidden code
This item type is used in Dungeon Master for Apple IIGS.
This is machine code for the 65C816 processor (the processor in Apple IIGS) hidden as IMG1 graphics. This is used by the game’s copy protection system.
COD4 items are decoded in the same way as IMG1 items, but without any final reordering of bytes to produce a .bmp file. The resulting data directly represents the machine code.
See Dungeon Master and Chaos Strikes Back Graphics.dat: Hidden code
This item type contains binary data. The detailed structure is documented on Dungeon Master and Chaos Strikes Back Graphics.dat Item 558 Coordinates.
This item type contains binary data. The detailed structure is documented on Dungeon Master and Chaos Strikes Back Graphics.dat Item 559.
This item type contains binary data. The detailed structure is documented on Dungeon Master and Chaos Strikes Back Graphics.dat Item 560 Actions and spells.
This item type contains binary data. The detailed structure is documented on Dungeon Master and Chaos Strikes Back Graphics.dat Item 561 Keyboard and mouse input.
This item type contains binary data. The detailed structure is documented on Dungeon Master and Chaos Strikes Back Graphics.dat Item 562.
This item type contains graphics layout information like sizes and coordinates. The detailed structure is documented on Layout coordinates.
This data type is attributed to items that are not yet decoded (unknown content).
This data type is attributed to items that do not contain anything to decode.
This data type is attributed to items that have no data at all (they are just listed in the header part with a size equal to 0).
This data type contains a list of entries describing the contents of the graphics.dat file. This data type is used in Dungeon Master II only.
The data is a sequence of entries which number is specified in the header. Each entry consists of 8 bytes:
1 byte: Entry category
1 byte: Entry index. In a given category, each entry has a unique index.
1 byte: Entry type
3 bytes: Entry name. In a given category and index, each entry has a unique name.
Some examples for items categories (Weapons, Armor, Scrolls, Potions, Containers, Miscellaneous), type 0B:
Note: Depending on the value, a bonus may be permanent or temporary. It may apply when holding an item or after using/eating the item.
1 word: Entry data.
For 0B entries the entry data is the word value stored as little endian or big endian depending on the platform.
For 0C entries the entry data is the value of the image offset.
For other entries it is the item number in the graphics.dat file, always stored as big endian.
Note: Some images only contain the differences from a base image. Both images must be decoded to render the final images. Check Dungeon Master II Data Files Notes for details.
In Dungeon Master II for PC 0.9 Beta champion statistics are stored in DUNGEON.DAT like for Dungeon Master and Chaos Strikes Back.
In all other versions of Dungeon Master II, champion statistics are stored in GRAPHICS.DAT. Each champion has a 52 bytes type 08 item (Raw binary data) storing the starting skills and statistics of the champion. In Dungeon Master II for PC, these are little endian values:
The Money box item in graphics.dat has a text entry named 40 00 00 that contains: J26-28 J8 J56 J6.
This string defines which items can be stored in the Money Box. The letter “J” is for “Miscellaneous items” and the numbers are the indices of items that can be put in the money box:
In this version, images are encoded with IMG2 or IMG6 format. It is possible to determine which format is used for an image by testing the value of the second word of the header:
if (word2 & 0xfe00) == 0x8000 then the image is decompressed (IMG6 format)
if (word2 & 0xfe00) != 0x8000 then the image is compressed (IMG2 format)
Some images in the FM-Towns version use the transparent pixels capability of IMG2 format but there is no apparent reason for that: this version does not use base images and consequently there is no entry 00 00 08 00 00 00.
The following files contain only one item without any header.
I wish to thank Zyx (the developer of GraphReader), Brian (the developer of DMDecode) and Paul R. Stevens (developer of Chaos Strikes Back for Windows) as their source code helped me understand the image encodings.
I also wish to thank kentaro.k-21 for his work on the Dungeon Master II graphics.dat file format as well as SND1 decoding.