Code 2: Game logic

These functions are the higher-level game code. They follow C calling conventions (args on stack in reverse order, return value in register d0) and even have the name of the function at the end (see elsewhere in this document for the exact format of these names).

A selection of the functions and their C-style calling signature:

Code 3: lower level memory/video routines for game

Game data 2: map, text

A selection of some of the contents:

| offset | contents | | | ------- | -------- | | | 0x1a88e | Initial world map (LAND.ORG) | 4 continents * 64 rows * 64 columns | | 0x1ebd3 | Continent names | | | 0x1ecbd | Castle names | | | 0x20d4d | Contract/villain names | | | 0x20ee0 | Signpost text | | | 0x22678 | Town names | | | 0x228d7 | Spell names | | | 0x23766 | Troop quantity bucket labels (A few/Some/Many/...)

For more about the text tables, see the text section of this document.

Code 4: publisher intro

Main game data

Decompressing the data

The first byte after the header serves as the "flags" for the next eight decompression steps. The eight bits of that byte, starting from the least significant bit, choose between a single-byte literal or a two-byte reference to the window contents. If the flags byte is all-ones, then the eight bytes following are all literals that appear in the decompressed stream (and should be written to the sliding window at the current window position).

The two-byte reference to the existing window contents is made of two parts, a 12-bit window position and a 4-bit window length (beyond the minimum lookback count).

Making your own "compressed" data

You can create data compatible with this scheme that only pretends to compress (and will in fact be bigger than the source data) by inserting a byte with all bits set (value 0xff) at the start, eight bytes of source data, then another 0xff byte, then another eight bytes of source data, and so on. Count the size of your source data stream and your new "compresed" data stream and insert those as headers.

A word about graphics on the Mega Drive / Genesis

The video display processor (VDP) does much of its work not at the pixel level but instead with 8x8 groups of pixels. These 8x8 pixel blocks are called "patterns", "tiles", "chars", and probably other names too. In this document, I call them 4bpp VDP graphics tiles.

The tiles are defined and stored in 32-byte definitions, or tiledefs for short. The format is packed 4 bits per pixel (2 pixels per byte), 4 bytes per 8-pixel row.

As an example, a tiledef beginning with the hex bytes 01, 23, 45, 67 could be displayed with color 0 (transparent) in the top-left pixel, color 1 in the next pixel across, color 2 in the third pixel from the left, and so on, finish with color 7 in the top-right pixel.

Each tile is displayed with a 4-bit (16-color) palette line. The are four palette lines, each with 16 color slots (although slot 0 in each line is usually treated as transparent and not shown). Each time a tile is displayed, it must use just one palette line for all 64 pixels.

Tiles are arranged on screen with a series of 16-bit tile references, or tilerefs for short. Other documents call these tilerefs "nametables" or "patterns". Each tileref selects a single 8x8 pixeldef tile for display, along with a palette line number, and whether to flip the pixels horizontally or vertically. Some games can use this flipping and recoloring to do all kinds of tricks, but King's Bounty tends to be pretty straightforward with its display.

Troop graphics

King's Bounty has 24 types of military unit available in the game (Peasants, Militia, Archers, and so on). Each troop type is represented by a 4-frame animation. The graphics are 6x4 graphics tiles (48x32 pixels).

The graphics are stored at ROM offset 0x668ec as raw (uncompressed, headerless) VDP graphics tile definitions. Each frame has 6 * 4 = 24 tiles, and since each tile is 32 bytes, a frame is 24 * 32 = 768 (0x300) bytes. Four frames of 0x300 bytes means the animation for each troop type is 0xc00 bytes, and the animations for all 24 troop types is 0x12000 bytes.

The tiles are stored in column-major order (like villains). That is, the tiles stored as T1 T2 T3 T4 T5 T6 T7 T8 T9 ... T24 are arranged as in the figure below:

All troop graphics use the standard palette (the one stored compressed at ROM offset 0x3371a). The array of 16-bit words at ROM offset 0x2adc6 (selected by jump table -0x1e52) determines which palette line to use for each troop graphic. The values are in the same format used for tilerefs. A value of 0x0000 means palette line 0, 0x2000 means palette line 1, 0x4000 means palette line 2.

The animations are stored in order of the troop type number, the same as the text table beginning at 0x237c0 (jump table + 0x117).

Villain graphics

Similar to the animations for troops, King's Bounty has 17 villain animations.

Like troop graphics, villain graphics are stored as raw (uncompressed, headerless) 4bpp VDP graphics tile definitions. They begin at ROM offset 0x4b04c and end at 0x57c4c.

There are animated graphics for 17 different villains.

The tiles are stored in column-major order (like troops). That is, the tiles stored as T1 T2 T3 T4 T5 T6 T7 T8 T9 ... T24 are arranged as in the figure below:

Like troop graphics, each villain has a loop of 4 animation frames.

• Each villain uses a single palette line but different villains use different palette lines
  • There is an array of 16-bit words at ROM offset 0x2adf8 that select which palette line
  • This array is in the same order as the villain graphics, not ordered by "villain number" (see note below)
  • The palette values are in the format used in tilerefs: 0x2000 means palette line 1, 0x4000 means palette line 2
• Each frame is 0xc00 bytes (4 frames * 6 columns * 4 tiles * 32 bytes) making each animation 0x3000 bytes.
• Each frame is stored as 6 columns of 4 tiles (column-major)
  • Each column of tiles is stored top-to-bottom
  • Each tile represents 8x8 pixels
  • Each tile is a 32-byte pattern

The villain graphics not ordered by "villain number", so don't expect them in the same order as the table at ROM offset 0x20d6a. However, there is a mapping from villain number to graphics number in the 17 bytes at ROM offset 0x2aba9. The first byte at ROM offset 0x2aba9 is the graphic number (16) for the first villain (Murray). You can expect the animation data for Murray to begin at ROM offset 0x4b04c + (0x3000 * 16).

Event pictures

In addition to the smaller animated graphics, King's Bounty contains some bigger still images, like the intro screen and the ones shown visiting somewhere for recruiting troops.

These bigger images are stored compressed in three parts: the tile definitions, the palette definitions, and the tile references that show which tiles are displayed with which palette.

All compression is the same LZSS format with an 8 byte header made up of a pair of 32-bit long integers (big-endian). The first is the count of compressed bytes, while the other is the count of uncompressed bytes. The compression algorith is described in more detail elsewhere in this document.

After uncompressing, the tiledefs have a 2 byte header, a single 16-bit short integer (big-endian). That header is the count of tile definitions, and should equal the remaining bytes in the buffer divided by 32 (bytes per tiledef).

Likewise, the uncompressed tilerefs have a 4 byte header: a pair of 16-bit short integers (big-endian). That header is the count of rows and columns of tilerefs. The first number is rows (image height), the other is columns (image width).

The palettes, after uncompressing, are in the raw CRAM format. The buffer is 128 bytes: 4 palette lines, each 16 color entries, each entry a 16-bit short integer (big-endian). The entries represent RGB values, or rather BGR: 0x0eee is pure white, 0x00e is max red, 0x0e0 is max green, 0xe00 is max blue.

Terrain graphics

King's Bounty shows two different scales of terrain: in battle and out of battle. Terrains like like grass, trees, mountains, and lakes are shown in both. Despite some quite similar graphics, they are powered by entirely different definition data.

Hero portraits

Each of the four different character class has a different "hero portrait" picture to show on the View Character screen. Each portrait is 12 graphics tiles wide by 13 graphics tiles high (96x104 pixels).

The hero portraits are stored in a similar way to event graphics: a set of 32-byte tile definitions (stored compressed with a header), combined with a set of 2-byte tile references. There are some differences: the tile references are stored uncompressed headerless, row-by-row (row-major), and each row is padded with 0xffff in unused references.

The compression is the same LZSS compression used by event graphics and other parts of the game. The palettes are the usual set (found compressed at ROM offset 0x3371a).

Portrait addresses in ROM:

User interface graphics

Summary

Music

Music in King's Bounty is sequenced in a format conceptually similar to MIDI: Assign instrument to track. Select a key by note number, send a "key on" for that track to that note number, delay, key off.

Note numbers are counted in semitones like piano keys. In General MIDI, note number 60 (0x3c) represents middle C, and that seems to be true in Steve Hayes music sequencing format too.

Track 9 is a special track where the note numbers represent different (percussion) sounds. It is similar to General MIDI drum note numbers ("Channel 10"), and in fact the specific numbers seem to map well enough.

King's Bounty only uses few of the instruments defined in the Steve Hayes sound driver. There are many more that are defined but are never assigned to any track.

Cx yy: set track x to use instrument yy
C0 00: set track 0 to use instrument 0
C2 05: set track 2 to use instrument 5

9x: key on (note begin) for a track
90 yy zz: key on track 0, note yy, velocity zz
91 yy zz: key on track 1, note yy, velocity zz
92 yy zz: key on track 2, note yy, velocity zz
...
99 yy: play sample for note yy (like drum track)

8x yy zz: key off (note end) on track 0, note yy, zz is ignored (i think)

Fx: special
FC: end of stream

Sound effects

There is a table of 32 pointers at ROM offset 0x29f10.

The first entry points to ROM offset 0x29f90 and the final points to ROM offset 0x2a054.

The sound effects themselves are a sequence of 23 bytes (they may overlap). Byte 0 gets copied to the first byte of an "instrument" and byte 1 is used as a note number to play. The following two bytes form a 16-bit Z80 pointer to a byte.

TODO: Identify the specifics of the bytes in a sound effect definition. They might well overlap with FM instrument definition.

Multiplication tip

A pattern that occurs frequently in the code that tripped me up in the early days was a pair of multiplications, a pair of swaps, a clear and an addition. An example is the sequence of bytes:

    2001 c2fc0019 4840 c0fc0019 4840 4240 d280

which is the assembled version of the following:

    move.l d1, d0
    mulu.w 0x19, d1
    swap d0
    mulu.w 0x19, d0
    swap d0
    clr.w d0
    add.l d0, d1

I believe this was compiled from a fragment of C code that read something like i * 0x19 in a fragment like the following:

    int i;
    for (i = 0; i < 5; i++) {
      Print(messages[i * 0x19], 2, i);
    }