Dark Seed investigation

The DOS edition has file names with some consistent extensions

Palette files

Dark Seed includes over 100 separate PAL files. Almost all of them are exactly 48 bytes in size, while three of them are 768 bytes (CYBER.PAL, TITLE.PAL, and TOSSTD.PAL).

The 48-byte files are presumably 16 colours. The colours are stored with no header. Three bytes per colour entry: one byte for red, one byte for green, one byte for blue. VGA colours supported 64 levels of each channel, so the bytes range from 0x00 to 0x3f.

r0 g0 b0 r1 g1 b1 r2 g2 b2

The 768-byte files are the same headerless format, but they cover 256 colours.

TOSICONS.SPR

The one and only SPR file is called TOSICONS.SPR and contains a bunch of images.

The header is pairs of bytes (width, height) that represent the size in bytes (and pixels) of each image. 0x25 0x0f means 0x25 pixels (bytes) wide by 0xf pixels (bytes) high.

PIC files

These are presumably images of some sort. The filenames seem to mostly be locations: GARAGE.PIC, STORE.PIC, STUDYA.PIC.

There are nearly a hundred PIC files, and they vary in bytes somewhat. They range from around 20kB to around 60kB but most tend to be around 40 kilobytes, give or take 5 kilobytes.

Many of the pictures are presumably the same pixel dimensions as each other, so the variation in bytes suggests some compression.

The file with the biggest byte size is GFRAME.PIC and it begins with the same byte sequence as the similarly-named CFRAME.PIC:

02 80 01 5e

All the other PIC files begin with another byte sequence:

01 f5 00 c8

These four byte headers can be interpreted as a pair of big-endian 16-bit integers:

Since the game is advertised to use "high resolution" 640x350 graphics, it seems reasonable that the FRAME graphics would cover that whole size and the location pictures which go in the smaller area inside the frame would be a second smaller size.

DIG and SIT files

Although Dark Seed comes with more than a dozen DIG files, they are mostly copies of each other. There are only four unique files, and one of those four is essentially blank (repeating the three-byte sequence 00-03-00 over and over).

I believe they are music (and perhaps music-like sound effects). The biggest files (HOUSE, QUIET, TOS1, and TOWN) probably contain instrument definitions (FM synthesiser configuration) while the smaller ones probably only contain which notes to play.

Every DIG file has a SIT file with a matching name. QUIET.DIG and QUIET.SIT, BOOK.DIG and BOOK.SIT.

Every SIT file is exactly 4096 bytes. Most SIT files are unique, but six have the exact same content as each other (ALIEN, CREDITS, DOLL, IMPLANT, NIGHT2 and NIGHT3)

SBR and PCS files

Each pair of DIG and SIT files has a matching pair of SBR and PCS files. Furthermore, there are five more SBR/PCS pairs beyond the ones that match DIG/SIT.

ROM files

Each of the 66 ROM files are exactly 1187 bytes. There are big stretches of 00 bytes as well as fairly long stretches of 0xff bytes in each one. Many of these 0xff stretches are in the same position or at least end in the same position./202e70696300

Each file begins with fixed-length "8.3" null-terminated (ASCIIZ) filenames.

Here "x" represents a space, which is eliminated in DOS file access (presumably).

Most (all?) room files seem to have some stretches that look like a visual bitmap if you view them with 40-byte strides (beginning at offset 0x7f).

At least 11 rows, probably 15 or 16 rows. Seems to be 640 bytes.

Just before that visual map there's a section that seems to be pattern with a 11-byte stride.

ROOM4.ROM has at offset 0x53 9 null bytes followed by 0xff 0x03, then that 11-byte pattern repeated four times. Same for ROOM3.ROM and ROOM1.ROM.

Just after the visual map there's a pattern of bytes that are valued either 01 or 00. offset 0x287 in ROOM10.ROM - and seems to make a pattern with stride length of 16 bytes. Maybe 6 or 7 rows of that pattern.

• ROOM0 seems to start a 16-stride pattern at 0x25f, with maybe 9 or 10 rows. 0x2ef is an all-zero row.
• ROOM1 seems to start a 16-stride pattern at 0x25f, with maybe 9 or 10 rows. 0x2ef is an all-zero row.

Some rooms (ROOM2, ROOM3) seem to have all-zero rows beginning at 0x25f.

• ROOM4, ROOM5, ROOM6 has f0 bytes as well as the 00 and 01 bytes. but there is still very much a visible pattern.
• ROOM7 has the regular pattern.
• ROOM8 has 80, e0 and f0 as well as 01 and 00. But those seem to be part of the visual. Starting at 0x287 for 7 rows of 16 bytes gives all 01 and 00 bytes in a nice visual pattern.
• ROOM9 has the regular pattern.
• ROOM10 includes some f0 bytes.
• ROOM11 includes some f0 bytes.
• ROOM12 has the regular pattern.
• ROOM13 includes an 80 byte.
• ROOM14 has the regular pattern.
• ROOM15 has the regular pattern.
• ROOM16 has the regular pattern.
• ROOM17 includes some f0 bytes.
• ROOM18 has the regular pattern.
• ROOM19 includes a c0 byte and several f0 bytes as well as 01 and 00.
• ROOM20 includes a c0 byte and several f0 bytes as well as 01 and 00.
• ROOM21 includes a c0 byte and several f0 bytes as well as 01 and 00.
• ROOM22 includes a c0 byte and several f0 bytes as well as 01 and 00.
• There is no ROOM23.

Near the end of the file are 14-byte stride patterns. and some stretches that look patterned with 14-byte strides (starting at 0x36f)

• ROOM0's obvious 14-stride pattern (03e8 0000 000...) begins at 0x3df
• ROOM1's obvious 14-stride pattern (03e8 0000 000...) begins at 0x361
• ROOM2's obvious 14-stride pattern (03e8 0000 000...) begins at 0x36f
• ROOM3's obvious 14-stride pattern begins at 0x345
• ROOM10's obvious 14-stride pattern begins at 0x3c3

It might be these 14-byte data structures always start at offset 0x2ff and the repeating pattern is an empty slot or something.

In fact, these 14-byte data structures start with 0000, 0001, 0004, or 03e8 and 0x3e8 is decimal 1000. Perhaps they are the target information: bounding boxes (x, y, width, height?), command (look, touch, go to?).

The lines that start with 0004 seem to follow a fairly predictable pattern:

0004 sequence sub600 sub240 usuallycor7 usallyc seqseq

The sequence seems to be (mostly) 1 for the first 0004 line, 2 for the second, and so on. The final two bytes seem to be (almost always) the same value as the sequence, so a line beginning with 00040002 will almost certainly end with 0202.

ps @ 13
px 13 * 40 @ 0x7f @e:hex.cols=40
px 8 * 16 @ 0x28f @e:hex.cols=16

Looking at the shapes in the 40-stride visualisation and being familiar with the game suggests that this area is a representation of the walkable parts of the room, "turned on its side and flipped": The first bytes represent the left of the screen, from top to bottom, with each successive 40 bytes representing another vertical slice of the room. The last 40 bytes of this section represent the rightmost slice of the play area.