Pictures

Dark Seed for DOS uses a somewhat unusual VGA graphics mode: 640x350 with 16 colors. The manual explains how this was negotiated with artist H R Giger:

Giger agreed to lend his artwork, provided Cyberdreams uses only high-resolution graphics mode, in order to avoid the "square and jagged" look of low resolution.

The two programs by (START.EXE and TOS.EXE) by the two separate programmers (Krause and Feddersen, respectively) each use their own image formats. START.EXE uses files called ".IMG" while TOS.EXE uses ".PIC" instead.

Animations

This section is a stub.

START.EXE uses image (IMG) and animation (ANM) files, while TOS.EXE uses picture (PIC) and (NSP).

Sprites

This section is a stub.

NSP files (aNimated SPrite?) start with 192 bytes, or more specifically 96 pairs of bytes. Each pair of bytes represents the size of an image frame.

These 96 size pairs are followed by 0x60 image frames, each of which has its size the calculated size s.

An empty/unspecified image is 0x01 0x01 (1 width, 1 height) with the body byte being 0xff. Most images in most files are empty.

The matching OBT files are in a different format, containing information to animate the sprite frames.

OBT files (object transformation?) contain exactly 20 "objects" (animation information), and are mostly empty. They are a fixed size, regardless of how much is used.

Each object (animation) starts with a byte that counts the number of meaningful frames of movement in the animation. Then 20 frame steps (mostly empty). Each frame step is 8 bytes: delta X (one byte for x-direction, two bytes for distance), delta Y (three bytes, same structure as X), sprite number to move (byte), tick duration (byte).

All of the OBT files are the same fixed size ( 20*(1+(20*8) = 3220 bytes) except for four smaller ones: ROOM2.OBT (for room "SECRET1"), ROOM3.OBT (for room "SECRET2"), ROOM56.OBT (for room "ARCHIVES") and MIRROR.OBT. Each of these is 3072 bytes long.

TODO: Check how the shorter OBT files are handled. Does the loader ask for less data, or perhaps simply handles an early finish?

Palettes

The palettes are stored in files with the extension ".PAL". The format is straightforward and maps very closely to VGA hardware. There are two sizes: most are 16-color palettes (stored as 48 bytes), and also a few 256-color palettes (stored as 768 bytes) but these seem to be unused in the game.

Each of the sixteen entries is three bytes: one byte for red, one byte for green, one byte for blue. The maximum value is 63. Thus pure white is represented as (63, 63, 63), pure black as (0, 0, 0).

Each room has its own palette file but many of them are complete duplicates.

Sound and music

Later (CD-ROM) versions of Dark Seed for DOS used standard MIDI files for music and Creative Labs "Voice" files for sound effects and speech. The speech files have the usual ".VOC" file extension and the sound effects use the alternative ".SFX" name.

Earlier (floppy) versions of Dark Seed for DOS provided music and sound in other formats to work with various hardware at the time. The three options are the basic PC speaker, AdLib, and Sound Blaster.

01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 00 13 14 15 16 17 18 00

String lists

The credits text is embedded as data in START.EXE, and the names of objects are embedded as data in TOS.EXE. Most of the in-game messages are read from an TOSTEXT.BIN.

The format of TOSTEXT.BIN begins with an ordered series of little-endian uint16 offset values. Each one of these offset values point to the start of a text string later in the file. The offset value is an absolute position within the file.

The series of bytes at the start of the file:

a6 07 d4 07 f6 07 ...

Can be read as a series of little-endian integers:

• 0x07a6
• 0x07d4
• 0x07f6

Which in turn can be used as file offsets to find a line of text:

0x07a6: "You have dared touch an Ancient! You die!\r\n"
0x07d4: "Fido takes a chunk of your head\r\n"
0x07f6: "The fleshy stalk"...

Executable

The file called ds (or sometimes DS) is the main executable for the Amiga. It is the format that was standard on the platform at the time, a format which lacks a formal name but is sometimes called "old-style Amiga executable", "LoadSeg" or "hunky" format.

It consists of a number of distinct "hunks", some of which are code, some data, and some a mix of both.

The English floppy disk demo and full version look much the same:

In some versions, like the CD32 edition, MaxTrax variables and code appear in single hunk together.

Pictures

Files with that begin with the header magic number "MCP" (M's Compressed Picture, perhaps?) are, once decompressed, in a suitable format for blitting to the Amiga graphics hardware.

The header is eight bytes. The low-order nybble of the fourth byte is either 1 or 4, and shows the count of bitplanes. A single bitplane file can be decompressed as a single stream.

The following two 16-bit values represent width and height respectively. The width is rounded up to the next multiple of 16 then divided by 8 and stored as a count of bytes per line. The height is multiplied by half of the width and the result is stored as the number of 16-bit words per bitplane. In the case of a single bitplane, that number (height times width-rounded-up divided by 16) is the number of words in the whole decompressed file.

In the case of multiple bitplanes, the decompression result is allocated first to the first (lowest-order) bitplane until it fills up (at a 16-bit word boundary). The next bytes to be decompressed fill up the second bitplane, until it fills up, and so on until all four are filled. These filled bitplanes are all the same size, and can be converted to so-called "chunky" format of one-byte-per-pixel palette indexes using an established "planar to chunky" conversion algorithm.

Here are the header bytes of some example files and their expected decompressed size:

Palettes

The Amiga floppy disk and Amiga CD32 version of Dark Seed both use 16-color (4-bit) palettes. Each of the 16 entries is a 16-bit number: 0xfff is bright white, 0x000 is pure black. The palettes are stored as data in the game executable rather than in a separate file.

There is a default palette and a table of 8 alternate palettes. The table of alternate palettes is 256 bytes: 8 palettes of 16 entries. There is a different table of data elsewhere in the executable which you can use to calculate which palette to load for each resource.

Resource IDs are 32-bit numbers that can also be treated as four-character ASCII filenames ("R10A" is 0x52303141).

Resources with a zero palette byte: No modification.

Resources with a "positive" palette byte (0x01-0x7e): Standard with modification. The second-highest palette entry is replaced with a value from a 63-entry lookup table.

Resources with a "negative"/high palette byte (0x80-0xff): A specific alternate palette. The number of the alternate palette can be calculated using (x + 5) % 8 where x is the byte in the lookup table and % is the remainder after division.

Sprites

Smaller image overlays and updates are stored as flat images in the additional materials files. They are pictures in the same MCP (compressed picture) format as the room pictures.

The coordinates and parameters for which parts of the image data are used, as well as animation timing, live in the executable file (see Object data).

R00B stores the sprite image data for room 0, but not all rooms have such image data. Room 1 has none at all, while room 31 has several separate images for different sprites: R31B (stick), R31C (Delbert throwing), R31D (dog), R31E (Delbert walking and drinking), and R31F (Delbert standing).

The image data for player walking sprites is stored in the resource file W1 (light world) and W2 (dark world). Likewise, the image data for the player falling is stored in resources F1 (light world) and F2 (dark world).

The styled font used for the opening credit sequence is a sprite too, stored in N03A. The main font for message text in the game is stored in the same file as the inventory pictures: I1 (light world) and I2 (dark world).

Sound and music

Rooms

The "R00A" file holds the static picture for room 0 in the same format as the other game graphics.

Room data

The "R01M" file holds the movement mask for Mike, the player character, in room 1. It is a single-bitplane image the same size as the room picture, and distinguishes between the places Mike can move to (bit set) and cannot move to (bit clear). All (or at least most) rooms have a movement mask.

The "R01S" file doesn't exist because room 1 doesn't have a room-specific sprite stencil. It uses the general light-world sprite stencil S1. Room 5, the upstairs hall, does have a room-specific sprite stencil. It is a single-bitplane image the same size as the room picture. Only the pixel locations with bits set in the stencil will draw through. This allows a sense of layered depth, letting the sprites appear to go "behind" parts of the picture.

String lists

The Amiga editions do not store string lists in separate files, but rather as data in the game executable file.

There are two string lists:

• a big one with response messages (001-997), matching the efx speech
• a small one with item names and credits (0-301)

Both the string lists are in the same "hunk" of the executable, the final hunk.

A string list is stored as a big block of strings are provided concatenated together without any dividing marker. After the strings have finished, there is a separate numerical list of each string's starting position within that concatenated block.

NothingBoxHandQuestionCtrlcrowbarjournalscotch
^      ^  ^   ^       ^   ^      ^      ^
0      7  10  14      22  26     33     40

There is some special handling for messages 977-999. These are formatted messages stored in a somewhat unusual form.

The table is located in the data hunk after the encoding table. The table is 128 bytes long, and covers 25 messages. The game uses this table to assemble multi-part messages such as those that mention a held item. 22 rows of 5 bytes each, then some more rows of 6 bytes each. Each row represents a combined message, with each byte representing a segment. The byte 0xff signals the end of the message. The byte 0xfe represents string 0x10d, which is "You see the ". Byte values 0-3 are replaced with object names for the held object, the interacted object, and something else like that.

The first composite string (in the English CD32 version) is the byte sequence EC 01 FF FF FF. This two strings, entry 0xec in the smaller string table ("This sentry cannot be stopped with a"), the name of the object being held. The first 0xFF byte signals the end of the sequence, the others are unused.

This is equivalent to "This sentry cannot be stopped with a ^1." as used in the Macintosh port of Dark Seed.

The next composite string is the byte sequence CA 00 EB FF FF. This is three strings, with a different placeholder. The first and third byte represent entries in the smaller string table (0xCA is "The", 0xEB is "has no effect on the alien tubes."). The 00 value is a a placeholder for the the object being held.

This is equivalent to "The ^0 has no effect on the alien tubes." as used in the Macintosh port of Dark Seed.

TODO: confirm the difference between 0 and 1 placeholders.

Text character encoding (accents etc)

All strings in the string table are encoded in a subset of ISO-8859-1. The English editions don't use anything beyond ASCII (and in fact a quite limited subset of ASCII) while the French, German, and Spanish translations make use of language-specific characters. All use the same encoding and font. The main game font "sprites" (I1/I2) only provide images for up to 104 of the 256 possible byte values. Character code points are mapped to font "sprites" in a table in the game executable.

The ASCII upper-case letters, lower-case letters, and numerals are all present. Some limited ASCII punctuation is provided:

Hex	Char
21	!
22	"
27	'
2C	,
2D	-
2E	.
3A	:
3F	?

The floppy disk editions provide ASCII slashes too:

Hex	Char
2F	/
5C	\

The ISO-8859-1 subset beyond ASCII are these:

Hex	Char	Description
A1	¡	INVERTED EXCLAMATION MARK
BF	¿	INVERTED QUESTION MARK
C4	Ä	LATIN CAPITAL LETTER A WITH DIAERESIS
CB	Ë	LATIN CAPITAL LETTER E WITH DIAERESIS
D6	Ö	LATIN CAPITAL LETTER O WITH DIAERESIS
DC	Ü	LATIN CAPITAL LETTER U WITH DIAERESIS
DF	ß	LATIN SMALL LETTER SHARP S
E0	à	LATIN SMALL LETTER A WITH GRAVE
E1	á	LATIN SMALL LETTER A WITH ACUTE
E2	â	LATIN SMALL LETTER A WITH CIRCUMFLEX
E4	ä	LATIN SMALL LETTER A WITH DIAERESIS
E7	ç	LATIN SMALL LETTER C WITH CEDILLA
E8	è	LATIN SMALL LETTER E WITH GRAVE
E9	é	LATIN SMALL LETTER E WITH ACUTE
EA	ê	LATIN SMALL LETTER E WITH CIRCUMFLEX
ED	í	LATIN SMALL LETTER I WITH ACUTE
EE	î	LATIN SMALL LETTER I WITH CIRCUMFLEX
F1	ñ	LATIN SMALL LETTER N WITH TILDE
F3	ó	LATIN SMALL LETTER O WITH ACUTE
F4	ô	LATIN SMALL LETTER O WITH CIRCUMFLEX
F6	ö	LATIN SMALL LETTER O WITH DIAERESIS
F9	ù	LATIN SMALL LETTER U WITH GRAVE
FA	ú	LATIN SMALL LETTER U WITH ACUTE
FB	û	LATIN SMALL LETTER U WITH CIRCUMFLEX
FC	ü	LATIN SMALL LETTER U WITH DIAERESIS

The following translation table shows mappings (and non-mappings, marked as ..):

	x0	x1	x2	x3	x4	x5	x6	x7	x8	x9	xA	xB	xC	xD	xE	xF
0x	..	..	..	..	..	..	..	..	..	..	3d	..	..	..	..	..
1x	..	..	..	..	..	..	..	..	..	..	..	..	..	..	..	..
2x	4b	34	35	..	..	..	..	36	..	..	..	..	37	3a	38	4c*
3x	41	42	43	44	45	46	47	48	49	4a	3b	..	3c	..	..	39
4x	..	1a	1b	1c	1d	1e	1f	20	21	22	23	24	25	26	27	28
5x	29	2a	2b	2c	2d	2e	2f	30	31	32	33	4d*	..	..	..	..
6x	..	00	01	02	03	04	05	06	07	08	09	0a	0b	0c	0d	0e
7x	0f	10	11	12	13	14	15	16	17	18	19	..	..	..	..	..
8x	..	..	..	..	..	..	..	..	..	..	..	..	..	..	..	..
9x	..	..	..	..	..	..	..	..	..	..	..	..	..	..	..	..
Ax	..	66	..	..	..	..	..	..	..	..	..	..	..	..	..	..
Bx	..	..	..	..	..	..	..	..	..	..	..	..	..	..	..	65
Cx	..	..	..	..	58	..	..	..	..	..	..	..	..	..	..	..
Dx	..	..	..	..	..	..	5e	..	..	..	..	..	5f	..	..	67
Ex	53*	60	51*	..	52	..	..	54	56*	50	55*	..	..	61	57	..
Fx	..	64	..	62	5a*	..	5b	..	..	5d*	63	5c*	4f	..	..	..

Most versions of Dark Seed for Amiga use a similar font image and a similar table. Some versions have differences like the ones marked * in the table (for example, the French floppy disk).

The encoding table is located in data hunk after the file resource table (which file is on which disk) but before the five-stride array (which starts with the byte sequence fe01ffffff, ec01ffffff).

A separate table holds the width (in pixels) of each glyph. Most are 6 pixels wide but the letter 'l' is only 2.

Movies

The four resources called M00B, M01B, M02B, M03B each have the signature MDA and seem to represent full-screen animations.

These files have a header structure not unlike MCP.

The low-order nybble of the fourth byte (offset 3) is used for the number of bitplanes. (All four files have the value 4 here, for 4 bitplanes). The higher-order nybble (always 1 in these files) is used to calculate bytes ber bitplane with the following algorithm: (x + 1) * 2

The next four bytes are interpreted as 16-bit integers (big-endian) are width and height. Always 320 width and 400 width.

The rest of the file is structured as follows:

• MSB word, COUNT, count of the upcoming chunk of data bytes
• one byte indicating which bitplanes to update
• another byte (padding, seemingly ignored)
• COUNT bytes of difference data for the frame in the format described below

Each frame is structured as follows:

• changes for bitplane 0
  • five bytes (40 bits)
  • a series of byte-column row changes
• changes for bitplane 1
  • five bytes (40 bits)
  • a series of byte-column row changes
• changes for bitplane 2
  • five bytes (40 bits)
  • a series of byte-column row changes
• changes for bitplane 3
  • five bytes (40 bits)
  • a series of byte-column row changes

Each bit in the five-byte stretch at the start of each bitplane represents a "byte column" (8 pixels) in the picture. If there are no changes to this bitplane in this frame, these bits will all be clear. If the first (highest-order) bit is set, the leftmost "byte column" has changes in this frame -- that is, some of the left-most 8 pixels have changed value.

For each column bit set, there will be a set of row updates. These follow in order directly after the byte column change summary.

• count of upcoming row updates, each of which has:
  • byte (uint8) for row count which is is split:
    • high bit clear means changes are included
    • high bit set means no changes to row count rows
    • remaining bits are the actual row count (RC)
  • Series (length RC) of bytes of of data to be XORed

Files

Many of the files are exactly the same between the Amiga floppy disk version and the CD32 version. There may be some language-specific changes in pictures (like the newspaper, the note from the movers, etc).

Resources in Dark Seed

A credit image says "Darkseed Macintosh developed and programmed by Brian Fitzgerald", and that name appears in other credits.

It seems to have been built with "THINK C" and AppMaker, and some debugging/development information seems to have been left behind. (A happy accident for digital preservationists.) An icon says "THIS SPACE FOR RENT", presumably as a joke.

Templates

Macintosh resource management tools like ResEdit and the third-party Resorcerer use template resources (with the ResType "TMPL") to provide a convenient user interface for resource data.

The format of TMPL resources is documented in the official Macintosh ResEdit Reference from Apple, and the Resorcerer Template Information has information on some extended structures that Resorcerer provides.

Pictures

Dark Seed uses at least four different resource types for graphic data ("PicL", "PicD", "Fram", "Room"), but they all seem to be encoded in the same way.

It presumably uses compression, perhaps similar to the compression used in Dark Seed for DOS (nybble-based run-length encoding) or Dark Seed for Amiga (LZSS).

The window frame pictures ("Fram" resources) come in two sizes, one default and one for 12-inch displays (presumably targeting a 512x384 resolution instead of the default 640x480).

TODO: Research the actual storage format and compression.

Palettes

Many resources with ResType "pltt" have names closely tied to the DOS version of Dark Seed ("ROOM04.PAL", "LIB-BABE.PAL"). The format seems to be a 16-bit big endian count of entries, then 16 bytes for each entry. An entry is mostly zeroes. Three of the bytes are not zero, and I presume then to be a byte each for red, green and blue.

Most of the palettes seem quite similar to each other, or even exactly the same.

Sprites

The resources with ResType "Sprt" are sprite animations.

They have names quite closely tied to the DOS version of Dark Seed ("ASPIRIN.NSP", "RM10STAIRS.NSP", "ROOM04.NSP") and are often similar in size to the DOS editions too. They presumably represent much the same data as the DOS ".NSP" files but have such different byte values that the data must be structured differently.

Rooms

The "Room" resources appear to hold the per-room static picture in the same format as the other game graphics.

000000020129013700BC000C000C002900BD01BE006C0038006E000000040140008200FD00AF00FD01B8014001E5

0000 one-based count of links
     (no links)

    0002 one-based count of objects

        01 object 1 type
          29 object 1 number (ITEM_TIN_CUP)
            0137 object 1 x
                00BC object 1 y
                    000C object 1 width
                        000C object 1 height
                            00 object 1 depth
                              29 object 1 sprite

                                00 object 2 type
                                  BD object 2 number (ITEM_CELL_BARS)
                                    01BE object 2 x
                                        006C object 2 y
                                            0038 object 2 width
                                                006E object 2 height
                                                    00 object 2 depth
                                                      00 object 2 sprite


                                                        0004 one-based count of polygon points

                                                            01400082 point 1 (320, 82)
                                                                    00FD00AF point 2 (253, 175)
                                                                            00FD01B8 point 3 (253, 440)
                                                                                    014001E5 point 4 (320, 485)

0002000200000000 41 05 0000 0000 42 05 0001 0000 0000 00 05

0002 count of objects

    0002 count of object 1's frames

        0000 x vector for object 1 frame 1
            0000 y vector
                41 sprite number
                  05 ticks

                    0000 x vector for object 1 frame 2
                        0000 y vector for object 1 frame 2
                            42 sprite number
                              05 ticks

                                0001 count of object 2's frames
                                    0000 x vector for object 2 frame 1
                                        0000 y vector for object 2 frame 1
                                            00 sprite number
                                              05 ticks

String lists

The game contains string lists as standard Macintosh "STR#" resources.

One list (resource ID 301, named "English item strings") contains the names of game objects in what seems to be the same order as code (crowbar=5, journal=6, scotch=7).

The credits mention separate teams for "IBM" and Macintosh. The game strings include some leftover DOS-specific values like mentioning "Soundblaster".

The (English) strings are encoded in MacRoman, a platform-standard superset of ASCII. For example, message 999 includes a 0xd5 byte to represent a curly apostrophe (what Unicode calls U+00219 RIGHT SINGLE QUOTATION MARK).

Movies

This section is a stub.

The resources with the ResType "Movi" are presumably the bigger animations.

They have somewhat descriptive names ("Nightmare 1a", "SpaceLetters d"), with only a few kinds of name:

• Nightmare
• SpaceLaunch
• SpaceLetters
• SpaceLand

In addition, one of the "Movi" resources (ID 131) seems to have been blanked out. It is named "-- Nightmare 2 --" and has a single byte (0xDD) as its entire content.

TODO: Research the actual format of Movi resources.

Sound and music

Speech and sound effects are stored as AIFF "snd " resources, as are the instrument samples that are arranged into music. Two codecs are used: raw unsigned 8-bit PCM (codec identifier "raw ", with the space) and the less-common Macintosh Audio Compression/Expansion 3:1 (codec identifier "MAC3").

The sequence and timing of notes to play is stored as standard MIDI data in "Midi" resources. The selection of instruments are stored in "Inst" resources.

The resource templates tell us the structure to interpret "Inst" instrument data:

• one-based count for list of instrument definitions, where each item has:
  • 'snd ' resource (DWRD, decimal word) - presumably resource ID
  • Fixed pitch (0=none) (DWRD)
  • Loop enable (BOOL, boolean byte)
  • Voice enable (BOOL)

Strings

The strings are in the same format as Macintosh "STR#" resources: a 16-bit count for the number of strings, followed by a length byte for the first string, followed by the first string's characters, then the length byte for the second string, then the second string's characters, and so on. The text is encoded with Shift-JIS, a widely-used standard for Japanese text at the time. The Japanese PlayStation resource ST301.STR corresponds with "STR#" resource number 301 (named "English Item Strings" in the English Macintosh release):

Likewise, the Japanese PlayStation resource ST308.STR corresponds with "STR#" resource number 308 in the English Macintosh release:

The string numbers line up perfectly with the English Macintosh release. These two parts of the combined string list 308 are equivalent, and in the same order.

Some of the strings contain line breaks:

Some of the strings contain the same placeholders ("^0", "^1") used in Dark Seed for Macintosh:

It appears that the smaller component string lists like 401 (Credits) and 302 (messages 1-200) also exist: